Hacker News Reader

Comment by SPBS | Hacker News Reader

My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type.

I'd still upgrade for the new VM's better performance/security patches or whatever, but I don't need any language changes.

View on HN

I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default since forever.

Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them:

- `var` local type inference

- record classes

- text blocks

- switch expressions

- sealed classes and interfaces

[1] http://paulgraham.com/avg.html

My main dependency only supports jdk 8 soooo...

Var is nice. But I generally prefer to not require people to jump out of the current code to figure out the type of a variable. And yeah, I've worked in those other languages, and navigating unfamiliar code with var everywhere can be confusing, so I try to avoid that kinda thing.

Records are nearly useless to me. Immutability is great, but I need a way to derive new sets of information based upon an set of information. And the only way to do that is bug prone.

Text blocks are nice for writing SQL queries and other multi-line things. But I'm not sure how often I actually use it.

Switch expressions are nice because it gets me compile time checking for things I would previously use a runtime check for. Other than that, as they currently exist, they're meh.

Sealed classes are something I've not had a use for. Maybe libraries will eventually make good use of them.

So I would say there's some nice QOL things in here. But I think "incredibly useful" is overselling it.

The thing is, lots of these things are built to support a longer term roadmap towards better support for data oriented programming. I think that is a worthwhile goal to drive for - and the sum of the parts (many of which are still in preview) will be less than the whole together - but we don't have the whole, yet. That, to me, would pass the "incredibly useful" bar.

`var` in Java is local for a reason. In most contexts I can think of the variable either was created above or was passed in as a parameter/object field. Unless you set it from a weirdly named creation pattern/function.

Regarding records, you never had someone update a POJO, add a field, and forget to update equals and hashCode?

Sealed classes are great for everything parsing/validation, in data modelling. They're not a solution for behavior polimorphism, but I don't think they were supposed to.

People think boring is good but it’s not. Simplicity is good. Boring is just what you’re familiar with.

New features done right improve simplicity by abstracting away complexity or need to reinvent the wheel. For example Go devs having wrote their own list .map() functions is absurd.

We migrated our codebase because multi line string literals somewhere in jdk14 made writing large SQL queries in java code so much easier.

Big reason is security patches. But if the services are running in a VPN and don’t interact with outside world, it’s fine

My understanding is that jdk8 has support from Oracle until 2030.

paid support. I’m not convinced that most of those companies that use older versions even know where their JDK comes from.

Reply on news.ycombinator.com