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

281–290 of 356 posts

Re: Java 20 / JDK 20: General Availability

#281

Post by DannyBee »

xyzzy4747 wrote: post #260
DannyBee wrote: post #253

Earlier quoted context omitted.

It's highly amusing to watch java folks frame this as the rest of the world not "keeping up" when it's pretty obvious it's the rest of the world not caring enough to do anything about it. I wonder how long it will be before they realize they are in the slow, sad, decline regardless of how many features get added.

I think this is true for young companies - for example every crypto startup I’ve interacted with makes their backend in either Node.js, Golang, or Rust. There is quite a lot of legacy software that uses Java though.

Sure, no doubt there. Where i work has hundreds of millions of lines of java code, and i was the director responsible for the java team for years ;)

But:

1. The enterprise users aren't spending their time chasing java versions, and probably already gave up and have a support contract with Azul or someone, or just stick with an unsupported versions.

This is why all the cloud vendors, for example, either have such deals, or provide their own guarantee of support.

So they almost certainly do not care about Java 20 anytime soon unless they are in the weird category of "serious java shop" (rather than legacy java shop), which is quickly shrinking. That is not a big enough class that people will "try to keep up" to frame it in the java-centric version used by GP.

2. The non-enterprise users are also a shrinking base.

Re: Java 20 / JDK 20: General Availability

#282

Post by yCombLinks »

digitalsanctum wrote: post #144

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.

Nearly all of the language changes except for the thread changes are minor quality of life things.

Re: Java 20 / JDK 20: General Availability

#283

Post by hota_mazi »

twobitshifter wrote: post #155
DonHopkins wrote: post #88

Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.

C#, owned by the most ethical company in software. Java is very different and much improved from when c# branched off, but many people haven’t been following along and still think it’s the same as in 2002.

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?

Re: Java 20 / JDK 20: General Availability

#284

Post by [deleted] »

pkolaczk wrote: post #227
hn_throwaway_99 wrote: post #163

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").

> low resource usage of async/await Will calling a coroutine do zero heap allocations like async in Rust? > with the ease-of-use experience of threads That's highly subjective. Threads usually require locking which is often hard to get performant and correct at the same time. Async/await allows to write concurrent code with no synchronization.

[deleted]

Re: Java 20 / JDK 20: General Availability

#285

Post by re-thc »

cesarb wrote: post #263
mike_hearn wrote: post #236

Earlier quoted context omitted.

The problem of scaling threads up further is fundamental and not really solvable by more kernel features. JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. The kernel can't do any of these things - it has to assume a process is a black box that could do anything wi…

> JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. Forgive me for staying doubtful, but I recall hearing this same "the JVM can be very fast and efficient because its JIT has complete knowledge and control" spiel back in the 90s, and back then, anyone could clearl…

The JVM is comparable to pre-compiled native code these days. It has evolved and improved since the 90s.

Re: Java 20 / JDK 20: General Availability

#286

Post by re-thc »

koito17 wrote: post #268
kaba0 wrote: post #216

Earlier quoted context omitted.

Im what aspect is the VM “far superior”? Where are CLR’s state-of-the-art GC or low-level GC? Or does it have observability tools like JFR?

I do not use C# (in fact, I do my best to avoid Microsoft products). But I can tell you that there are obvious workarounds C# employs to work around its lackluster GC. Stack allocation and spans immediately come to mind. As far as I know, Java offers no way to mark objects as stack-allocated, but C# does. Spans in C# allow programmers to produce subarrays without copying. Enums in C# are stack-allocated, unlike Java.…

In Java, primitives go on the stack. Escape analysis helps in other ways.

Re: Java 20 / JDK 20: General Availability

#288

Post by bcrosby95 »

kasajian wrote: post #287

Why is it difficult to determine what those features are 429, 432, 433, etc. How difficult would it have been to put links there so one can click on the link to see what it is. Have these people hard of hyper-text markup?

https://openjdk.org/projects/jdk/20/

It's linked in the email.

Re: Java 20 / JDK 20: General Availability

#289

Post by za3faran »

EVa5I7bHFq9mnYK wrote: post #152
oaiey wrote: post #120

Earlier quoted context omitted.

With all my love for .NET, why not continue Java with its new features when it fits to your developer base, existing products etc. Give it one or two more years and Java is where C# is ... also aesthetically. As did JavaScript.

The feature that everyone is excited above - switch statement with pattern matching - has been available in C# for 6 years now.

C# doesn't have exhaustive pattern matching yet.

Re: Java 20 / JDK 20: General Availability

#290

Post by cozos »

cesarb wrote: post #263
mike_hearn wrote: post #236

Earlier quoted context omitted.

The problem of scaling threads up further is fundamental and not really solvable by more kernel features. JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. The kernel can't do any of these things - it has to assume a process is a black box that could do anything wi…

> JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. Forgive me for staying doubtful, but I recall hearing this same "the JVM can be very fast and efficient because its JIT has complete knowledge and control" spiel back in the 90s, and back then, anyone could clearl…

It's been a while since I read up on this, but my understanding is that with OS threads, during a context switch it has to pop the entire process stack, which in Java is 1MB by default. This is expensive. Virtual threads "context switches" have much more lightweight stacks because the JVM knows exactly what kind of state needs to be associated with the virtual thread and thats where the difference lies.
Post reply on HN