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

81–90 of 555 posts

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

#81

Post by iforgotpassword »

jve wrote: post #56
jpgvm wrote: post #22

Earlier quoted context omitted.

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

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…

I think you can with 3rd party tools, as with Python, but why would you? If your app is literally a single executable with no additional resources, maybe it makes sense, but otherwise, just bundle the JVM like jetbrains does.

And as you mostly use Java on the backend, you're probably running Linux where a free and open jre is packaged, so just target that and not worry about it ever.

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

#82

Post by kaba0 »

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…

> The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues

How is it any different from something like RoR or Django, both of which are well-liked?

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

#84

Post by foepys »

vardump wrote: post #54
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…

"So with this, the last thing Go had going for it over Java is gone, right?" You can deploy Go app with a single binary, no runtime required. No runtime configuration.

Nowadays you don't deploy a global JRE on machines anymore. Each application has its own JRE bundled.

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

#85

Post by pjmlp »

pharmakom wrote: post #65
andresp wrote: post #47

Earlier quoted context omitted.

C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.

How so? Linux is a first class citizen in .NET these days.

A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.

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

#86

Post by fear91 »

pharmakom wrote: post #31
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…

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

Writing everyday code, Go compiled binaries are on average more performant than C#.

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

#87

Post by jve »

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.

Our employer actively tracks runtime usage and makes sure we have no O in it.

> The quantity of licenses is determined by the total number of employees, not the number of employees using the programs https://www.infoworld.com/article/3686611/oracle-per-employe...

> Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual number of employees that use the Programs. https://www.oracle.com/us/corporate/pricing/price-lists/java...

Excuse me, but isn't that a minefield?

Another point I don't want to use java: Now I have to understand what is Java SE and if the runtime falls under it or the development tools or how my users use the software, whether we now how to license every user that won't even use that program and even any people that interacts with our business. Pure maddness.

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

#88

Post by re-thc »

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 still very good for short lived tasks.

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

#89

Post by Cthulhu_ »

kaba0 wrote: post #69
yxhuvud wrote: post #60

Earlier quoted context omitted.

I'd rather think they hate it for being a word salad with lots and lots of boilerplate. Go has its issues, but that isn't one of them.

Have you seen the two languages, like.. ever? I’m sorry for the harsh language, but Go is literally much much more verbose than java, and not just recent Java that has since improved, even Java 8.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice.

Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything.

Third, it depends. You can set up a HTTP server in two or three lines in Go without 3rd party dependencies. This [1] is the shortest Java versions I've found, and it contains a lot more magic.

I'm biased in favor of Go, but verbosity is not the issue there.

[1] https://stackoverflow.com/questions/3732109/simple-http-serv...

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

#90

Post by kjto »

marginalia_nu wrote: post #52
maxbond wrote: post #48

Earlier quoted context omitted.

To be fair though M:N threads aren't the provenance of research language, Go and Rust both have them, and I'm sure some other languages. (But it's awesome Java has them now too, other languages getting the feature earlier doesn't really devalue it.)

My point is that they're on diametrically opposite ends of the language-philosophical spectrum.

.net has had this feature for a decade++
Post reply on HN