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

Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

infoq.com

Post reply on HN
Print view View original

241–250 of 555 posts

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#241

Post by kaba0 »

pjmlp wrote: post #168
kaba0 wrote: post #134

Earlier quoted context omitted.

As for the JDKs, they are basically all just OpenJDK repackaged. Think of them more like debian’s chromium vs arch’s packaged chromium. You can generally use any.

No they are not. Azul, PTC, Aicas, microEJ, OpenJ9 are their own thing. And then there is ART. Also special stuff like Ricoh, Xerox, Gemalto, Cisco among many others using Java subsets to customize their hardware.

Sure, if we are being pedantic you are right. I meant it more like the “majority of well-known” or those with “bigger userbases”.

But the “niche” JVM category is really (perhaps surprisingly) huge.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#242

Post by the_gipsy »

jpgvm wrote: post #22
hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

Irrational Fear is actually what is waged on the Java front. People doing mental gymnastics to avoid touching anything non-Java. Cargo-culting. I've witnessed Java devs proposing changing an existing Go project's build system to maven because "that's what they know well". Straight insanity.

People that avoid Java don't do it because of some stigma, but because they have been burned before. Remember that a typical Java project is not the latest version and uses a mix of dependencies that make using newer features impossible. Then, there is no point in updating, you might as well rewrite it. That is the reality.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#243

Post by dfox »

moring wrote: post #57

The top comment in this thread [1] highlights (potential) problems with virtual threads, referring to this PDF [2]. Does anyone know if these actually manifest in the way they are implemented? [1] https://www.reddit.com/r/rust/comments/xrrjec/virtual_thread... [2] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

This is relevant to environments where the user code is statically compiled into native code that depends on some thin runtime library and more or less directly interacts with C code. In case of full blown VM many of these problems are not as significant as the internal thread state representation is non-native anyway and you can dynamically instrument pretty much whatever you want (one issue are system calls and system library functions that do not have non-blocking equivalent, but that could be handled by either having separate OS-level thread for such things or simply ignoring the issue, with real implementations doing some mix of these two approaches).

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#244

Post by kaba0 »

piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

The JVM’s GCs are the state of the art, they can definitely deal with that amount of objects easily, I doubt that would be the bottle neck.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#245

Post by kaba0 »

ddorian43 wrote: post #113
moring wrote: post #57

The top comment in this thread [1] highlights (potential) problems with virtual threads, referring to this PDF [2]. Does anyone know if these actually manifest in the way they are implemented? [1] https://www.reddit.com/r/rust/comments/xrrjec/virtual_thread... [2] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

Maybe ask in /r/java, the main developer is there (pron98).

He might just pop up here, he is a frequent HNer with username pron.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#246

Post by lenkite »

pdpi wrote: post #107
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

Java's GC has better throughput, because Go's GC specifically optimises for latency. This may or may not be the right tradeoff for you specifically, but it is a perfectly reasonable tradeoff. Jars are more portable at the cost of requiring a JVM installed on the target, whereas Go's statically linked binaries and great cross-compilation make portability mostly moot for server applications. Also, with Java 21, the JVM…

If you wish statically linked binaries and cross-compilation, you can use GraalVM https://www.graalvm.org/22.0/reference-manual/native-image/S....

Fully accept that Go has the superior cross-compilation story, though you can do this via Github actions if you really want this for Java. https://github.com/marketplace/actions/github-action-for-gra...

As for GC - Java is superior in nearly all respects. But you are right that common programming libs+paradigms in Java produce too much garbage. This has changed with lean and memory-sensitive frameworks in Java nowadays - like Quarkus https://quarkus.io/

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#247

Post by xdavidliu »

ulimn wrote: post #116
Barrin92 wrote: post #28

I haven't touched Java since school and never worked in it professionally and that's been well over a decade. Is there a resource that people recommend that gives a good introduction to modern Java? Preferably succinct but doesn't need to be.

I think the book "Core Java for the Impatient" by Cay S. Horstmann is a really good one on (relatively) new java. The author has a 2 volume, longer book as well if you want more details.

The Horstmann 2-volume series is probably the best books for someone learning Java, period. I wished there was a book like this for other languages: both comprehensive and up-to-date. For C++, I guess the closest would be Stroustrup, but even as the creator of the language, Stroustrup's books just aren't as comfortable to read as Horstmann's.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#248

Post by aembleton »

zapnuk wrote: post #225
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

A few counterpoints: - Modern Java requires heavy use of Decorators - JSON handling is tiresome - As soon as you are using Spring you aren't actually coding Java anymore - Many mature libraries have dated APIs - Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out. - Java requires a well configure IDE - However, IDE Support won't matter in a year…

> As soon as you are using Spring you aren't actually coding Java anymore

Can you expand on that. I'm pretty sure its still Java. There are some additional annotations that help with autowiring and object reuse, but probably affect the code less than Lombok.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#249

Post by okeuro49 »

Kwpolska wrote: post #32
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life featur…

Spring docs are fantastic, take for example https://docs.spring.io/spring-boot/docs/3.0.x/reference/html...

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#250

Post by wiseowise »

nickstinemates wrote: post #169
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority

I can’t believe you’ve posted this seriously.
Post reply on HN