JVM Weekly #6 - What is data-oriented programming?
1. Why is Project Amber data-oriented programming?
Of all the JVM projects, Amber is the one that gets probably the least community heart and is the least defined. Well, because what is this legendary "Developer Experience" or "productivity" that Amber stands for? The whole project is a kind of umbrella, under which basically everything could be hidden, and it is difficult to find a single term that would elegantly bind all the initiatives under it.
That's why my eyes were so caught by Brian Goetz's article, in which he decided to use the term Data-Oriented Programming to describe the set of features that Amber brought (such as var, records, sealed classy, or pattern matching). As the author himself writes
Data-centric programming encourages us to model data as (immutable) data, and the code that contains the business logic for acting on that data should be kept separate.
So in a nutshell... anemic objects and the services that support them... something Spring developers have been doing basically forever.
But this is actually the tip of the iceberg. Goetz's text, which I highly recommend, is not only a technical introduction to the latest Java features, but also a really interesting, somewhat philosophical decomposition of what object-oriented programming is. Brian makes an attempt to understand why OOP is no longer as popular as it once was. One possible reason in his eyes is... the move away from Monolith and the regular downsizing of our projects (microservices, serverless functions).
But Amber wasn't the only thing written about in the community recently. The Inside Java blog featured the second part of a guest series on the Panama project created by Denys Makogon. We had a chance to write about Panama before, recently in the context of experiments with sorting algorithms, but it is hard to call that article a good introduction. Makogon's text works much better as a groundwork.
2. New JBoss EAP is coming
Usually, when we write about Jakarta EE, the discussion revolves around the specification itself or WildFly - the most "thriving" of all application servers. There is a good reason for this - that is the only one of them that is developing in a dynamic way. Such, for example, JBoss EAP (Enterprise Application Platform, not Early Access Preview) is released quite rarely. However, that makes each new "major version" a big event. That's why the mere fact that RedHat has announced that its eighth edition will appear early next year catches the eye.
JBoss EAP is based on WildFly. If the developers want to ensure full compatibility with Jakarta EE 10 (which they promise to do), they will have to rely on WildFly version 27 as a minimum. The JBoss developers deliberately skipped Jakarta EE 9 - as this mainly involved migrating the namespace javax.*
to jakarta.*
. Redhat feared that forcing such an unbusinesslike change on application developers would prove to be a shot in the knee and potentially drive away the remaining users.
What is important, already at the end of the year users will have the opportunity to test - because then the Beta version of the new release will appear.
3. Release Radar: ZIO, jOOQ and Quarkus
ZIO 2.0
ZIO is one of the more popular scala libraries and implementation of the IO Monad. The IO Monad is a special monad that wraps expressions in a way that allows "functionally pure" execution of input-output (IO) operations. What does the second edition of the ZIO library introduce in that manner?
Let's start with the information that will probably start appearing more and more often soon - the new ZIO has been optimised for Loom. This is not the only connotation with Java - the creators boast that the API of the library has been improved and is now more pleasant to use for developers who have more experience with Java. Streaming features have been improved, as well as overall performance. The creators also boast of improved monitoring.
The whole blog post with the announcement is well-written and full of details, and if you are interested in the topic of Monad IO - I invite you to a very good introduction in the form of a 36 minute video
jOOQ 3.17.0
Last week also saw the release of jOOQ version 3.17. The new version now better supports both reactivity and Kotlin coroutines "under the hood". It also drops support for both Java 8 and Java 11 - the free version will only run with Java 17. If you are forced to use older JDK LTS, you are left with the commercial version. In return, the developers promise broader support for features available in the new Java (as a result of Project Amber), such as records and sealed classes.
In terms of functionality, certainly the biggest novelty is the customer-only calculated columns. These can be thought of as "views" stored in jOOQ, for individual columns. A particularly useful combination of features is the combination of these enumerated columns with the new visibility modifier, which allows the underlying primary columns to be kept private, and therefore invisible to user code. They also allow the generation of audit columns. Unfortunately, the functionality is only available in the commercial variant. This one also receives improved support for transforming between formats.
From the more minor changes - there is support for new PostgreSQL data types, and a new API for Implicit (implicit) JOINs. These have already made their way to everyone (even open-source edition).
Quarkus 2.10
And finally, the new Quarkus 2.10, which like its predecessors is very interesting.
I've only just predicted that Loom will start to make its rounds among the announcements of new features, to be able to come back to the topic just now. Itโs because Quarkus has announced its first forays into Loom support. It did it in a truly java style, as it simply added... @RunOnVirtualThread annotations.
Most of the changes revolve around asynchronous I/O. We get improvements to SmallRye Reactive Messaging, Kubernetes support in Reactive SQL Client and a non-blocking variant of GraphQL support. Minor improvements hit quarkus-cache
and quarkus-bootstrap-maven-plugin
.