Loom/Valhalla/Panama/Amber Timeline, Minimal Yet Functional Runtime Images
nipafx news #93 — 30th of January 2021
Hi everyone,
and happy new Gregorian year! Hope you all made it into the second rerun of 2020 in good health and with lots of energy to tackle whatever the world throws at us next. I’ve been doing well so far (thank you for asking) and after a slow start got into things eventually. This week was particularly hectic but fruitful, so I’m content.
Today I got my speculations on the Loom/Valhalla/Panama/Amber timeline, details on creating a minimal but functional runtime with jlink, and some shots for you. Enjoy!
I send this newsletter out some Sundays. Or other days. Sometimes not for weeks. But as an actual email. So, subscribe!
Speculations on feature timeline
(This is the extended version of a YouTube comment. You may know parts of it, but not all — skip at own peril. ;) )
Before I get to the timeline, I need to put in a caveat: This is really just my personal guess. I don’t ask the devs for their estimates because I’d either get the official, vague reply or I’d get details that I can’t share. So all I know is from the JEPs, mailing lists, talks, etcetera. That means this is no official Oracle announcement, you can’t trust a word I say (imagine safe harbor slide), and you better not base business decisions on my ramblings.
Equivocations
Project Loom
Project Loom currently has two draft JEPs, one on virtual threads, the other on structured concurrency. I’m really hoping for them to be in JDK 19 but I don’t quite see it. While the overall progress seems to be pretty far along, the JEPs are still drafts and I would expect it to take a few months between actual proposal and merge for such a monumental change like this one. And keep in mind that JDK 19 will be forked in June, so there’s only a few months left. That’s why I put Loom’s first previews into JDK 20.
I also expect more structured concurrency APIs or further additions to the currently proposed one to show up in future versions. Not sure how long that will take, but I think once the project passes the hurdle of first release on the main line, it won’t take too long, so I’m guessing 2024 for that.
Project Valhalla
The current version of the stellar State of Valhalla ends with:
We intend to divide delivery of Project Valhalla into three broad phases: identity-free value objects first; then primitive classes, migrating the existing primitives, and universal generics; and finally specialized generics.
There are (draft) JEPs for most of that and the Valhalla EA build already demonstrates parts of the proposed functionality, so I’m expecting the first phase (value classes) soon, lets say JDK 20. I think primitive classes aren’t far behind and to make sure they can be used properly out of the gate universal generics (i.e. ArrayList<int> compiles) will land with them, so I pegged both for JDK 21.
I have less of an idea how far along specialized generics (i.e. ArrayList<int> is backed by int[]) are, but it's clearly a monumental task. I think the preceding two phases won't start until Brian Goetz et al are convinced that they'll work well with how they conceive specialized generics to be implemented and so I'm sure they have a pretty good idea how to do that, but I'm hesitant to expect them too early. So... 2025? (Don't hurt me!)
Project Panama
Panama works on two topics: interaction with foreign code/memory and the vector API. The former is coming along really well and has seen its first incubation in JDK 14. In December, Maurizio Chimadamore stated on the mailing list that we’ll see the first preview in JDK 19 — first one in the board for the fall release. ^^
The vector API has been incubating since JDK 16 is basically done, but needs Valhalla’s primitive types in its API and so, to avoid breaking changes, is on pause until they land. My guess is that Paul Sandoz et al will take the first chance they get to turn their work into a proper preview and that it will land in the same version as the first preview of primitive classes, so I’m guessing JDK 21.
Project Amber
Amber has a bunch of ideas in the pipeline and sometimes they come into the public space rather abruptly. String templates, for example, which I heard nothing about until there was suddenly a draft JEP. The idea seems pretty far along and I think we’re gonna see that one soon. So to appease you folks with something new in 19, I put it in there. :D
I’m expecting Amber’s current main thrust, pattern matching, to progress with deconstruction patterns in JDK 20 (maybe 19, but judging from the surprising lack of progression in 18, I’m guessing there’s something that needs to be worked out) and then more patterns in 2024.
Overall, Amber is the most unpredictable and I give good odds for something we don’t know about now to be previewed in 2023/24.
Timeline
All put together (releases/years are guesses for first previews, not full standardization):
JDK 19 (2022):
- template strings (Amber)
- foreign memory/access APIs (Panama)
JDK 20 (2023):
- deconstruction patterns (Amber)
- virtual threads (Loom)
- structured concurrency API (Loom)
- value classes (Valhalla)
JDK 21 (2023):
- primitive classes (Valhalla)
- universal generics (Valhalla)
- vector API (Panama)
2024:
- more structured concurrency (Loom)
- more/custom patterns (Amber)
2025:
- specialized generics (Valhalla)
Creating a minimal but functional runtime with jlink
Somebody recently Twitter-DM’ed me a StackOverflow question on how to determine the JDK modules required by Logback, wich doesn’t ship a modular JAR. (Btw, if your SO question is stuck and you think I can help, feel free to ping me.) The answer is independent of Logback, so I thought I’d post (and slightly rephrase) it here…
As mentioned, the problem with that specific JAR is that it’s not modular. So if you run jar --describe-module or java --describe-module the requires section will be incomplete. You can recognize this by the "No module descriptor found" in the first line of the output. So the JAR can't tell what modules it depends on and you have to find out yourself. The canonical tool for that is jdeps but it may not be enough.
Static Dependencies
I wrote a jdeps tutorial that gets you started, but the interesting bit is this section. The gist is this command:
jdeps
--class-path 'jars/*'
-summary -recursive
logback-core-1.2.3.jarWhere jars contains all Logback dependencies. (If you don't have those at hand, you can leave --class-path and -recursive out, but then you won't know which modules the dependencies need.) Besides a few other things, the output will list the dependencies on JDK modules.
Dynamic Dependencies
jdeps works by analyzing byte code, which means it will only find dependencies that are statically linked. Consequently, if a JAR uses reflection, the service loader, or other mechanisms to avoid explicitly mentioning the classes it wants to use, jdeps will not notice them.
To find those cases, you can run an app with the java command-line option -XX:DumpLoadedClassList=classes.lst (intended for creating application images, but works here as well). It will generate a file classes.lst that lists all loaded classes. Getting from there to modules (via the packages) is a bit unpleasant, but it will contain every module that was touched while the app ran.
Minimal Runtime
Note that the base module java.base uses a lot of services that are provided by other modules, for example locale data by jdk.localedata. That means a minimal runtime (i.e. one where service provider modules are not included) may miss things that an app needs (in the example, maybe locales). You can list the base module’s services with java --describe-module java.base (see list of uses ... in output) and then find potential providers for each with jlink's --suggest-providers option.
You can include all available providers with jlink's --bind-services option and this would be the same runtime you'd get via the class list as described above. But that immediately abandons the idea of a "minimal" runtime as it will include a lot of modules. If you're going for "minimal", probably better to include them one by one as needed.
Whatever you do, make sure to thoroughly test your app on the custom-made runtime.
Shots
Here’s what I published this month (feeling quite good about that list :) ):
- Java’s Plans for 2022 — Inside Java Newscast #18
- a #SipOfJava on JDK 17’s random API
- Where to use Optional — Inside Java Newscast #19
- More Opinions on
Optional - an experiment with Loom’s features
And here are a few random but pretty cool things that others put out there:
- a better experiment with Loom’s features
- automated Wordle solvers with Playwright:
* by Tom Cools
* by Johannes Kuhn
* latter wrapped in jbang by Max Rydahl Andersen - goldfish steer robot on land (I for one, …)
- the arrow that can’t point left
Long shot is Dan Olsen’s Line Goes Up — The Problem With NFTs, a 2:18h video on everything broken with cryptocurrencies, NFTs, the communities they evolve in, and the circumstances that birthed them — worth every minute. If you want to be extra-thorough, watch the movie The Big Short before his video.
so long … Nicolai
PS: Don’t forget to subscribe or recommend! :)
