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

151–156 of 156 posts

Re: Paving the on-ramp to Java

#151

Post by kaashif »

barbarbar wrote: post #150
kaashif wrote: post #72

Earlier quoted context omitted.

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…

What about Records and immutable Collections, Sets, Maps? Isn't it possible to achieve what you want with that?

Not really. In Java you can do all kinds of things with immutable wrappers, but the language doesn't help you and it doesn't come for free for your own types.

In C++ you can write a class with some methods that mutate, and some const methods that can't mutate anything, and you can pass around const references through which mutation is guaranteed to be impossible. This all comes for free.

Re: Paving the on-ramp to Java

#152

Post by kaashif »

cobbzilla wrote: post #100
kaashif wrote: post #72

Earlier quoted context omitted.

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.

Yeah, and I really like Rust. Rust has its mistakes but having RAII and immutability by default goes a very long way.

But it's not terribly easy or even a good idea to switch from Java to Rust at a real company that has no time to rewrite libraries, has to hire developers, and so on.

Re: Paving the on-ramp to Java

#153

Post by barbarbar »

kaashif wrote: post #151
barbarbar wrote: post #150

Earlier quoted context omitted.

What about Records and immutable Collections, Sets, Maps? Isn't it possible to achieve what you want with that?

Not really. In Java you can do all kinds of things with immutable wrappers, but the language doesn't help you and it doesn't come for free for your own types. In C++ you can write a class with some methods that mutate, and some const methods that can't mutate anything, and you can pass around const references through which mutation is guaranteed to be impossible. This all comes for free.

This was added a couple of years ago https://docs.oracle.com/en/java/javase/17/docs/api/java.base....

I was thinking that would make it possible to create unmodifiable data objects using that (and not Object as base class).

Re: Paving the on-ramp to Java

#154

Post by ascendantlogic »

chrisseaton wrote: post #136
dianeb wrote: post #135

Earlier quoted context omitted.

Alas, the language is incredibly verbose in and of itself and the plethora of examples continue to be incredibly verbose. From _Java in a Nutshell_ to the latest documentation, the examples all tend to be of the form: UnbelievablyLongClassName unbelievablyLongClassName = new UnbelievablyLongClassName(parameterName, anotherParameterName); Given that nearly all existing code follows this pattern (yes, there is var whic…

> UnbelievablyLongClassName unbelievablyLongClassName = new UnbelievablyLongClassName(parameterName, anotherParameterName); That's verbose, but how is it convoluted? It seems extremely plain and simple and linear to me? A local variable is set to a new instance of a class with a couple of parameters. What do you see as being convoluted here?

Individually the lines are verbose but are usually readable. But once you start talking about hundreds or thousands of lines across tens or hundreds of files the sheer volume of the text is what starts leading to convolution. What pushes it over the edge then are the endless abstractions, misdirections and enterprise patterns that may or may not make sense to solve the problem at hand but generally are "best practice" or at least were when lots of legacy code was first laid down 10-20 years ago. It becomes a giant headache very quickly.

Re: Paving the on-ramp to Java

#156

Post by okennedy »

mcculley wrote: post #140
okennedy wrote: post #55

Earlier quoted context omitted.

It's worth keeping in mind that the primary audience that the article discusses is not folks at your skill level. By far one of the most common errors I see as a CS instructor is aggressive over-reliance on global state. Not global methods, but state. However, usually what causes the student to reach for global state is the fact that it can be accessed from a static method like main; In lieu of figuring out how to st…

I agree that this is a good way to simplify Java. I just don’t want newbie Java programmers told that static methods are bad because that is our only way to express pure functions and we need them to learn to default to immutable data and minimizing stateful objects.

That's a fair long term view, and a sense for this type of nuanced choice is one of the marks of a good programmer. Not all students have the experience to judge the tradeoff, and so my goal as an educator is to default them to the safer of the two options. In this example, it's usually trivial to just add the static keyword to an already pure method. In my experience it's considerably harder to refactor a series of stateful methods that were incorrectly declared static, since you usually also have to plumb the state object through all of the callers, and their callers, and their callers, etc...
Post reply on HN