Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Paving the on-ramp to Java

openjdk.org

Post reply on HN
Print view View original

91–100 of 156 posts

Re: Paving the on-ramp to Java

#91

Post by RockingGoodNite »

kubota wrote: post #67
ferd wrote: post #64

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…

var ages = Map.of("sarah",19, "dan",35); //valid java

var and static must die.

Re: Paving the on-ramp to Java

#92

Post by exabrial »

One additional comment: they need to make the launch protocol for jar files, much simpler as well. META-INF needs to be replaced with a simple properties file that indicates what method to run and which libraries to have on the class path.

Re: Paving the on-ramp to Java

#93

Post by jfengel »

ferd wrote: post #64

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…

Java is deliberately nudging you not to do things like that. It would rather you create a class with fields a and b -- which has its own verbosity, though they've improved it.

I find that I use structures like that primarily when interfacing with other loosely-typed languages, like Javascript, which do encourage you to create structures on the fly like that. Impedance mismatch is always a pain, no matter where it occurs.

That's not to say Java doesn't want you to use Maps. They do -- but only when the content is dynamic. They don't want to add literals for it because that's the opposite of their goal.

There are days when you want it anyway, and then you grumble that the language has forced you to do something ugly. But every language is a set of tradeoffs where some things are ugly, other things are pretty, and the language spec doesn't require a shelf of its own.

Re: Paving the on-ramp to Java

#94

Post by kaba0 »

kaashif wrote: post #72
mcculley wrote: post #62

Earlier quoted context omitted.

Yes, I definitely meant in the mathematical sense. I would really like a way to express pure functions in Java. There would need to some way to mark objects as immutable at the language level.

I switched from being a C++ developer to Java a while back and the lack of const (i.e. immutability) annoys me. It annoys me even more than no-one seems to care about it much, and most think final is good enough - you can still mutate final objects. In C++ all references are final (in a Java sense) since they can't be reseated, but const actually gets you immutability (modulo const_cast). I just want everything to be…

Clojure may be what you want then, if you can stomach the lisp-y syntax.

Otherwise Scala is pretty pragmatic about it (val vs var).

In both cases you still get only shallow immutability, but if nigh every object itself is immutable, shallow immutability may not be so shallow.

Re: Paving the on-ramp to Java

#95

Post by Sankozi »

monster_group wrote: post #65
mcculley wrote: post #32

I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…

Static methods are a pain for unit testing though. I have started avoiding them for that reason alone. For stateless objects, you can always have a singleton and invoke all the methods on that object giving effectively static behavior without the baggage.

They are hard to test only if they are not functions and access some global mutable state. In vast majority of cases static methods are functions and are easier to test than normal methods, because you do not need to initialize object.

Re: Paving the on-ramp to Java

#96

Post by [deleted] »

monster_group wrote: post #65
mcculley wrote: post #32

I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…

Static methods are a pain for unit testing though. I have started avoiding them for that reason alone. For stateless objects, you can always have a singleton and invoke all the methods on that object giving effectively static behavior without the baggage.

[deleted]

Re: Paving the on-ramp to Java

#97

Post by xwolfi »

RayVR wrote: post #53
kaba0 wrote: post #29

I always love seeing Brian Goetz’s articles, they explain the problem succinctly and they do a great job of validating their approach, showing the shortcomings of alternatives. I especially like the language team’s very conservative attitude, valuing backwards compatibility greatly. Here, they again solve most of the problem by simply changing the “program launcher” code, without any modifications/special casing done…

Succinctly? You must be a Java programmer. This essay is at least 3-4x longer than I’d like. As a (mostly) python and C++ programmer, Java feels like someone is afraid they’re speaking to an imbecile, so they constantly repeat themselves and over-explain every point.

Yeah and when you ask a question to your C++ colleague in that mysterious legacy team, not even on the language, you're convinced they think they're speaking to an imbecile.

C++ devs seem to live in a bubble of self admiration, spending hours over engineering under-performing applications they never profile - after all, profiling is like debugging: it's for people who cant code :p

Re: Paving the on-ramp to Java

#98

Post by gkfasdfasdf »

aaa_aaa wrote: post #7
hughjd wrote: post #4

Doesn't Groovy ( https://groovy-lang.org ) achieve much of this? I remember being taught with it at university for some time before they introduced Java. With Groovy you don't need the class or main method, and can have a program which is just `println "Hello world!"`.

Groovy is not Java.

Neither is the final sample presented in the article! But I think the point is that Groovy already exists and can run most Java programs as well.

Re: Paving the on-ramp to Java

#100

Post by cobbzilla »

kaashif wrote: post #72
mcculley wrote: post #62

Earlier quoted context omitted.

Yes, I definitely meant in the mathematical sense. I would really like a way to express pure functions in Java. There would need to some way to mark objects as immutable at the language level.

I switched from being a C++ developer to Java a while back and the lack of const (i.e. immutability) annoys me. It annoys me even more than no-one seems to care about it much, and most think final is good enough - you can still mutate final objects. In C++ all references are final (in a Java sense) since they can't be reseated, but const actually gets you immutability (modulo const_cast). I just want everything to be…

> I just want everything to be immutable unless mutability is really truly needed

Have you tried Rust? It’s nice in this regard; variables are immutable unless explicitly declared mutable.

Post reply on HN