Live data from Hacker News

Java 20 / JDK 20: General Availability

mail.openjdk.org

341–350 of 356 posts

Re: Java 20 / JDK 20: General Availability

#341

its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var

'The world' in this case also includes a large portion of java programmers; it takes years for Java programmers to adopt new language features, if they do so at all. They're almost as bad as C++ devs.

And if you consider the history of Java as a language since the 1990's, it has historically had very slow feature releases. If you review the release history of Java, almost half of major relases and changes to the language came after 2014+. var in Java came out in 2018, record was introduced out in 2020 - feaures that were copied from other languages that already had them for years. Java as a language is still is playing catchup here.

Re: Java 20 / JDK 20: General Availability

#342
post #334

Earlier quoted context omitted.

> M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is I'm not very into this Loom virtual threads thing, but... what's the difference between this automagically conversion of blocking into non-blocking in a M:N model and a 1:1 one? I mean, couldn't the same be done with normal threads too?

Well, to a degree this is also done by the OS, IO syscalls are frequent locations where the OS scheduler might decide to schedule another thread, but this is a very slow context switch (flushing caches, including TLB, the switch to kernel mode and back, and since heartbleed and alia it is even more expensive). Loom implements every IO on top of a more modern async OS calls, and these virtual thread context switches a…

Thanks!

Re: Java 20 / JDK 20: General Availability

#343
post #274

Earlier quoted context omitted.

I use Clojure, which benefits from these consistent JVM improvements; things like pattern matching have been accessible to me for years already, but I like that Java slowly trails along as it helps keep me vested in the Java ecosystem.

By contrast I despair of Clojure ever keeping pace with Java updates. Clojure seems to be a functional language which isn't even implemented using the host's functional features which were introduced 9 years ago.

I guess that only matters if we're missing out on performance improvements by not using native language features; be cool to see if anyone has done any profiling/investigation on that.

Clojure the language isn't missing anything I need.

Re: Java 20 / JDK 20: General Availability

#344

Earlier quoted context omitted.

This is 2023 and you are saying that Microsoft is less ethical than Oracle. A lot of things have happened since the 90s, you know?

Sure things changed. But some things will stay the same 'till end of time. Like Oracle and M$.

Or you forming an opinion 30 years ago and never changing it.

Textbook definition of "closed minded".

Re: Java 20 / JDK 20: General Availability

#346

its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var

'The world' in this case also includes a large portion of java programmers; it takes years for Java programmers to adopt new language features, if they do so at all. They're almost as bad as C++ devs. And if you consider the history of Java as a language since the 1990's, it has historically had very slow feature releases. If you review the release history of Java, almost half of major relases and changes to the lang…

>>Java as a language is still is playing catchup here.

It's a feature, not a bug.

Re: Java 20 / JDK 20: General Availability

#347

Earlier quoted context omitted.

Sure things changed. But some things will stay the same 'till end of time. Like Oracle and M$.

Or you forming an opinion 30 years ago and never changing it. Textbook definition of "closed minded".

Those companies do the exact same thing (or even worse!) as 30 years ago.

Of course nothing changed; besides the concrete wording of the PR and marketing materials.

So there is no reason to change any opinions.

Actually M$ got even more dangerous since than as they stopped to fight OSS and switched to their infamous and in this case even more concerning EEE strategy.

But sure, I know some people get blinded by their marketing efforts and don't look to close what this companies are actually doing.

Re: Java 20 / JDK 20: General Availability

#348
post #57
post #46

Earlier quoted context omitted.

This year. Six months from today.

(just on the following up on this) https://en.wikipedia.org/wiki/Java_version_history The non-LTS releases are every 6 months and have support for one year. LTS releases are every 4th release which falls on odd numbered years in September.

> The non-LTS releases are every 6 months and have support for one year.

Not exactly, they are supported for 6 months (well, till the next JDK release) at least the builds on jdk.java.net page. Other vendors might provide different support.

Azul for example supports some releases (13 and 15) for 3.5 or 2.5 years (MTS)

Re: Java 20 / JDK 20: General Availability

#349
post #70
post #33

Earlier quoted context omitted.

Why? Java 11 is already leaps and bounds better than Java 8.

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…

> as earth-shaking as the changes we got with Java 7

7 didn't introduce anything earth-shaking (just try-with-resources), lambdas were earth-shaking, just like records and switch expressions are.

Re: Java 20 / JDK 20: General Availability

#350

Earlier quoted context omitted.

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.

There would be a world for this argument if the CLR had anything even remotely resembeling hotspot runtime optimization. What you describe is the result of different philosophies/priorities. CLR focuses on static compile-time optimization, while the JVM is a highly dynamic construct with unmatched runtime analysis. In the 90s, there was a hope that with sufficient escape analysis, the need for user-defined primitives…

> What you describe is the result of different philosophies/priorities

Maybe, it might also be the results of bad design decisions.

> highly dynamic construct with unmatched runtime analysis

As someone who spend quite a bit of time working on custom optimization around hotspot, i failed to see how anyone can describe the current state of the JVM ( J9 is a bit better) as unmatched. V8 and some some extend Julialang have much strong dynamic analysis.

> CLR focuses on static compile-time optimization

Sources ?

Post reply on HN