Hacker News Reader

Comment by rlawson | Hacker News Reader

I don't like Oracle very much but I have to say I appreciate the rate at which Java has improved

It's working out well as a 'forever' language: I can understand and use java code from the dawn of time (aka late 90s, but more realistically 1.5, 20 years ago), and Goetz seems to being doing well keeping that going. The challenge is adding any new features, but they are maintaining a reasonable cadence.

At some point I imagine they will have to remove or at least isolate and disarm some ubiquitous core features (e.g. serialisation and synchronisation).

Appreciate Kotlin and others pushing it there.

Yeah, the ant pushing the elephant..

Java's stated design philosophy since way back is to let other languages experiment and then incorporate what appears to work out, thus being able to maintain an append-only change philosophy where everything is always backwards compatible. Kotlin is undeniably a source of inspiration, as is many other languages.

(This doesn't always work out, some bad API decisions[1] will likely haunt Java forever, some features are arguably a bit undercooked (e.g. exception handling in Stream:s), but given the constraints it's kind of remarkable how well it does work)

[1] https://stackoverflow.com/questions/21410683/boolean-getbool...

That’s true. But why would Java take inspiration from Kotlin, which adds very little new to the picture (scala has done basically everything before, let alone ML, from where most of the new features java (or any other modern language) copies originate from)

Checked exceptions themselves to me looks like an experiment which had no place in Java. I don't know language landscape in 1990, may be it looked like a good idea back then. But today: C++, JavaScript, Python, C# are few of the most popular languages which use unchecked exceptions.

May be one day Java will just retire this concept and make all exceptions unchecked. It'll be backwards-compatible change. Make `throws` clause cause deprecation warnings and that's about it.

Checked exceptions are an unfortunate case of a feature being rolled out in a language that wasn't ready to support it ergonomically and then becoming a pariah because of how bad the experience was in that language. There's nothing wrong with the concept—checked exceptions are conceptually the same as every function returning a Result type—but without type inference and without some ergonomics like Rust's ? operator they're really hard to work with and so people grew to hate them.

I personally believe that it is now within reach for Java to fix checked exceptions to be ergonomic and useful. If they do it, Java could have one of the best error handling paradigms out of any modern language, but I suspect it won't happen because the community has come to land so firmly against checked exceptions.

Making big feature and possibly breaking changes such as making checked exceptions ergonomic would only be possible if the original language designer - James Gosling decided to dust his sleeves, un-retire himself and lead the job. Now, its a distant pipe dream.

Scala, especially

Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.

JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.

If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE.

I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.

What about the standard library? What about other libraries that you depend on? Can't those introduce NPEs?

Inputs to standard libraries will obviously never NPE if you pass in a non-null value. For outputs, a lot of standard collection .get() calls are unnecessary when you’re working with small collections or Optionals, where you simply use stream, filter, ifPresent.

Or simply wrap the return with Optional.ofNullable, checkstyle will not accept it if you don’t.

> I can’t remember the last time I encountered one by using the proper compile time checks.

When you're sufficiently careful, you can reduce accidental nulls down to the level of minor inconvenience.

But no amount of care on your part will stop your teammates from deliberately using nulls.

Code reviews usually help to stop that.

It's too embedded in the culture.

Even IntelliJ right now will tell you off for using an Optional field instead of a nullable one.

Does no good when interacting with the standard library, where things like collection methods return null for "not found". All that discipline and organization you're talking about? That's a compiler's job, and if it won't do so, I'll find a language that does. I don't spend much time griping about Java these days though, because I've had many such languages in my arsenal for some time now. Ironically in most of them I use null quite freely because it's now a distinct type and no longer a landmine.

Usually you’re using a lot of Optional and Streams, so the collection method returns null inside a .map() and you don’t need to think about it. To be clear, it is handled by the checkstyle rules at compile time, so you won’t accidentally forget.

Yeah, if you have perfect dilligence, you can work around many language's weaknesses. But we're in an imperfect world. It's not easy to influence my coworker's code style and impossible to do with other teams or people who worked on my projects in the past and left since, yet I still have to work with their code.

> then you can pretty much eliminate NPE.

NPEs is only one kind of cost incurred by the lack of null safety. The other is all the unnecessary "if (x == null) {" boilerplate code caused by the uncertainty and defensive programming, which increases complexity and worsens readability.

it's getting there https://openjdk.org/jeps/8316779

> It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value.

It's not. It's another half-feature into the collection of half-features mentioned in my post.

Thankfully, the Java Community Process works pretty well, and it's not just Oracle pulling the strings. JEPs and JSRs are the primary drivers of Change in the Java world, and they are largely driven by the Java Community Process and its many members.

Reply on news.ycombinator.com