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

https://www.infoq.com/news/2023/04/virtual-threads-arrives-jdk21/

by ivanche • 3 years ago

310 525 3 years ago

infoq.com

pantulis• 3 years ago

Are these green threads?

-- edit myself: no, it can't be. JVM had green threads since eons ago, according to wikipedia.

-- edit again: this SO thread --pun intended!-- explains it

https://stackoverflow.com/questions/74639116/what-is-the-dif...

HippoBaro• 3 years ago

Yes, these are user land threads. Sometimes they are also called fibers, green threads, virtual threads, or stackfull coroutines.

Valodim• 3 years ago

That's pretty confusing without some more context, yeah. Not the best article in this regard.

In fact, in very early Java versions, the JVM threads were multiplexed onto OS threads (also known as platform threads), in what were referred to as green threads because those earliest JVM implementations actually used only a single platform thread.
However, this single platform thread practice died away around the Java 1.2 and Java 1.3 era (and slightly earlier on Sun’s Solaris OS). Modern Java versions running on mainstream OSs instead implement the rule that one Java thread equals exactly one OS thread.

https://blogs.oracle.com/javamagazine/post/going-inside-java...

flockonus• 3 years ago

I found the StackOverflow accepted answer to be a very clear explanation, it summarizes and re-iterates what matters: "With Virtual Threads, multiple virtual threads can run on multiple native threads (n:m mapping)"

dfox2• 3 years ago

JVM was originally designed to run as a single thread because of bunch of factors that were relevant at that time:

It was originally designed to run on embedded-ish platforms without any real OS. And in such an environment it makes perfect sense to do threading at a VM level (also implementing it that way is not that hard for bytecode interpreter, as additional bonus you don't have to think about issues like concurrent accesses to internal structures of the VM and stopping the world for GC).

The time when Java was designed more or less overlaps the time when first "mainstream" operating systems with OS-level threads (ie. Windows NT and Solaris) were also designed, so it could not exactly assume that underlying target supports OS-level threads. For client platforms you had Classic MacOS and 16bit windows both with multitasking models where the concept of thread does not really make sense and Windows 95 with NT-derived Win32 API with real threads. In server space you had various Unix flavors that migh or might not have OS-level threads but these that had threads had mutually incompatible APIs and then you have "Network Operating Systems" (eg. Netware) that were marketed in a way that presented absence of real multitasking as an "performance benefit".

In this 90's environment typical large application that was intended to be portable included somewhat extensive platform abstraction library that more often than not included implementation of something similar to green threads (with POSIX standartizing ucontext_t and friends as an portable-ish API to built such a thing on). You can probably find remnants of such an layer in Firefox code to this day (and probably in other large originally proprietary software packages that were then opensourced).

namdnay2• 3 years ago

hopefully this will mean the end of Reactor Core and all that craziness

MrBuddyCasino4• 3 years ago

I'll drink to that.

noelwelsh• 3 years ago

Next stop, tail calls plz.

JonChesterfield• 3 years ago

Tail calls make stack traces harder to read and it looks from the outside like java development is primarily about reading stack traces

aembleton4• 3 years ago

The strange thing is that the JVM can handle them because Scala and Kotlin have them. Java though, doesn't.

aardvark1792• 3 years ago

Scala and Kotlin just implement them using a trampoline, the JVM does not itself support tail calls.

TheDong2• 3 years ago

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 comparable compile times.

I guess at this point the only major difference is that you can teach a 3 year old to write Go more easily, so ChatGPT produces correct Go more easily than Java, and the dependency management story differs a little (though I don't think you can really call a winner or loser on that one, it's just different)

ape4• 3 years ago

ALGOL originated null

TheDong2• 3 years ago

In ALGOL it was more like a thousand dollar mistake. It didn't become a billion dollars until Java caused NPEs on 3 billion devices

hintymad• 3 years ago

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.

jpgvm5• 3 years ago

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

jeroenhd• 3 years ago

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch.

In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versions, with ancient libraries, full of code nobody dares to touch in case something collapses. The same will happen to Go, and it'll happen to whatever popular language will displace Go as the trendy language to learn; it's just a consequence of keeping around legacy code and not spending the time and money on migrating as soon as possible.

datadeft6• 3 years ago

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.

yxhuvud• 3 years ago

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.

miohtama• 3 years ago

It's also older generation, those who worked with Java in 00s and 10s and got experienced with Java.

tsss3• 3 years ago

The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.

marginalia_nu18• 3 years ago

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.

MrBuddyCasino4• 3 years ago

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

kaba060• 3 years ago

For non-trivial problems GC performance will be much more important, and Java will beat out go in that category with flying colors.

quanticle• 3 years ago

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

self_awareness• 3 years ago

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

saurik• 3 years ago

Speaking of Go and Algol...

http://cowlark.com/2009-11-15-go/

the-smug-one• 3 years ago

So with this, the last thing Go had going for it over Java is gone, right?

No. Go does containerized microservices better because of its lower memory footprint. If you can use GraalVM then that might not matter.

threeseed2• 3 years ago

This is based on outdated advice.

Java stacks like Quarkus [1] have memory as low as 12MB and JVMs like OpenJ9 natively support CRIU for instant startup.

[1] https://quarkus.io

[2] https://blog.openj9.org/2022/10/14/openj9-criu-support-a-loo...

winrid• 3 years ago

You can configure the GC to give the memory back to the OS after a short interval. We do this at FastComments with Shenandoah for our pubsub system.

darthrupert• 3 years ago

Java will always have Java syntax, though. And its runtime will remain rather heavy compared to language implementations that compile down to machine code. Go's benefit's will probably always be there.

Java can be taught to 2-year olds so Go seems to have a slight disadvantage there. ;)

jbverschoor• 3 years ago

Java Card on smart cards?

kaba060• 3 years ago

Very subjective, but having Java syntax is an advantage compared to goddamn Go — like I have seen my fair share of languages and can generally “read” a new language’s code sample just fine, but go was honestly quite hard the first time with their stupid type, “receiver” etc notation. And I have honestly no problem with Haskell/Lisp/C/etc notation at allz

FooBarWidget• 3 years ago

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 clear what the difference is. There are many different testing libraries (some TDD, some BDD) but it seems everybody picks a different one. There are multiple advanced concurrency libraries and concepts, but again not much consensus and everybody uses a different one. Lots of deprecations all over the place.

It's even worse in the Jenkins-specific ecosystem where nearly every plugin uses some deprecated aspect of either Java or Jenkins, and hunting for what the "right" way is supposed to be is a bit of a daunting task.

There are like 20 different JDKs, not sure why.

On the other hand, startup time and memory usage still seems to be a big issue. Starting Jenkins takes forever even with JVM in client mode and with bytecode verification disabled. And when started it uses a huge amount of memory. To date I've never seen one non-hello-world Java app that isn't like that.

mike_hearn5• 3 years ago

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.

pjmlp14• 3 years ago

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.

pizza234• 3 years ago

What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.

mike_hearn5• 3 years ago

Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup.

There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it.

Then there is GraalVM Native Image. It can compile JARs to native code ahead of time. They start as fast or faster than the equivalent C program, so it's the big hammer for CLI tools. However, it can't cross compile so you have to compile for the target system on the target system. There can also be compatibility issues with some libraries, though that's getting better rapidly.

So those are the options. Still, even without those extra features, startup time is usually good enough.

DaiPlusPlus3• 3 years ago

On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-ish environment (Prefetch, IO caching, etc)

Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.

aembleton4• 3 years ago

Just tested on an M1 Macbook Pro and it took 148ms

I have a tool I created that creates a git branch based off a Jira ticket number. If I don't supply a ticket number then it errors out straight away, so I think most of that 148ms is the JVM starting up.

pharmakom3• 3 years ago

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.

andresp• 3 years ago

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

DaiPlusPlus3• 3 years ago

C# doesn’t really have an equivalent for Go’s channels syntax though.

Also, Go doesn’t have inheritance, but does have interface forwarding and structural (as opposed to nominative) type-system - those both very significant factors that influence final program design.

foepys4• 3 years ago

To be fair, .NET only recently got AOT compilation and single binary (or self-contained) deployments as officially supported features.

fear91• 3 years ago

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

Kwpolska7• 3 years ago

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 features (properties and operator overloading, for example). It often suffers from design-by-committee (e.g. https://openjdk.org/jeps/430 ).

And then you get to the web frameworks. The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues.

kaba060• 3 years ago

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?

Cthulhu_5• 3 years ago

I would say that Go's error handling is a billion dollar mistake as well.

I think you'll need to substantiate that one with some solid evidence. I don't see anything wrong with Go's error handling that cannot be explained by developer choice.

vincnetas• 3 years ago

I have my complaints about Spring, but bad docs is definitely not among them. What do you consider a good docs?

ilamparithi• 3 years ago

when it comes to full stack frameworks, Micronaut(https://micronaut.io/) is actually good and pleasant to work with.

okeuro49• 3 years ago

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

Un1corn• 3 years ago

This is a pretty terrible comparison, suitable for those X-vs-Y websites. While on paper Go and Java have a lot in common, in practice their philosophies differs enough to produce different enough languages.

I've used both Java and Go and I can tell you, there is no right or wrong but they differ a lot in their ecosystem, tooling and in design patterns. I don't see myself going back to Java because of the virtual threads.

datadeft6• 3 years ago

It would be great to have a language that is a love child of Erlang and Rust. All I need is: repl, message passing, actor model, lightweight-threads and strong types. :)

kaba060• 3 years ago

Scala? A good contender might be OCaml as well.

hugofirth• 3 years ago

I wish Swift wasn’t so tied to the Apple ecosystem, as it has (IMO) a good mix of these

brabel2• 3 years ago

The love child of Erlang and Rust exists already: Pony.

https://www.ponylang.io

It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D.

But if that's really what you want, Pony is your language. It definitely deserves more love.

rakoo3• 3 years ago

Are you looking for pony (https://www.ponylang.io/discover/#what-is-pony) ? Never tried it, but it does have actors, reference capabilities (in short, "who can get this piece of memory and what can they do with it") but sadly no repl. There is a playground though (https://playground.ponylang.io/).

birdfood• 3 years ago

https://gleam.run is a statically typed language on the BEAM

mseepgood• 3 years ago

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

kaba060• 3 years ago

Haskell’s type system does type erasure, is it “worse” for that?

Cthulhu_5• 3 years ago

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

lenkite11• 3 years ago

Java methods support type arguments. Go methods do not leading to convoluted gymnastics for straightforward behaviour.

Java's type system is not unified, it does not have a top type

Neither does Go for that matter.

Go's lack of visibility modifiers and package scope namespace cause very common gotchas mentioned in https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-....

There is a Manning book about Go: https://www.manning.com/books/100-go-mistakes-and-how-to-avo... . And these are not rare mistakes. Everyone makes them and some of those mistakes are repeated again and again in every Go project. (Esp the for-loop ones). I have found programming in Go needing the kind of alert, defensive mindset I adopt for C++ which is quite exhausting. Not so much for Java.

However, to be honest, Rust is probably the only the language where you can relax your "defect-analysis" mind thread while coding - with the exception of async Rust.

za3faran6• 3 years ago

Java has records, pattern matching, and proper enums.

As of writing this comment, golang does not allow you to have generics on methods as far as I'm aware.

samuell• 3 years ago

Will they provide automatic M:N multiplexing on OS threads, or is that something that needs to be handled by the user somehow?

Also, what about channels, and select semantics etc?

I think before those are in place, with good library support, it won't be very close to competing with Go.

Not to mention compilation to fully self-contained binaries.

kaba060• 3 years ago

Will they provide automatic M:N multiplexing on OS threads

Yes, you can set the number of OS threads they can use.

Channels and alia have been implemented in Java’s standard library for many many years, it doesn’t need additional language features.

bhawks• 3 years ago

The linked article has zero references to golang, so it's unclear if the java community has other golang features they're planning on buying into.

This change improves Java/JVM capabilities and that's great. Java is a great language and it's nice that it is shaking off the stagnation/perception of stagnation it has acquired over the years. Golang also has really great capabilities and use cases. Having written tons of code in dozens of languages it seems to be folly to expect one language to rule them all. The features that you don't have are almost as important as the features you do have.

If Java is looking for additional golang cherrypicks I would love to see their start times improve (shortlived java processes are painful, Graal doesn't cover all uses). FFI even in Panama is much more boilerplate then CGO. Go's deployment story is so much cleaner and straightforward then Java. The amount of engineering hours saved through language/toolchain standardized formatting is just monumental. Those are just 3 things at random, their are a bunch of other great ideas to steal.

I also wouldn't throw any shade at Golang's vibrant library ecosystem. There are just so many great active projects written in pure go that make spinning up new services a joy.

za3faran6• 3 years ago

golang doesn't really have other features that Java can take from, since Java is so rich, other than perhaps embedding. But it's been the case that the Java development process has been doing an excellent job at taking a better approach than what exists in adhoc developed languages, so it wouldn't surprise me that they would come up with a superior alternative.

vardump• 3 years ago

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

foepys4• 3 years ago

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

impulser_2• 3 years ago

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 popular as a replacement for Java.

How are Jars more portable than Go binaries when you need Java installed to run Jars?

Java obviously has a more mature ecosystem with more libraries due to age, but Go you don't need many libraries to begin with. The Go std lib will give you almost everything you need in most cases.

surfsvammel3• 3 years ago

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.

marginalia_nu18• 3 years ago

How are Jars more portable than Go binaries when you need Java installed to run Jars?

Uh, you don't...?

https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa...

you don't need many libraries to begin with.

This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more.

A while back I found myself wanting to render MathML into an image. So I dug up jeuclid which is absolutely antique and as far as I can tell not actively maintained. My project flat out would have ended there if I had to build my own math rendering engine to proceed.

pjmlp14• 3 years ago

What people?!? That is a very special bubble over there.

kaba060• 3 years ago

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.

matsemann• 3 years ago

How are Jars more portable than Go binaries when you need Java installed to run Jars?

Your java knowledge is half a decade out of date.

mahmoudimus2• 3 years ago

In 2010, I think arguing that relying on the JVM would be an acceptable gripe. However, it is 2023, almost all of your stated issues have been (IMHO quite elegantly) addressed WITH the added benefit (or maybe detriment?) of backwards compatibility in modern versions of Java and the _incredible_ engineering behind the JVM.

I would actually argue the inverse. Between the two languages, Go would be my second choice precisely because it does NOT have the JVM. Even though I have used GraalVM for AOT, with Docker / containerd, I would take the JVM any day. It's just night & day when operating something in production.

That being said, Go still has a lighter resource footprint but I found Go to be a better Python alternative than Java.

Here are some IMHO acceptable gripes with Java:

- Java represents strings using UTF-16 (although there are optimizations introduced in Java9+ already to use LATIN1 / ascii encoding if you don't need to use Unicode)

- Java makes it difficult to have steady state memory consumption (by design)

- Java's escape analysis is primitive

- Java is missing value types (coming soon!)

I think Go is great, but IMHO modern Java is just better at building backend systems.

the_gipsy4• 3 years ago

What Go has going is that it's faster and more pleasant to develop in. Yet another bullet-point-feature bolted on only makes the Java ecosystem jungle worse in that aspect.

I find your other points a bit dubious. Java's type system suffers from extreme verbosity and little soundness, and exceptions have not been a successful error-handling story. I don't think you can call a jar that needs a system installation of some specific jre portable - at all. The ecosystem may be huge, but also nightmare in terms of interoperability and support of newer features. IDE click-driven-development is a crutch for the extreme verbosity and complexity of patterns in Java. Compile times are much worse in my limited experience.

kaba060• 3 years ago

Based on your writing, your experience with Java is indeed very limited and not up-to-date at all.

Dinux• 3 years ago

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 users, stuck in the past.

pjmlp14• 3 years ago

We are at Java 20, when Sun died we were stuck in Java 6.

No improvements, what a joke.

MrBuddyCasino4• 3 years ago

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

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

wiseowise11• 3 years ago

Are you trolling?

https://openjdk.org/jeps/0

pdpi2• 3 years ago

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 brings runtime support for virtual threads, at the VM and standard library level, but there is no real language support, whereas Go has actual support with syntactic sugar around goroutines, channels, and select statements.

Tooling and the sheer number of libraries are definitely Java's biggest draws, but it's not enough to justify choosing Java over Go across the board.

killerstorm2• 3 years ago

JVM has many different GC implementations, some of them are optimized for low latency, and, in fact, come with guarantees.

kaba060• 3 years ago

Java also has a low-lat GC which is also better than Go’s at the relevant metrics (ZGC).

lenkite11• 3 years ago

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/

commandersaki• 3 years ago

Java's jars are more portable than go's binaries

Since when?

jillesvangurp3• 3 years ago

Well a go binary only runs on the platform it was compiled for. A jar file runs on any platform that has a working JVM. I.e. most commonly used operating systems and CPU architectures you can name.

Of course whether that matters to you is another thing. Most people package either of those up using docker and run them on generic linux hosts.

wiseowise11• 3 years ago

Since forever.

bborud2• 3 years ago

I think all of the things you point out are probably true. But I still prefer Go.

And I'm probably not the kind of person you imagine. I'm in my 50s. I used Java for ~20 years. I spent a lot of time developing efficient programming practices in Java and teaching those to both junior developers and people with decades of experience.

I'm also not someone who takes a language switch lightly. It takes much, much longer to become reasonably competent in a programming language and I think that if you are going to choose a "workhorse language", you kind of need to see it as a decade long investment. You don't learn a language in a year.

I switched to Go mostly because it is a nicer language for what I do (servers). But I can fully understand why someone would flee Java. Java has a lot of baggage in the shape of legacy code. When people talk about languages they tend to talk about them as if we all live in a fantasy world where we can write new programs from scratch all the time. But that isn't reality for most programmers. Most programmers aren't starting projects from scratch - they work on stuff that has already existed for a while.

Java has been around for a long time. Which means that every version of the language, every fad, every architectural trend, everything that has happened in almost 3 decades of Java exists at the same time in codebases that are alive and kicking. When developers get a job, this is what they are faced with.

The same is true for C++. Yes, the most recent language spec is a nicer language than what you had 10 or 20 years ago. But that probably isn't the language you get to use when you join a company and start to work on their product.

The reason people choose different languages when they do start from scratch (do a startup) probably isn't entirely rational. I suspect a lot of people avoid languages where they have encountered large legacy codebases full of frustrating code that is done in a out of fashion way.

I chose to switch to Go, despite having 20 years invested in Java, because Go has the features I need in a language and isn't cluttered with much of what I don't need. It has nicer tooling that just works better for everyday things. It also has a healthier approach to how you design stuff: it isn't dominated by large frameworks. I don't have to teach Go programmers minimalism and have "experienced" programmers throw tantrums because they feel threatened when having to re-learn how to program Java.

To be honest, I shudder a bit when thinking about going back to Java. It has so much stuff to deal with when reading other people's code. It doesn't feel like it is worth my time. I can't go back to that. My time is too valuable to me.

(I probably should point out that I did decide that I had better find an alternative to Java when Oracle showed itself to be untrustworthy and litigious. But it took years to find both the opportunity to leave Java and the language to leave Java for)

jillesvangurp3• 3 years ago

Well technically, you could do async and green threads / co-routines / promises / futures/ etc. (all the same thing technically, it's all callbacks under the hood) on the JVM for many years. Frameworks like Spring, vert.x, and others have supported this for ages. The loom project just makes it a bit easier to use this and provides some JVM level support and optimization for this. With other JVM languages (Scala, Kotlin, Clojure, etc.) this was already quite easy so it's less dramatic if you were already using those languages. My kotlin co-routines will be using loom threads under the hood pretty soon but it's not going to massively change how I use them or what I do with them. Or make a huge difference in performance. My code isn't CPU bottle necked, typically. Like the vast majority of server software (which is IO or memory bottle necked typically).

Go of course has simplicity as its main advantage. That doesn't go away of course. But it's a double edged sword and it can be a bit overly verbose / limited for some stuff.

Maybe more interesting is the trend towards native compilation in the Java world. Graal is a pretty big deal. And with languages like Kotlin, there is also kotlin native and wasm as a relatively new option. That's the other advantage Go has had that is slowly going becoming less relevant: fast start up times and a simpler run-time (i.e. a statically compiled binary that you start).

ChatGPT is fluent in many languages. I've been generating some usable Kotlin code with it, for example. I'm sure it does Java just fine as well.

spion3• 3 years ago

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

pjmlp14• 3 years ago

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

nickstinemates2• 3 years ago

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

0xAFFFF2• 3 years ago

I you really want to stick to terrible naming and overused architectural principles in 2023 that's your choice but that's hardly a Java issue.

tm-guimaraes3• 3 years ago

that's a culture issue that is changing rapidly to avoid that. Also that was common due to previous limitations in the language.

regarding the "com.lol.myapp", i actually think this is a good think for package management, it avoids naming issues with packages for different vendors and forks. On the code itself you should only see these on the import lines on top of the file, which isn't really a big deal.

I think most people issues with java come from old legacy codebases that had over the top patterns like that due to limitations in the language and culture. Nowadays, with a proper conventions guide, java can be quite clean. Sure it won't ever be as clean as something new as Kotlin, as it tries hard to maintain backwards compatibility, so old ugly stuff will remain in the language (even if you don't use it, you might see old code that does), and new stuff designs are restricted by what already exists, but it still has its advantages over new shiny things like kotlin for example: new pattern matching, compile time and compatibility (kotlin "100% compatibility" doesn't actually cover everything, and compatibility is important for Big Co with loads of teams and loads of internal and external dependencies and tools)

cleanchit3• 3 years ago

Never wrote one. Couldn't care less.

wiseowise11• 3 years ago

I can’t believe you’ve posted this seriously.

kabes• 3 years ago

As a language java's not that bad at this point. But it still has cultural issues.

Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder.

Furthermore, since the language evolved so much in recent years, it's hard for newcomers to know what the best practices are. There's at least 6 different ways to iterate over map values. Which one should I pick?

vrnvu• 3 years ago

Completely agree with you.

I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice".

But this seems a taboo topic in a culture infested with "good practice gurus".

kaba060• 3 years ago

Gradle is a better build tool from a purely architectural point of view (though it is quite disliked, I believe mostly due to the ultra-complex android build system being built on top and giving it a bad name), but the Maven repo system is absolutely better than most contemporary repositories, proved by its comparably rare side-chain attacks.

brabel2• 3 years ago

I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder.

I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a configured repository or something similar, which would of course be your mistake not the tool's.

re-thc8• 3 years ago

There's at least 6 different ways to iterate over map values. Which one should I pick?

Didn't stop people from using Javascript.

I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder

And I frequently encounter issues which seem to only get resolved by throwing away my node_modules folder (and package-lock.json).

Point being every language has its issues but Java gets knocked down constantly regardless.

equalsione• 3 years ago

Pre-java 8 (Java.old) and post-Java.8 (Java++) are philosophically two different languages.

Now, 21 is coming and while the changes aren't quite as in your face, the change in philosophy is just as radical.

Java would be better regarded if less time was spent on "look at this cool new feature" and more spent on "this is how you should use Java now". Or even, "here's how to safely modernise your codebase".

Venkat Subramaniam does some good talks on this but I would prefer if the Java language team were leading it.

Bjartr• 3 years ago

If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated.

Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.

jayd1611• 3 years ago

Don't use ambiguous dependencies and you won't need to flush your cache to get a newer version.

I would say the culture is not an issue of Java but of popularity. If Go became the shovelware language of choice, you'd see a lot more bad Go.

rakoo3• 3 years ago

So with this, the last thing Go had going for it over Java is gone, right?

Go still has composition over inheritance, which is vastly more flexible. Go favors explicit (verbose copy-paste, redundancy, use stdlib first, libraries second) over implicit (magic annotations, frameworks everywhere) and I like when I can understand what's happening without holding 10 files in my brain context. Go's memory usage doesn't trigger the OOM killer every 10 minutes. Go favors copy-pasting because what you copy is short and understandable, and function names don't have 10 words in it.

It's always going to be a personal choice, and even though virtual threads bring java closer to where go is, it's still not there for me.

jayd1611• 3 years ago

How does a language favor copy/pasting? Do you mean it makes code reuse harder?

zapnuk2• 3 years ago

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 or two when we have IDE integrated AI support

I guess it depends on the problem you want to solve. For the use cases I work on I'd prefer Go for its simplicity.

aembleton4• 3 years ago

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.

kaba060• 3 years ago

For the use cases I work on I'd prefer Go for its simplicity

Why don’t “enjoy” the simplicity of assembly then? (Not trying to be sarcastic, just I always felt that this logic is flawed. Especially that java is a very simple language, with very few concepts. If you don’t like, you absolutely don’t have to use metaprogramming like Spring)

qtzfz• 3 years ago

Go doesn't have exceptions. That makes it infinitely better than Java could ever be.

Thaxll2• 3 years ago

I mean having a nice feature does not remove all the other pain points. On your last point go mod is way better than anything available in Java. There're still printing out 600 pages book about Maven.

Java will always be a mess of layer of abstraction and magical / heavy framework.

gigatexal• 3 years ago

Can I get a tiny static binary with Java? Nope. Then Go still has legs.

Edit: nvm. You can get static muslc binaries with graal https://www.graalvm.org/22.2/reference-manual/native-image/g...

the-alchemist3• 3 years ago

The "original billion dollar mistake" is lack of runtime bounds checking (in the creator's words), not the idea of a null/nil/undefined generally.

lightbendover2• 3 years ago

the billion dollar mistake

Eh, a billion dollars isn't too bad.

Mawr• 3 years ago

This is missing the forest for the trees.

Languages are very complex, you will not get a good picture of their overall strengths and weaknesses if you limit yourself to a very zoomed-in view, like comparing a few features of the languages themselves.

As an example, consider the digital camera market vs the cameras in smartphones.

The digital camera is a clear winner! So many features. The quality of photos taken is objectively better in every metric too.

And yet the digital camera market is dying, completely killed by smartphones.

But why, the features are cleary better right?!

Because we're looking at it wrong, we're tunnel-visioned on the "camera" part. We need to look at what actually matters.

Thankfully, that's simple to answer and is the same for every product in existence. All that matters is the user experience.

Nobody wants extra features on their camera, nobody wants a camera in the first place, nobody wants to take photos either. What people actually want is to preserve the moment of their first born child taking their first steps. The technology is irrelevant as long as it lets the user do what they really want.

Why would I want a digital camera when my smartphone has a decent enough one that is effectively free and always available? A low quality camera on you is infinitely more valuable than the professional camera at home.

Programming languages are no different, just that "users" in this case are programmers, which seems to be confusing to some.

What is the developer experience of using Java vs Go? - that's the real question you need to answer to get to the bottom of this.

Start a new project and write some code in both languages, compare the experiences. Be wary of biases, if you have pre-existing experience in one of the languages it's going to shadow your judgement (the curse of knowledge). Pay attention to aspects of good design - how many pointless decisions do you have to get through before actually shipping code?

Go eliminates whole areas of pain points:

- Dependency management? Go modules.

- Tests? Built-in.

- Code formatting? Built-in autoformatter.

- Compilation time? As fast as it gets.

- Distribution? Single binary.

- Writing code? Minimal ceremony, just make a function.

- Performance? The idiomatic code you write will naturally perform well due to value types, explicit pointers, a culture of straightforward code with no needless indirection. If you need to optimize, the profiling tooling is great and the optimizations themselves straightforward due to intuitive language and GC semantics - just reduce allocations.

- GC? A single implementation, good enough for 99% of cases. Two whole knobs available if you really need to tune it. Performs well due to the language not getting in its way.

- Standard library? Excellent, good balance between batteries-included and bloat. The built-in HTTP server is suitable for 80%+ of workloads.

- Concurrency? Core to the language - syntactically supported green threads. The entire language and its ecosystem are built with it in mind.

- Linting? Community-made linter runner with a curated list of good linters.

- Found a bug in a library? No problem, the library is written in straightforward Go, the same flavor of Go you've been writing. It's of course autoformatted as well.

There you go, a single go-to solution to each problem. The language's designers have gotten all the pointless details out of the way for you. You get to focus on writing code.

Now compare the above points with Java.

Go was designed for developers, with the same philosophy Steve Jobs designed Apple products for users. Java wasn't. Simple as.

seanparsons2• 3 years ago

Well it's not really ushering it in, given that this is what Haskell has had for a decade at least.

marginalia_nu18• 3 years ago

Well, yeah. Haskell is a research language, while Java's stated design philosophy from day one has been to be conservative with adding new features, and judiciously add new features after they've proven useful in other languages.

maxbond4• 3 years ago

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

seanparsons2• 3 years ago

So how does that make a difference to my point? The title is literally false as multiple other languages have already done it, Haskell in fact has even rewritten the underpinnings at least once the feature has been there so long.

cleanchit3• 3 years ago

What's haskell? \s

invalidname• 3 years ago

If you need a video explanation of virtual threads this might help: https://www.youtube.com/watch?v=4mf24mzm0ks

spuz3• 3 years ago

Thanks - that's really helpful.

ranguna• 3 years ago

Are these like javascript promises or goroutines?

MathMonkeyMan• 3 years ago

More like goroutines. They remind me of Guile's fibers: https://github.com/wingo/fibers

avodonosov3• 3 years ago

In javascript the analogue is async / await, only without the need to manually mark code "async"

Rapzid7• 3 years ago

If you want to return a future you'll need to note that in the return type.

Barrin92• 3 years ago

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.

ulimn• 3 years ago

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.

xdavidliu• 3 years ago

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.

moring• 3 years ago

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

ddorian43• 3 years ago

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

kaba060• 3 years ago

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

dfox2• 3 years ago

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

BenoitP3• 3 years ago

Your second link is from 2018, and would indeed need a case study for Loom. For example the concerns about thread-local storage are addressed, and the base overhead is understood (as in: don't use them for CPU-bound worloads, they'll fare better on IO-bound workloads)

Also, the cases studies in that paper are platform-level when I believe the language has to be involved; as a runtime has more information when resuming to a suspension point. The paper even acknowledges Go as a successful implementation although with C-compatibility call overhead caveat. In the Java world, the vast majority of programs stay in the Java language. So I'd say that paper would list Loom as the best implementation (And maybe revise their recommendation. It'd be useful to have that author's opinion of Loom in 2023)

piokoch• 3 years ago

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: https://webtide.com/do-looms-claims-stack-up-part-1/

Before getting too excited I advise to watch Tomasz Nurkiewicz lecture on the subject - https://www.youtube.com/watch?v=n_XRUljffu0, it explains what are the trade-offs here.

No silver bullet, again.

re-thc8• 3 years ago

Jetty server guys tested this and they were not that happy

This was in 2021. Hopefully things have and will improve in the final version. We have to start somewhere.

No silver bullet, again.

More like progressive improvement. If you always need things to be a 100% better we'll never have new toys :)

kasperni• 3 years ago

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.

A typical request easily creates 100's of objects that needs to be garbage collected. Adding a single thread object on top of that means absolutely nothing. And how much garbage to you think reactive frameworks create? I can you tell you it is a lot more.

Before getting too excited I advise to watch Tomasz Nurkiewicz lecture on the subjec

Don't waste your time. He is pretty clueless. I remember him complaining about lack of backpressure and composability. But this comes pretty much out of the box with loom.

isbvhodnvemrwvn• 3 years ago

How does loom address backpressure?

karussell• 3 years ago

Based on that I found this reddit discussion where Ron Pressler (Loom project) commented:

"The posts read like they’re leading to a negative conclusion, but at the end of part 2 it turns out that the current Loom prototype does perform as well as async in their experiments ..."

https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claim...

cleanchit3• 3 years ago

Million thread shouldn't be an issue (million times 2k bytes per thread = 2gb)

akvadrako• 3 years ago

You can even use a million native threads without an issue on Linux. But unless they are mostly idle you probably won't be able to serve a million concurrent clients, wether you use threads or not.

kaba060• 3 years ago

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.

pron6• 3 years ago

1. Platform threads place a heavier burden on the GC. It's true that virtual threads are allocated on the heap, but platform threads are GC roots, which is worse. The GC easily deals with a gazillion heap objects; it's rather unhappy with lots of roots. The number of heap objects that virtual threads occupy is roughly the same as the number of heap objects that async code allocates anyway.

2. The Jetty experiment measured the wrong thing as they misunderstood the origin of the "million thread" scenario. What happens in a real application is that you have some number of threads with deep stacks servicing incoming requests -- say 50K concurrent sessions -- and then each of those fans out to, say, 19 micro services in parallel, each of those outgoing requests is done on a virtual thread with a very small stack, and that's how you get to 1M threads. I.e. when you have a high number of threads, only a small minority of them (5% in this example) have a deep stack.

3. I don't think anyone would claim anything is a silver bullet. All virtual threads do is let a server service the same throughput as asynchronous code does, but the code is much simpler and it is observable, i.e. easily debuggable and profitable, something that async code can't do.

MarkSweep• 3 years ago

Regarding #1, would not the stacks of the lightweight threads have to root have to root any object on it? Otherwise the GC would free objects out from under the virtual thread, right?

I could imagine that by having fewer physical threads running, the stop-the-world part of garbage collection could suspend the runtime more quickly. That could reduce the effect of GC-pauses.

cryptonector4• 3 years ago

Yes, there's no silver bullet. Writing async code from the beginning is a much better approach to reducing memory footprint. But fibers/virtual threads/whatever-you-call-them will help scale many thread-per-client apps w/o having to pay for a rewrite as async code. That is worth a lot because the size of the thread-per-client Java codebases is enormous.

tsimionescu• 3 years ago

That is very much false.

Async code is the wrong fit for Java, and it complicates everything tremendously. There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency.

If anything, I would assume that, after a few rounds of optimization, Loom will be significantly better at managing memory than a Java async framework.

kjto4• 3 years ago

Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.

they should have just called them "Tasks" leaving the already overloaded term "virtual" out of the conversation.

marginalia_nu18• 3 years ago

Java's already got tasks[1] within the namespace of parallelism though, but it hasn't overloaded any meaning onto virtual.

[1] https://docs.oracle.com/javase/9/docs/api/index.html?javafx/...

vips7L2• 3 years ago

JavaFX is not really a part of Java and isn’t actually shipped with most builds of OpenJdk. Azul Zulu is the only build that I know of that you can get FX built in.

BenoitP3• 3 years ago

IMHO virtual is the perfect word. The JVM's entire schtick is abstracting (virtual) hardware (machine). A simple API pertaining to intent, that can be materialized depending on OS and hardware.

Calls are virtual, though under the hood the compiler may inline them.

Memory is managed, though through analysis some allocations will go on the stack.

Threads are now (no full grandfathering, but they tried) virtual, and the runtime may now optimize them differently on different OSes and hardware.

aardvark1792• 3 years ago

We went through a lot of iterations on what they should be called. They were originally called Fibers, but since they were extremely thread like it was decided they should be actual threads, so they should be some type of thread. Once that decision was made the question then becomes which adjective to add to Thread, and things like LightWeight, Small, etc. were ruled out as smaller or more lightweight threads might be introduced in the future.

mattgreenrocks• 3 years ago

Thanks for the explanation. That makes a lot of sense.

Naming things well is harder than making said things sometimes.

layer86• 3 years ago

They are of type `Thread`, for interoperability with existing code.

surfsvammel3• 3 years ago

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.

re-thc8• 3 years ago

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.

surfsvammel3• 3 years ago

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

flippinburgers2• 3 years ago

The top level comment is someone gushing over Java so perhaps Java advocates bring this on themselves?

gpderetta5• 3 years ago

Indeed. It is the curse of the Stroustrup law.

alkonaut3• 3 years ago

How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?

jillesvangurp3• 3 years ago

Conceptually, these are all variations of the same thing. The difference is in how you use them and how much boiler plate you need to use them.

Funnily enough, the first versions of Java did not support OS threads and only had green threads for a while. Supporting real threads was a big deal at the time as it allowed you to use more than 1 processor. Of course, processors were single core at the time and most computers only had one of those anyway. Java 1.1 laid the foundations for proper multi threading and green thread support was eventually removed with Java 1.3. With Java 1.5 we got the java.concurrent package which enabled doing more complicated things with locks and other synchronization primitives that were a bit less primitive & brittle than using the synchronized & volatile keywords. That includes implementing green threads on top of real threads. Which is what frameworks like vert.x and others have been doing for ages.

So, in a way we're coming full circle here with virtual threads re-using the thread API, which in turn reused the original green thread APIs in Java 1.0.

kaba060• 3 years ago

That leaves off basically the whole point of it: JVM-native blocking calls don’t have to actually block, they can do an OS-native async call, and do some other work on the thread, returning upon completion.

Since Java uses very little FFI, it will benefit greatly from this automagical “no more blockingness”, of course only when there is some other available work in the meanwhile. Servers are the best fit for that.

killerstorm2• 3 years ago

I guess the idea is that you don't have to write tasks explicitly - if you have a sequence of actions you can just write it as a regular code, and the runtime will automatically insert points where your code might be suspended waiting for IO or other threads.

alkonaut3• 3 years ago

The only example in the article does an explicit task though (in the form of a closure) e.g. something.submit(() -> { task code });

neonsunset• 3 years ago

New Era of concurrency? It began in arguably better languages a decade ago.

philonoist• 3 years ago

Anyone familiar with Java and Kotlin, please expand on how close is Java in feature parity with Kotlin?

BenoitP3• 3 years ago

Kotlin's are stackless (as in emulated by the compiler), Java's are stackful (as in a chunk of stack is copied into the heap along with a program resume point)

This means Kotlin's functions can become colored [1] which is a problem.

This said, I'm fully expecting Kotlin to react and pass on this feature to the users. Maybe after figuring out how to deal with Android.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

cutler2• 3 years ago

`Executors.newVirtualThreadPerTaskExecutor()`.

Java verbosity is alive and well.

mahmoudimus2• 3 years ago

Yeah that part is not great. OTOH, I know exactly what it does :)

thom• 3 years ago

Any other naming here would be worse.

lenkite11• 3 years ago

So is Apple/Swift, but Apple always gets a smile instead of a smirk here on HN.

    func CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications(
      allocator: CFAllocator?,
      sourceDescription: CMMetadataFormatDescription,
      metadataSpecifications: CFArray,
      formatDescriptionOut: UnsafeMutablePointer<CMMetadataFormatDescription?>
    ) -> OSStatus

cutler2• 3 years ago

Wow. Where did you find that specimen?

2muchcoffeeman• 3 years ago

Do they? I recall ObjC getting a lot of criticism over their long method names.

But really, who cares? Who the hell types out the whole method in this day and age? Type the first few chars, up arrow, down arrow, tab. Jump around with vi bindings. I have not written a full line of code in well over a decade.

Although Apple deserves it since their IDE really blows compared to say Idea.

i3863• 3 years ago

God forbid we have names that explain the subject

marginalia_nu18• 3 years ago

Given this is something you're probably going to find at most a handful of times in an entire code base, I don't think that's necessarily bad.

Java API stuff hasn't ever been a huge contributor to verbose code. Yeah I guess some of java.io's stuff isn't great, but the worst AbstractFactoryDelegateImplFacadeProviderVisitor gore was always in the application code.

wiseowise11• 3 years ago

How would you call it?

kaba060• 3 years ago

Yeah, some C-style would be so preferred: e_nvtpte() /s

andix2• 3 years ago

Is this the equivalent for the .NET TPL (task parallel library), which exists for over a decade now?

francasso• 3 years ago

Not familiar with .NET, virtual threads in Java are an alternative to async await in other languages. The approach Java took is similar to green threads in go.

andix2• 3 years ago

TPL is a library to create Tasks and run them. They can be scheduled in different ways, on (native) thread pools for example. They are commonly used together with async/await. They are very similar to promises in JavaScript.

I read about the approach without async/await, but honestly I don’t really get it. Seems to be very dangerous to me, if you give up control about scheduling. But sure, async/await is completely viral and it is everywhere now. Most functions tend to be async.

ahtihn• 3 years ago

virtual threads in Java are an alternative to async await in other languages

Not really. Async/Await is mostly about syntax. Transform callback-hell into something that looks like linear code. The underlying threading model doesn't really matter for that.

bullen3• 3 years ago

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable.

2004 -> 2011, 7 years!

Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.

Many nuclear power plants wasted on the kernel.

giancarlostoro• 3 years ago

Many nuclear power plants wasted on the kernel.

iTunes could have reached greater heights had they allowed nuclear plants.

thesuperbigfrog• 3 years ago

> iTunes could have reached greater heights had they allowed nuclear plants.

The old iTunes "Burn Disc" icon with its yellow and black colors and sharp angles always reminded me of the "Radiation Warning" symbol:

https://cdn.osxdaily.com/wp-content/uploads/2009/09/burn-iso...

https://en.wikipedia.org/wiki/File:Radiation_warning_symbol....

When you were burning your own custom mix CD, things got hot . . .

nicktelford2• 3 years ago

Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.

Can you expand on this a little? Are you referring to the necessity to copy between kernel memory and user-space memory, or something else?

hderms• 3 years ago

Maybe io_uring?

bullen3• 3 years ago

Yes

wolf550e2• 3 years ago

Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.

How does this work around the kernel? This lets you write java code that uses async IO but make it look nice, like golang code. But this isn't DPDK.

bullen3• 3 years ago

The JDK would have access to network card and SSD directly.

Bypassing the kernel. Java is already sandboxed we don't need the kernel unless the net/ssd drivers crash completely.

It's a huge task/risk, but 30% is alot.

kosolam2• 3 years ago

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

jononomo2• 3 years ago

If you want to use an async framework without sacrificing simplicity, look into Elixir/Erlang and the BEAM.

jayd1611• 3 years ago

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

throwaway2847• 3 years ago

Why would you need an async framework? All blocking I/O in the Java runtime has been changed to yield in a virtual thread.

grishka2• 3 years ago

JVM itself would do async I/O as needed using whatever API the underlying OS provides. Your own I/O code would be straightforward and synchronous. Nothing will run out of threads.

cryptonector4• 3 years ago

Because Java did not have a good async model for decades, most Java apps are thread-intensive (thread-per-client) and there's an enormous amount of code that can't easily be refactored into async. Light-weight threads help save all that thread-per-client code from the ash pile of history.

But in general it's best to write async code from the get-go because that forces the programmer to compress application state rather than inefficiently smear parts of it on the stack. Better state compression (because smaller stacks) -> smaller memory footprint per-client (or whatever) -> faster (because of higher cache hit ratios because of less cache thrashing because fewer memory accesses).

erik_seaberg2• 3 years ago

We are made of meat. It’s rarely worthwhile to sacrifice developer effort to conserve hardware, and if you do manage to break even today, you probably won’t in the future. Async Java was pretty painful and only penciled out because the cost of a million native threads was just ludicrously higher than everything else.

_boffin_• 3 years ago

Does this mean one doesn’t need to use reactor with spring and can rely on the non-reactive method and still get great performance?

kaba060• 3 years ago

Once spring changes over their internal implementation, yes. In the meanwhile there are already Loom-aware frameworks out there like Helidon Nima.

theandrewbailey• 3 years ago

Platform threads are a one-to-one wrapper over operating system threads, while virtual threads are lightweight implementations provided by the JDK that can run many virtual threads on the same OS thread. Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead.
The JDK can now run up to 10,000 concurrent virtual threads on a small number of operating system (OS) threads, as little as one

OK, but why bother with virtual threads if the JVM could just magically decide to run all my virtual threads on one thread? I guess "efficient" in this context doesn't mean "fast". I want my code to run on all available cores, and not be hobbled by a JVM that decided to hate me today.

mschaef• 3 years ago

OK, but why bother with virtual threads if the JVM could just magically decide to run all my virtual threads on one thread? I guess "efficient" in this context doesn't mean "fast". I want my code to run on all available cores, and not be hobbled by a JVM that decided to hate me today.

If you have 10,000 threads blocked on a sleep (or I/O), then there's no reason to run them on more than one code. In fact, they won't usually be running at all.

This is the use case. It's less about giving the VM a new way to 'hate you today', and more about telling the VM when it can save resources and share system threads.

Edit: There is some potential for unexpected downside to the extent that this introduces a new scheduler for the virtual threads. If every thread is an OS thread, then it's the OS scheduler that controls when they run. With virtual threads, I assume the scheduling policy (deciding when virtual threads get time on OS threads) is controlled by a JVM scheduler that may or may not be as good at making the choices you'd like. But probably best to assume it won't summarily drop everything on a single OS thread and call it a day.

jononomo2• 3 years ago

It seems that everyone is learning from Erlang and the BEAM!

layer86• 3 years ago

However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution.

What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

nicktelford2• 3 years ago

Lock contention IIRC

the-alchemist3• 3 years ago

Yeah, poor performance and memory usage. In the Java world, thread locals are java.lang.ThreadLocal, basically a hashmap from thread to variable.

Using a ThreadLocal is (usually) a code smell. It's optimized / supposed to be used with just a few threads, not millions.

layer86• 3 years ago

But the lock would only need to be per platform thread?

royjacobs2• 3 years ago

Typically ThreadLocals are used whenever something is costly to initialize per-request. The rule of thumb is usually: you might want to use some heavy object without locking, so you stick into a ThreadLocal.

However, if suddenly you have a million threads then this optimization doesn't work anymore. Sure, the concept of ThreadLocal still works, but in practice you'll end up creating a million of these heavy objects - something you wanted to avoid!

layer86• 3 years ago

Expensive to initialize doesn’t imply large. And wanting to avoid expensive initialization (runtime) is orthogonal to wanting to avoid a larger memory footprint. So I don’t quite buy your argument.

no_wizard• 3 years ago

What will this mean for Kotlin and concurrency I wonder

DeathArrow• 3 years ago

How are Java virtual threads compared to C# tasks? To me, they seem very similar.

plumarr• 3 years ago

The main benefit of virtual threads it that they release their carrier thread when they call (non native) blocking code, so that other virtual threads can be executed by the same carrier.

I don't think that it's the case for C# task, which also appear to be an higher level construct.

Patrol8394• 3 years ago

I really hope this is the end of complicated reactive frameworks! I love the old blocking spring controller paradigm, thread local and so on. It makes things much easier. Never liked webflux, so complicated and hard to debug. Simple things become a project!

Virtual threads to the rescue!

remon• 3 years ago

I could not agree more. And that's coming from someone that converted to almost completely async/reactive/flux-y code. Reactive frameworks, almost by necessity, force developers to write less maintainable and readable code (objective fact, not an opinion). Lightweight threading is a significantly better approach to the same problem space.

wiseowise11• 3 years ago

objective fact, not an opinion

Got any links where I can read about it?

jmull• 3 years ago

Are we dropping the "in" from "to usher in" now?

Or is this just an incorrect headline?

whoisthemachine2• 3 years ago

Using virtual threads only, can one make a non-blocking UI application? Or do you still need to fall back to Promises or callbacks?

bberrry• 3 years ago

I'm not positive about this but I believe the virtual threads can yield at syscalls (i.e. IO calls). I don't think GUI application code is littered with these syscalls where a virtual thread can naturally yield so you get non-blocking for "free". Someone please correct me if I'm mistaken.

jsmith45• 3 years ago

Under .NET's async await model, switching also generally only occurs when blocking IO is initiated (or blocking on a timer, etc). You cf course add your own yield points, but it is not frequently necessary. That is mostly limited to CPU/memory bound operations, as any IO bound operations would have the potential to yield.

However, something important to remember is that UI frameworks generally require most or all UI interaction to occur on one logical thread. This is because making all the UI code safe for calling from multiple threads would require tons of work, and likely require one massive lock that serializes most ui compontent method calls, or tons of smaller locks. And that is just for the minimum of safety. UI work has tons of implicit state.

User level logic would also likely need additional locking, since even if each method call to a control is thread safe, if you want to perform some kind of conditional action that does not already have some dedicated method, that would pose a problem without some form of synchronization code.

One advantage of the async-await approach in UI scenarios (where continuations always get run on the UI Thread) is that you know that between two awaits, no other code will be running on the UI thread, so can avoid synchronization code. You know if you read a value from a control and then conditional call a method on it, you don't need to worry about racing with another thread. Now whenever an "await" occurs, potentially arbitrary other UI code may have run in the interim, so you may need to reverify the state of things. But this is still much simpler to handle than possibly being preempted at any time, or having another thread literally changing things in parallel.

Green thread based approaches like Virtual Threads do avoid much of the complexity of async-await, but they often do lose those sorts of advantages. Even if the green thread approach has guarantees about the yield points (e.g. only has cooperative yields which only occur when certain specific methods are called), you still lose the ability to locally reason about where those yield points may occur, since any function/method call could potentially call one of those yielding functions, or call something that calls one of them, etc. The only way to regain that info is to "color" the functions again, which was the whole thing peple are trying to avoid with green threads in the first place.

sys_64738• 3 years ago

What are these things? It sounds like it is a time-sliced sharing that offers only concurrency and not parallelism. In other words, it's a userland construct and not a kernel thread. Sounds more like GO coroutines but do we really need another name for them?

za3faran6• 3 years ago

Already responded to here https://news.ycombinator.com/item?id=35537890

vkaku• 3 years ago

The issue I see is some companies' reluctance to even shift from Java 8 or move away from legacy.

I guess that will be the biggest impediment to adoption of new features.

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

Related Stories