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

91–100 of 555 posts

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

#91

Post by tpxl »

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…

You can use jlink to create a custom runtime you can distribute with your application, so that your users don't need to download a JRE/JDK. You'll still need to run this with the java command.

You can use also jpackage to create an executable file you can just double-click (.exe on Windows, whatever on mac and linux).

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

#92

Post by MrBuddyCasino »

Dinux wrote: post #75
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…

Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible. Java is, like its large corporate us…

> Ever since Oracle took over Java has seen almost no improvements.

Is this supposed to be sarcasm? Because the literal opposite is true.

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

#93

Post by Cthulhu_ »

self_awareness wrote: post #26
quanticle wrote: post #15

Earlier quoted context omitted.

while Java originated the billion dollar mistake By the "billion dollar mistake", are you referring to null references [1]? But null references were introduced in 1965 in Algol, by Tony Hoare. They long predate Java. [1]: https://www.infoq.com/presentations/Null-References-The-Bill...

I don't think it's about the existence of null references, but how Java is using them. Null references can be a useful, e.g. Kotlin has converted them to be useful (with nullable types).

Using nulls in Java is mostly a choice on the part of developers; even if you can't migrate to a JVM-targeted language like Scala, you can still adopt practices like null objects [0].

[0] https://en.wikipedia.org/wiki/Null_object_pattern

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

#94

Post by kaba0 »

impulser_ wrote: post #58
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 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…

> Go is very simple language that is just as powerful as Java

I don’t think so, Go is very low on expressivity. Generics help, but I don’t see anything like JOOQ for go, just as an example. Also, no real alternative to Java’s stream api, which can at times make code much more readable than the 4 nested for loops with 4 different exits.

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

#95

Post by maxbond »

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.

Fair enough.

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

#96

Post by MrBuddyCasino »

marginalia_nu wrote: post #14
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 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.

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

#97

Post by tehbeard »

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.

Java has the lingering shadow of Oracle hanging over it.

That legalistic hydra is enough to make you second guess using it.

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

#98

Post by kaba0 »

jve wrote: post #87
kaba0 wrote: post #67

Earlier quoted context omitted.

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 employ…

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?

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

#99

Post by Cthulhu_ »

mseepgood wrote: post #40
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 has an obviously better type system How does Java have a better type system? Java's generics are unsound, while Go's generics are sound. Java's generics do type erasure, while Go does not. Java's type system is not unified, it does not have a top type (an int is not an Object, int vs. Integer etc.).

Anecdotally, but I feel like Java's type system allows me to write code that gives me more guarantees about the soundness and correctness of my codebase.

One example I can think of is Java's annotations vs Go's closest alternative, struct tags [0], which are just strings added to struct fields that specific libraries can act on; at best these are only checked at runtime, the compiler or type system will not help you with those.

[0] https://go.dev/ref/spec#:~:text=A%20field%20declaration%20ma...

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

#100

Post by mike_hearn »

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…

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 of agreement on the exact semantics and use cases. No, me neither. Or just write in Kotlin where it's all integrated with the type system and the compiler understands / hides from you the Java annotation mess.

- Testing libraries: it's been quite a long time since I encountered anything except JUnit 4 or 5, but they interoperate so that's no big deal. JUnit 5 is great and very standard so you can't go wrong by picking it.

- Concurrency libraries/concepts: yes this is a problem but it's one found in other ecosystems, and it's one the new virtual threads are designed to solve. The hope is (and I guess we'll see) that everyone can forget about coroutines and reactive programming now, at least where performance matters, and go back to writing old fashioned ordinary threaded code. I guess they'll stick around in Jetpack Compose GUI programming.

- Lots of different JDKs. That is indeed new and unfortunate. They don't actually vary much, mostly in how long major versions remain supported. Amazon is a sort of default choice unless you're doing GUI work, in which case JetBrains Runtime has lots of desktop specific patches.

- Startup time/memory usage. There are simple things that can be done to improve this (see AppCDS). Some of it is cultural however, the people who write CI servers probably don't care about startup time. IntelliJ for example starts pretty fast in the latest versions, because they care to optimize it. For memory usage, be aware that the JVM will default to using most of your free system RAM even if it doesn't need to. It figures hey, the RAM is free, so why waste CPU time and energy on garbage collecting if I don't have to. If you planned to use the RAM for something else, or conclude that this is the "natural" level of RAM usage, it can be annoying however. You can give it a limit or in recent versions set a flag that'll cause it to regularly run GC when the app is idle, to give back memory to the OS.

Post reply on HN