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

161–170 of 555 posts

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

#161

Post by surfsvammel »

re-thc wrote: post #88
surfsvammel wrote: post #74

Every time something show up about anything related to Java, the discussions turn to this flame war about what language are better or worse than Java. Why can’t we just discuss the article at hand? In this case, I’d love to hear more from experienced Java developers, with existing code-bases, who have tested these new virtual threads out.

A lot of work still needs to be done on the libraries and other tools before it's useful for end users. We've spent years migrating to "reactive frameworks" or being stuck in "legacy". Virtual threads isn't just something to "enable". You do need to adapt existing codebases somewhat e.g. use of synchronization. The upcoming future is likely a mix of reactive and virtual threads where appropriate. Virtual threads is s…

The application that we are working on uses thousands of platform threads today (split over a handful of applicationservers). It’s a humongous banking system. I have been working on performance related improvements for years. I am now curious if these new virtual threads might be beneficial for us in some places. Need to read up on them a bit more

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

#162

Post by pjmlp »

MrBuddyCasino wrote: post #96
marginalia_nu wrote: post #14

Earlier quoted context omitted.

I think there are still a few changes in the pipe before Java is quite what it could be in terms of performance. Project Valhalla, and the foreign function and memory APIs in particular.

I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.

Native interop is everywhere on Android, but then again, good luck having updated Java features on ART.

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

#163

Post by DrScientist »

datadeft wrote: post #45
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.

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20 years and Go for ~2. I am not actively hating Java but I value my time, specially that was wasted on maven + co.

Maven isn't Java.

I've used java for over 20 years and managed to almost completely avoid it.

As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc.

Madness.

If you do dependency management at the source level ( using the compiler.... ) then life is generally much simpler ( reflection being the only aspect you need to manage ).

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

#164

Post by josefx »

kaba0 wrote: post #67
jve wrote: post #56

Earlier quoted context omitted.

Can you compile so that JRE is bundled with the program? I'm a C# developer and I also have a kind of resistance of java - having to install JRE and now the minefield Oracle made with the JRE, I'm hoping not only that I don't have to code in it, but that I don't have to use ANY Java program just to avoid the runtime or have to choose between different versions of it. And then the .jar files and how you execute them i…

Yes, there is in fact not even a JRE for quite some years now. Also, Oracle being a minefield is just bullshit - they are the ones that open-sourced the platform completely to the point that their paid version is only marginally different, but OpenJDK is the reference implemented. They are surprisingly good stewards of the language.

> they are the ones that open-sourced the platform completely

While I agree with the bullshit claim, Sun was the company to open source Java. Which itself goes back to IBM blocking the community process in order to force an Apache licensed Java implementation, Sun releasing the OpenJDK made most people happy without killing its embedded cash cow.

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

#165

Post by spion »

pjmlp wrote: post #157
spion wrote: post #153

Earlier quoted context omitted.

Kind of, but not quite. There is also: - compiling to a single binary (I guess jpackage fixes this) - saner / less elaborate / more ergonomic interfaces to implement and use e.g. compare `io.Reader` ( https://go.dev/tour/methods/21 ) to the Java equivalent

Several commercial JDK options have offered compiling to single binary for 20 years, even if out of reach for common folks. GraalVM and OpenJ9 now make it available as free beer as well. https://docs.oracle.com/en/java/javase/20/docs/api/java.base...

Is that the modern Java equivalent of the single-method interface in Go? I can see its an abstract class - what do you do if you want to implement both Reader and Writer?

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

#166

Post by pjmlp »

FooBarWidget wrote: post #25
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…

As someone who recently developed in Java (for developing a Jenkins plugin) after not having done so for a long time (~15 years), I feel that Java nowadays is technologically quite interesting with many interesting libraries and tooling. IDE code navigation and debugging support is excellent. At the same time, the ecosystem can feel messy and overwhelming. There are multiple @Nonnull annotation libraries and it's not…

Because Java is an industry standard, just like C, C++, Ada, JavaScript,... so many vendors want to provide their own take on JIT, AOT, GC implemetations, specially for niche areas like hard real time embedded deployments, where no other GC based language competes with Java, at least at the same deployment scale.

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

#167

Post by wiseowise »

surfsvammel wrote: post #64
impulser_ wrote: post #58

Earlier quoted context omitted.

I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so p…

It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.

It’s hard to find quality people who want to write Java.

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

#168

Post by pjmlp »

kaba0 wrote: post #134
mike_hearn wrote: post #100

Earlier quoted context omitted.

Hi there ;) Knowing you, I'm sure you've got it all figured out by now but for any others who are reading: - Nonnull annotations: you can pick any. Tooling doesn't care and tends to just accept any annotation with a name like @Nullable or @Nonnull regardless of namespace. There was an attempt to standardize this years ago which failed for reasons that are hard to understand from the outside, something to do with lack…

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.

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

#169

Post by nickstinemates »

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

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

#170

Post by kaba0 »

jve wrote: post #145
kaba0 wrote: post #98

Earlier quoted context omitted.

Are you using Photoshop without a license as well or how is that relevant? This is about Oracle’s JDK you specifically have to install and have a paid license to (actually, they also provide a free version if you stay on the latest LTS release at all times), and is meant mostly for governments and such. Will you uninstal linux because Red Hat has a paid support version as well?

So if i have JDK (Which I must) I do have to buy those licenses.. for all our employees? > The Java Platform, Standard Edition (Java SE) and Java SE Universal Subscription from Oracle include the Java Development Kit (JDK), and Java Runtime Environment (JRE) https://www.oracle.com/java/technologies/faqs-jsp.html#:~:te... . Do I not need the Java SE subscription to use JRE? Do I not need the Java SE subscription to us…

Do you have to buy a license for a regular Linux kernel? No. The exact same is true for OpenJDK. Just download any, for example one that is packages by your distro, or there is sdkman for developers to let you quickly choose from multiple vendors and any version.
Post reply on HN