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

Java 20 / JDK 20: General Availability

mail.openjdk.org

Post reply on HN
Print view View original

91–100 of 356 posts

Re: Java 20 / JDK 20: General Availability

#91

Post by cesarb »

vips7L wrote: post #78
cesarb wrote: post #70

Earlier quoted context omitted.

Not the parent poster, but I can see why: IMHO, the best new feature for Java was try-with-resources (Java 7), and the second best new feature was all the functional stuff in Java 8. On the other hand, Java 9 started the introduction of several breaking changes (it took years before I stopped seeing updates to Java libraries to fix their compatibility with Java 9 and Java 11), so it can be seen why someone would thin…

IMO you're neglecting the thousands of improvements in the HotSpot runtime.

You can't use any of these thousands of improvements if your software is broken because it depended on something which was removed, or changed in incompatible ways. It can take a lot of work and time until it all works fine, even more when the breakage happened deep within a third-party library, and as far as I could see, there was a lot of these breakages early on the Java 9/10/11 cycle. IMO, it's worth it to make your software compatible with the latest Java LTS release, but I can understand why some people see it as too much work for too little gain.

Re: Java 20 / JDK 20: General Availability

#92

Post by layer8 »

vips7L wrote: post #78
cesarb wrote: post #70

Earlier quoted context omitted.

Not the parent poster, but I can see why: IMHO, the best new feature for Java was try-with-resources (Java 7), and the second best new feature was all the functional stuff in Java 8. On the other hand, Java 9 started the introduction of several breaking changes (it took years before I stopped seeing updates to Java libraries to fix their compatibility with Java 9 and Java 11), so it can be seen why someone would thin…

IMO you're neglecting the thousands of improvements in the HotSpot runtime.

They aren’t critical to most applications, and are invisible to most developers.

Re: Java 20 / JDK 20: General Availability

#93

Post by baq »

dgb23 wrote: post #69
akavi wrote: post #26

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

I don't see a huge benefit for pattern matching in JS outside of it being expression based rather than statement based. Either way, the benefit has to be enormous. It's a feature that can easily break existing code.

In a world where upgrading node versions without language changes breaks existing code I wouldn’t be too worried.

Re: Java 20 / JDK 20: General Availability

#95

Post by somenameforme »

mbfg wrote: post #90

I'm curious what is meant by a "preview feature, or second preview feature, or..." in a released product?? I don't suppose they are going to remove it later. So in what way is it a preview? Are they signalling that it might have breaking changes in the future?

"A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases."

https://docs.oracle.com/en/java/javase/19/language/preview-l...

Re: Java 20 / JDK 20: General Availability

#96

Post by herculity275 »

zerr wrote: post #75
jwr wrote: post #61

As a Clojure programmer, I don't care about any of the Java language features or improvements, but I'm super happy that I'm getting a state of the art JVM that is continuously developed, maintained, extended and optimized, over a time scale of decades. This is incredibly useful: having a good VM to run your code in, with good modern garbage collectors, is not an obvious thing (as many other languages have learned). T…

The same applies to Clojure CLR, right?

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.

Re: Java 20 / JDK 20: General Availability

#97

Post by logistark »

jwr wrote: post #61

As a Clojure programmer, I don't care about any of the Java language features or improvements, but I'm super happy that I'm getting a state of the art JVM that is continuously developed, maintained, extended and optimized, over a time scale of decades. This is incredibly useful: having a good VM to run your code in, with good modern garbage collectors, is not an obvious thing (as many other languages have learned). T…

As Clojure programmer, i tell you that you should, because any moment Java introduce new features libraries will start using and most Clojure libraries are Java libraries wrappers.

In addition if you want to use these new Java libraries in case and Clojure does not catch up with new Java features the ergonomics of using Java libraries with clojure decrease.

And still they are trying to figure out how Ifn Clojure interface with Java functional interfaces.

Also when Project Loom lands on JVM it will benefit Clojure too, allowing to remove code for instance of Clojure futures.

If Clojure catch up with Value classes can increase performance of Clojure too.

But this disregard of Java features or improvements is the kind of Clojure developer so content of what he have that forgots that can get better things.

Re: Java 20 / JDK 20: General Availability

#100

Post by logistark »

taftster wrote: post #84
FalconSensei wrote: post #68

And here I am still on Java 8 :/

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…

I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.
Post reply on HN