JDK enters 2023: plans for the year, first JEPs and Preview feature retrospective - JVM Weekly #31
Well, after a rather slow start, 2023 can finally be considered to have officially begun - both JEPs and Java mailing lists have awakened from their winter sleep.
1. What will 2023 bring for Java?
To get today's edition off to a good start: Nicolai Parlog, Developer Advocate for Java at Oracle, as he does every year, has prepared a summary of what the JDK developers have in store for the next twelve months. To convince you that this will be the best-spent 10 minutes to build yourself a picture of Java in 2023, it's worth taking a look at just the scope of the video.
In less time than it takes to listen to the full version of Archive's song "Again" (which I also recommend!) Nicolai goes through not only Looma or Panama, but will also give you a better understanding of the plans for GraalVM, the Leyden project, or Lilliput. If you read this newsletter regularly, you've probably heard the names before, but I still recommend that video - I love how neatly and dynamically he manages to go through all these topics in such a short time. I think that even if the topics are familiar to you, the whole thing both put them in a broader context and gives you some repetition (and repetitio est mater studiorum).
Well, now we all stop reading and see you back in 10 minutes (this is not the end of today's edition, I have some more highlights for you, so come back after watching):
You have to admit that 2023 promises to be very tasty. Personally, however, I hope that this is not all yet - after all, 2022 brought us quite a few surprises.
Sources
2. First JEPs A.D. 2023
And as we already know what 2023 has in store for us, it's time to take a look at what it has already brought. January has been slow to get going, but the last week has seen a mix of interesting announcements and news straight from the Java mailing lists.
The first is the JEP being prepared under the umbrella of Project Amber: No longer require super() and this() to appear first in a constructor. It belongs to my favorite category of changes - very practical on the one hand, heavily minimalistic on the other, and on top of that - heavily complicated and making me understand better (and I hope you do too) How Java works under the hood. For we are talking about an attempt to eliminate one of the more incomprehensible for beginners, and annoying for experienced programmers, Java mechanisms - the requirement to directly call the constructor of the class you inherit from as the first operation in the inheriting class.
In short, the new Draft wants to enable, e.g. validation like that, currently impossible in Java (an example straight from JEP):
public class PositiveBigInteger extends BigInteger {
public PositiveBigInteger(long value) {
if (value <= 0)
throw new IllegalArgumentException("non-positive value");
super(value);
}
}This change has two very interesting aspects. First (which is easy to predict) - it is not so obvious to carry out, because of backward compatibility or some edge cases of creating class hierarchies, which is well described in the mentioned JEP. However, I recommend reading it also because the whole thing nicely highlights that the specification of Java as a language and the specification of the JVM have a slightly different level of "permissiveness". The fact that the JVM allows more probably won't surprise anyone (after all, languages like Kotlin and Scala were built upon it), but here this rarely discussed aspect has been brought out in a simple-to-understand example.
Information about the second change to be brought by Java in the near(?) future comes not from JEP, but directly from mailing lists. The developers of the language have strongly taken to heart the refresh of the JavaDoc standard. 2022 enabled adding code snippets to docs, and currently there are discussions on the possibility of support for Markdown as well. Jonathan Gibbons of Oracle noted the advantages of this markup language. However, he points out several problems, especially when it comes to compatibility with the current solutions used by JavaDoc, which is heavily based on HTML. And if only for the above argument, the original message and the budding discussion from it are worth reading. It once again shows how many tradeoffs happen in such a complex ecosystem as Java.
To summarize this section - back in December, there were several new items in the Java issue tracker, regarding work on the Class Data Sharing mechanism. That were improvements at the interface with the G1 Garbage Collector (1)(2) or improvements to the API and better support for other GCs. It's not something that strongly affects the end user, but I'm sharing it because these changes have been announced as a pre-cleanup for the Leyden project and they will appear in JDK 20.
In the next section, we will discuss the last of the JEPs - for it is strongly unique.
Sources
3 What the future holds for the Preview track - A retrospective after four years
Did you know that the new Java release mode is already 4 years old? The generation of JavaScript frameworks has had time to be born and die in that time.
The changes introduced in 2019 not only shortened the period between new Java releases to every six months, but also, as part of JEP 11: Incubator Modules and JEP 12: Preview Features, introduced two new testing tracks into the language - Preview and Incubation. Now it's high time to look at how they have worked in practice. A special JEP draft: Preview Features: A Look Back, and A Look Ahead has been released, in which Alex Buckley, Specification Lead for the Java Language, analyzes what worked, which concerns fell short, and which areas need improvement.
In short: "Previews" have met expectations. They allowed JDK Team to receive faster feedback from the community, test new features, and (slightly) iterate on them in an open public. Consider, for example, a wide response in the community (and a rash of publications) to the release of virtual threads as Preview. In addition, the speed of new features adoption by all kinds of tooling and IDEs has also been greatly improved, as they can work on a nearly stable API well in advance. So, Previews were a great idea, but...
The Preview was originally intended to be a phase in which language features are already stable enough to remain there for a relatively short time. In practice, however, we have already seen functionalities having a fourth Preview (I'm looking at you, Pattern Matching). The mentioned JEP examines the reasons, and these are varied. Mostly, however, they boil down to dependencies - waiting for other parts of the language to develop and the need to adapt to these external changes. An example of this is the second iteration of Virtual Threads, which had to come out mainly due to the appearance of new methods in the Thread class, thus slightly changing Virtual Threads API. However, each prolongation of the Preview phase is a somewhat different background and covers an additional corner case, making it difficult to come up with a single, common solution. Some option could be a broader adoption of the incubation phase, but this too, in its current form, is not a rule-them-all solution to the problem - incubated functions cannot be used in other parts of the language. This makes sense, as they are inherently unstable, but are therefore unsuitable for developing broader initiatives.
Conclusions? None so far, but first of all we are dealing with the Draft, and secondly there is value in just going back to the roots and doing a retrospective. It remains to be seen what next steps will be drawn from such.
Sources
Bonus: Source Buddy and the World's Most Buzzwordy Minesweeper.
To sum up this edition, I have two projects for you to play with today. Both are so interesting that I would love to see them get a slightly larger audience.
Source Buddy
The first is Source Buddy, a kind of eval for Java, whose first official release was on January 4. The library allows you to pass (as a String) a piece of Java code, which it will compile and generate working Java objects for you. Take this excerpt from the official readme as an example:
String source = """
package com.sb.demo;
public class MyClass implements Talker {
@Override
public void say() {
System.out.println("Hello, Buddy!");
}
}""";
Class<?> myClassClass = Compiler.compile(source);
Talker myClass = (Talker) myClassClass.getConstructor().newInstance();
myClass.say();
Would I run it in production? I do not even think about it, but I imagine that in the case of some small scripts written for local purposes such poor-man-metaprogramming can be quite a helpful tool. Therefore, I think it is worth being aware of its existence.
minesweeper-csp
The second of the projects is Minesweeper - but not such an ordinary one. Elliot Barlas' project, ebarlas/minesweeper-csp is an introduction to as many as two different programming concepts.
First, his project uses Virtual Threads. Admittedly, there's no shortage of good samples demonstrating the use of Loom in practice (I recommend Loom Lab from Nicolai Parlog, mentioned in the first section), but I'm always happy to cozy up to another one. In addition, we're dealing here with a game whose rules are familiar to basically everyone, thus avoiding the need to explaining the domain.
The second, even more interesting aspect of the project is the concurrency model adopted by Elliot. This is because the project is based on CSP - communicating sequential processes - which is the basis of how concurrency works in the likes of Go, and technique available e.g. in Clojure or Kotlin thanks to Coroutines. Until now, this way of programming has been beyond the reach of Java programmers, but thanks to the Loom project, the range of solutions available to us has finally expanded. If you're looking for a good introduction to CSP I recommend the primer from Stanford University, Rich Hickey's presentation "Core async Communicating Sequential Processes using Channels, in Clojure" on the implementation of this functionality in Clojure, or simply analyzing the code of described minesweeper-csp.
Time for Memories: my first desktop application (and one of the last) was Minesweeper written (and somewhat cliched) in Borland C++. A few applications gave me so much joy after that.
