Live data from Hacker News

Java 20 / JDK 20: General Availability

mail.openjdk.org

181–190 of 356 posts

Re: Java 20 / JDK 20: General Availability

#181

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]: case Tuner t && guitar.isInTune() -> ...; and case Tuner t if guitar.isInTune() -> ...; both seem as clear as case Tuner t when guitar.isInTune()…

I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our ca…

Thank you, that's excellent insight into the thought process for the same feature at about the same time.

You mention about the human-centred nature of syntax design... do you have any instinct for why one route vs another felt right to users? Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

Re: Java 20 / JDK 20: General Availability

#183

Earlier quoted context omitted.

I haven't looked into CLR in a long time, but it feels like it has a fraction of JVM's adoption and community size. Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves.

At the risk of starting a flame war, the CLI and the coreCLR are fare superior VM and platform from a technical stand point. A lot of the features schedule for jave 21 / project Valhalla are just basically catching up to modern VM design. Of course there is more to the choice of a platform than just the technical differences.

The Java JVM was originally designed with a very dynamic language in mind, e.g. Java's support for dynamic loading, dynamic binding, reflection etc. The influences at the time were Smalltalk and ObjectiveC. As Java has evolved to be a much more statically typed language (especially Java 5), the JVM has somewhat struggled to exploit this while maintaining backwards compatibility. It's nowhere near as bad as the Python situation though. I believe the CLR was built with things like parametric specialisation in mind from the beginning.

Re: Java 20 / JDK 20: General Availability

#184

As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.

It's really not as bad as it used to be. I recently picked it up again after playing with Spring boot. I got to say Spring boot seems awesome, and java as a whole it much more ergonomic. Worth another look.

Re: Java 20 / JDK 20: General Availability

#185

Earlier quoted context omitted.

Don't worry, someone will still manage put in a bug that results in a zero day in the next 2 years.

While the Java community has had some high profile vulnerabilities, I can't recall a major one that was actually tied to the JVM itself since dropped applets. Instead it's usually a popular library or framework.

> I can't recall a major one that was actually tied to the JVM itself since dropped applets.

Not exactly tied to the JVM, but IIRC one of the prerequisites for the Spring4Shell vulnerability was the existence of a new method added by Java 9. If you were still on Java 8, you were not affected.

Re: Java 20 / JDK 20: General Availability

#186
post #174

What are some good primers to understand the prominent new Java features? Not just in 20, but since, say, 8. Asking as someone who would like to be cursorily familiar with Java, but does not use it day to day. I'm very familiar with things like auto type inference, pattern matching, multi-line strings and structured concurrency from other languages, so I'm not looking for an introduction to Java. I'm looking for some…

Here are some resources I've found helpful and have read or are on my backlog to catch up with these developments:

- https://github.com/wesleyegberto/java-new-features (terse, includes links to JEPs, good jumping off point)

- https://github.com/winterbe/java8-tutorial (quick tour through features of Java 8)

- https://winterbe.com/posts/2018/09/24/java-11-tutorial/ (same for Java 11)

Books:

- Java 8 in Action / Modern Java in Action (Raoul-Gabriel Urma, Alan Mycroft, Mario Fusco; 2014 and 2018 respectively)

- The Well-Grounded Java Developer (Martijn Verburg, Benjamin Evans, Jason Clark; 2022) - not specifically focused on new features but does cover them in the context of going deeper into Java and the JVM.

Re: Java 20 / JDK 20: General Availability

#187
post #166
post #149

Earlier quoted context omitted.

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…

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 si…

My main dependency only supports jdk 8 soooo...

Re: Java 20 / JDK 20: General Availability

#188
post #135

Earlier quoted context omitted.

I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company th…

There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto…

Isn't 202 the last version?

Re: Java 20 / JDK 20: General Availability

#189
post #177
post #174

What are some good primers to understand the prominent new Java features? Not just in 20, but since, say, 8. Asking as someone who would like to be cursorily familiar with Java, but does not use it day to day. I'm very familiar with things like auto type inference, pattern matching, multi-line strings and structured concurrency from other languages, so I'm not looking for an introduction to Java. I'm looking for some…

Boring answer... but Chat GPT? I asked it what was new in Java 8 and it enumerated a number of features. I could proceed to ask it about more details for each, and then continue Java version by version and I think it would be quite exhaustive. The other day I did something similar for cell biology. As a layman I wanted to learn more about DNA, mRNA, tRNA, translation, transcription, mitosis, miosis, etc. I think I le…

Thanks! I keep forgetting to reach for this.

Re: Java 20 / JDK 20: General Availability

#190
post #173

Really excited to see how virtual threads are taken up by developers, and if they affect the larger programming language community. They just really seem like "the best of both worlds" to me: the high scalability/low resource usage of async/await, with the ease-of-use experience of threads (e.g. not having to worry about "function coloring").

I'm personally not so sure. We already had something like that before (M:N threads), and the world moved away from it, towards letting the kernel manage everything (1:1 threads). So I'd expect instead that operating system kernels gain whatever features are missing for scaling to a higher number of threads, and everything once again goes back to each programming language thread corresponding to one kernel thread.

M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is - which has not really been tried before (with erlang and go being the first).
Post reply on HN