Java's Enhancement Proposals Pursue Virtual Threads, Data Aggregate Types, and Better Communication with C Libraries (oracle.com) 56
Oracle's Java magazine takes a look at some current JDK Enhancement Proposals, "the vehicle of long standing for updating the Java language and the JVM."
Today, concurrency in Java is delivered via nonlightweight threads, which are, for all intents, wrappers around operating-system threads... Project Loom aims to deliver a lighter version of threads, called virtual threads. In the planned implementation, a virtual thread is programmed just as a thread normally would be, but you specify at thread creation that it's virtual. A virtual thread is multiplexed with other virtual threads by the JVM onto operating system threads. This is similar in concept to Java's green threads in its early releases and to fibers in other languages... Because the JVM has knowledge of what your task is doing, it can optimize the scheduling. It will move your virtual thread (that is, the task) off the OS thread when it's idle or waiting and intelligently move some other virtual thread onto the OS thread. When implemented correctly, this allows many lightweight threads to share a single OS thread. The benefit is that the JVM, rather than the OS, schedules your task. This difference enables application-aware magic to occur behind the curtains...
Project Valhalla aims to improve performance as it relates to access to data items... by introducing value types, which are a new form of data type that is programmed like objects but accessed like primitives. Specifically, value types are data aggregates that contain only data (no state) and are not mutable. By this means, [value types] can be stored as a single array with only a single header field for the entire array and direct access to the individual fields...
Project Panama simplifies the process of connecting Java programs to non-Java components. In particular, Panama aims to enable straightforward communication between Java applications and C-based libraries...
Several Amber subprojects are still in progress.
Sealed classes, which have been previewed in the last few Java releases and are scheduled to be finalized in Java 17. Sealed classes (and interfaces) can limit which other classes or interfaces can extend or implement them...
Pattern matching in switches is a feature that will be previewed in Java 17...
The article concludes that Java's past and current projects "testify to how much Java has evolved and how actively the language and runtime continue to evolve."
Project Valhalla aims to improve performance as it relates to access to data items... by introducing value types, which are a new form of data type that is programmed like objects but accessed like primitives. Specifically, value types are data aggregates that contain only data (no state) and are not mutable. By this means, [value types] can be stored as a single array with only a single header field for the entire array and direct access to the individual fields...
Project Panama simplifies the process of connecting Java programs to non-Java components. In particular, Panama aims to enable straightforward communication between Java applications and C-based libraries...
Several Amber subprojects are still in progress.
Sealed classes, which have been previewed in the last few Java releases and are scheduled to be finalized in Java 17. Sealed classes (and interfaces) can limit which other classes or interfaces can extend or implement them...
Pattern matching in switches is a feature that will be previewed in Java 17...
The article concludes that Java's past and current projects "testify to how much Java has evolved and how actively the language and runtime continue to evolve."
Deja Vu (Score:2)
I think I saw the same headline 20 years ago.
Re: (Score:2)
Exactly, wasn't this the whole green-threads vs native threads thing?
Re: (Score:2)
Exactly, wasn't this the whole green-threads vs native threads thing?
Yes, but it was handled by the JVM configuration. Sounds like now they're giving the developer (some) control over it. Also sounds, like everything else on this list, as a way to break the Write-Once-Run-Anywhere theme that used to be Java (get off my lawn).
Every gig I've been on in recent years has been cloud based microservices. Performance? Who cares. Just dial up more EC2 instances.
Re: (Score:2)
People still use Java? You would have thought that Oracle chased away everyone from it like they did with MySQL at this point.
Re: (Score:2)
Are you just silly or living under a rock?
What would be the alternative to Java?
And you seem to forget: Java is Open Source, developed by Apache. Oracle is just picking the latest release and rebranding it.
Re: (Score:2)
I would have thought that C# was an obvious alternative to Java. Isn't it just plain better than Java at everything that Java does?
Re: (Score:2)
Re: (Score:2)
No.
A) the language sucks
B) they don't have the tools - not the libraries
C) it is form Microsoft
D) it is much younger, no one is switching from (old) Java code to C# - makes no sense to rewrite anything
E) Java is basically: *the Internet language* C# is desktop, a little bit embedded
F) the naming conventions - sorry, americans seem not to bother that classes in C# are all lower case named, and for some idiotic reason: methods are Upper case. For a European - especially a German, that is a no go.
Plenty of mor
Re: (Score:2)
the naming conventions - sorry, americans seem not to bother that classes in C# are all lower case named, and for some idiotic reason: methods are Upper case. For a European - especially a German, that is a no go.
Wait, are you sure that's correct? I just double-checked, and what I found says that class names in C# follow the PascalCase convention, just like Java. I agree it's idiotic that C# uses PascalCase for method names. And I also very much agree that C# is inherently undesirable because it's from Microsoft.
Re: (Score:2)
Class names, for classes you create, can be any valid name. You are totally in control of your own naming conventions.
C# is opensource: it doesn't matter "where it's from", it's not owned by anyone.
The language is much less "sucky" than Java, as far as I can see, but I am a C++ programmer.
I only see one valid issue that you brought up: libraries.
Re: Deja Vu (Score:2)
Why be constructive with a person that clearly showed either his wilful lack of knowledge of his bad faith?
If you ask whether people still use java today, you are either of bad faith, thus not worth discussing with. Our your lack of information on the topic is so deep that there is no way you'd provide anything of value to a discussion.
Loom is the killer feature (Score:5, Interesting)
Re: (Score:2)
The advantage of that async/callback configuration is that it forces an awareness of how the underlying operation is fundamentally asynchronous and unreliable. Hardened applications typically have trips to prevent an excessive number of simultaneous I/O requests from being issued. With separate threads, it is a little to easy to assume that it will all execute successfully in the future.
My concern would be this sequence of events:
1. A multi-threaded library is written that assumes reliable transport.
2.
Re: (Score:2)
Re: (Score:2)
If you have a library that simply assumes reliable transport and doesn't handle exceptions your library is broken. And I fail to see how Project Loom creates new opportunities for that kind of brokenness.
The whole point of the approach is that in maintains the same programming models as exist in Java already, with the same error handling frame work, and largely the same concurrency model. The advantage is preserving execution context (e.g. ThreadLocal variables) without unnecessarily coupling it to an OS
Re:Loom is the killer feature (Score:5, Interesting)
The catch is that code running in a lightweight thread must also be designed to support that kind of interruption and blocking. In particular, the Go style of using communication channels rather than shared memory -- and avoiding mutual exclusion objects in as many cases as possible -- is strongly preferred. If code grabs a mutex, and then calls something that blocks it for an arbitrary time, then the functions relying on that mutex will not scale very well (and the bottleneck may not be readily apparent, depending on the application design).
Reactive programming makes that kind of long-running operation explicit, more or less forcing the programmer to think about the latency issue and plan their approach to concurrency, asynchronous operations and concurrency.
In that respect, simply being able to create lightweight threads that are multiplexed onto OS threads has a limited benefit. Also, it duplicates thread scheduling functions between the OS and the VM runtime. And you run into the question of where to put the stacks for all those lightweight threads, and how to grow them.
Re: (Score:1)
Re: (Score:3)
What early benchmarks? Do they benchmark anything other than the threading system itself? Do they represent a realistic application, or how threads interact with each other in the real world? For example, this Github repo [github.com] has some really trivial services -- but finds Project Loom is quite slow compared to older approaches.
Or a Jetty developer [webtide.com] found that Loom has some slight latency benefit but uses slightly more CPU and generates significantly more garbage. Looking also at part 1 of that series, if the
Re:Loom is the killer feature (Score:5, Interesting)
Also, it duplicates thread scheduling functions between the OS and the VM runtime. And you run into the question of where to put the stacks for all those lightweight threads, and how to grow them.
The Loom project relies on the existing fork/join pool, which is also heavily used by all the popular Java async frameworks. When a virtual thread needs to block, it transfers stack state to a heap-allocated continuation object, and so growth is managed by the existing GC facilities. In essence, Loom is automating the process of converting thread-based code to async-based code.
Re: (Score:2)
The catch is that code running in a lightweight thread must also be designed to support that kind of interruption and blocking.
Nope.
From a programmers perspective a "light weight" and a "heavy weight" threat is exactly the same. That is why VMs usually support both.
But when "heavy weight" - aka OS threats - got relatively cheap in the late 1990s, the VM implementors did not bother to continue supporting light weight threads. Now however, it is common that a Java VM is running several 10k (yes several 10 tho
Re: (Score:2)
Vanilla C was originally all synchronous, with the only async stuff being interrupts that disrupt the normal flow of the program (and SIGINT would default to termination). It's synchronous I/O was abysmal - it blocks whenever the user needs to do input, and thus cannot tell the user that something happened while waiting for a command. It was only until POSIX C or any system-specific library was it possible to do anything more
Re: (Score:2)
Some languages do embrace the async paradigm as a core language feature, but they all tend to be quite verbose at any I/O operation. I recall the whole "oh, async is a mess in Javascript but Promises will make it so much better", which while technically more flexible and easier than callback hell, is still not very pretty to work with when you have to have a significant back and forth conversation as part of a task.
True, multithreading introduces a complication when it comes to operating in some memory spa
Re: (Score:2)
Java acolytes have been claiming that Java was gonna obsolete/replace everything else "any day now" for, what - the past 20 years?
Yeah, that'll happen (Score:2)
during the Year of Linux on the Desktop.
Re: (Score:1)
Do any of them still exist anymore? I think Java is pretty universally hated, and widely just considered to be one of those things we use just because we have to. I doubt you'd find anybody these days who would say "hey, let's write a new application in java!" it's more like "oh fuck, we have to support this old code base that's written in java!"
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Java is the new COBOL.
Re: (Score:1)
Java is the new COBOL.
Java is the new COBOL.
No it isn't...not even remotely.
Re: (Score:2)
Sure it is. There's a bunch of Java code out there that will possibly never be retired or re-written, but it's not a language people WANT to program in anymore.
Re: (Score:2)
The only reason why Java is "hated", is that it is relatively old language at this point, with wide adoption and a trialed and proven workhorse in the enterprise.
Basically, it's not cool to use it anymore, because it is not the shiny new thing.
Re: Loom is the killer feature (Score:2)
Exactly, people have no idea what "hate" means anymore...
Java is not exciting, it's boring, it's verbose, for sure. But it gets shit done.
It's not the language that hype driven developers want to use. But do we want to work with hype driven developers anyway?
Re: (Score:2)
I don't know about that. async/wait is a fairly simple way to express concurrency. Especially it is often used for implementing futures. The good thing about futures is that they pretty much guarantee deadlock-freeness. Where as programming threads requires synchronizing the application by hand with mutexes and conditions which is fairly deadlock prone.
More catching up against C#? (Score:3)
Re: (Score:1)
Re: (Score:2)
C# doesn't have lightweight threads and you need to use async/await style coding which is a worse solution than virtual threads that Java will have.
As far as I understand, async/await is just syntactic sugar around Future/Promises. How can virtual threads compete in that area ?
Welcome Java to 21st century (Score:1)
I think we should all thank C# for bringing these features to attention... In 2005... In version 2.0.
Fibers: Already abandoned for better Async/Await APIs and custom schedulers (to be fair I think this was version 5.0)
Data objects: Every language since version 1.0, except for maybe interpreted ones. This includes C# 1.0, too. Again to be fair Immutable structure support improved later on
Panama: P/Invoke, NativeMethods, Google ProtoBuf/gRPC ?
And others as well.
I don't understand the stubbornness of Java to d
Re: (Score:3)
Fibers: Already abandoned for better Async/Await APIs and custom schedulers (to be fair I think this was version 5.0
Async/await are slower than correctly implemented green threads. Green threads-based programs are also way easier to debug.
Re: (Score:2)
I recall early versions of the JVM (1.0, 1.1) having green threads and everyone hating it. People were constantly deriding Java for the lack of native thread support. Have we come full circle? Are green threads good now?
Re: (Score:2)
No one hated it. Except you perhaps.
It was easy to program in and from a programme perspective indistinguishable from native threads.
And the question if you run native threads or green (light weight) threads: was a command line option!!!
Re: (Score:2)
These days Golang sets the standard for performant green threads that are well-integrated into the runtime.
Virtual threads are not really new (Score:2)
Re: (Score:2)
N:M schedulers are an old idea. But it only really started to make sense implementing them when machines with many cores became commonly available. So circa 2008.
"will be" finalized in / previewed in Java 17 (Score:2)
Isn't this old news? Even Adoptium released their JDK 17 GA binaries already on September 22th. (Although these don't seem to be available from the well-known Debian/Ubuntu apt repository as of yet; moving from AdoptOpenJDK to Adoptium seems to have broken something there?)
That said, thanks for the link, it's an interesting and concise summary of what's happening in Java right now.
Oracle is incompetent (Score:2)
For comparison, during the Project Loom development timeframe, Google Go went from the first awkward version that used C-based implementation to fully Go-based self-hosting environment.
Re: (Score:2)
Can you cite the document that claims that the Loom project was supposed to be finished 3 years ago? The earliest reference I can find shows that the project began 4 years ago. http://cr.openjdk.java.net/~rp... [java.net]
The key difficulty is maintaining full backwards compatibility and working with all the tooling that has been developed over the years. Golang has the luxury of being new, and so new features can be added quickly without breaking anything. In the early days of Java, features were being added at a m
Re: (Score:2)
Can you cite the document that claims that the Loom project was supposed to be finished 3 years ago?
The initial (uber-optimistic) plan was to ship it in 2019. I can find that presentation probably, but I'm too lazy. OK, that's 2 years and not 3, but the current Loom is not getting released next year anyway.
Google's Go has less to lose than Java (Score:5, Insightful)
For comparison, during the Project Loom development timeframe, Google Go went from the first awkward version that used C-based implementation to fully Go-based self-hosting environment.
That's a poor comparison. Go is/was still in the early stages. Nearly EVERY business runs mission critical applications in Java and has since the early 2000s, if not late 90s, including huge portions of Google. That's like comparing innovation on some startup, like Rivian, to the Ford F-150, the best selling vehicle in the USA. If you mess up the exhaust in a rivian...OK, a minor expense. If you need a recall for the 2022 Ford F-150, the cost would be staggering. Similarly, any small mistake in Java leads to a HUGE expense, so they have to be more cautious. That's one of Java's biggest selling points: stability and quality.
You don't choose Java because you want the latest syntactical sugar or whatever cool features fit your idiosyncratic views on software development. You choose Java because it has a LONG history of stable APIs and rock-solid reliability as well as many underappreciated features, like excellent documentation ecosystem and a well established culture of best practices.. And before you bring up some bullshit anecdote, yes, there are a million idiots who work in Java and wrote the shite code that gave you some bad experience long ago, but when you follow best practices, Java is one of the most stable and reliable languages ever written. Part of that is that they have to support ancient technologies, like EJB 2, which were obsolete 20 years ago. Why? Because massive corporations sunk billions of dollars into EJB and the folks maintaining Java EE want to ensure they get a return on their investment and don't jump ship. It's annoying for me, someone who works in Java daily, but very good in the long-term strategic sense. However, they can't chase fads. Once you release it in Java, it will be around a very long time, so they are extra cautious.
Fundamentally, a 25 yo mission critical language that runs LOTS of large, complex profitable apps can never evolve as fast as new languages. That's just how business works. It's not like an iPhone where you can just drop headphone jacks and claim you're innovating and showing courage. A business app tends to cost a few million to a few billion. They get REALLY REALLY pissed if your new version costs them $200,000 to rewrite portions because you break things or declare a new keyword. Backwards compatibility and API stability is something taken very seriously in Java and their customers appreciate that. Java will always be more conservative than languages with less penetration.
Re: (Score:2)
Go is a toy, a fad language that people give a try for one project and then quickly abandon.
Re: (Score:2)
Re: Oracle is incompetent (Score:2)
Good luck to them.
Really old copycat features! (Score:1)
The "virtual" threads are an imitation of what Erlang has done well for over 30 years (see: BEAM engine). And no credit is being given. Additionally, Erlang and Ada already protected objects well in multithreading decades ago for safety, which Java probably still won't do effectively (it's a pain!):
Likewise, fast C calls are an imitation of what Python has done well for probably close to 30 years. Sad.
I've been coding in Java since 1997, and I've always been frustrated that it still hasn't caught up with