Here comes the 100th edition! And in it, finally, the first JEP in a long time, a new Android, support for Virtual Threads in Jetty, and a lot of Kotlin releases.
1. The first new JEP in a long time!
We have not had the opportunity to update you on any new JEPs for some time. There are (I suspect) two reasons for this: the holiday season and the preparation period for the release of the new JDK. However, August is slowly coming to an end, JDK 19 has already received its first Release Candidate, so you can think about the future. Hence, I am undoubtedly delighted to inform you that the candidate JEP 429: Extent-Local Variables (Incubator) appears in the 100th edition of our Weekly. Let us, therefore, take a look at what lies behind it.
What are extent-local variables? They are an alternative to the existing ThreadLocal, created as a companion to Project Loom. Their purpose is to allow the sharing of non-mutated data within and between threads. Their use would look like the following.
final static ExtentLocal<...> V = new ExtentLocal<>();
// In some method
ExtentLocal.where(V, <value>)
.run(() -> { ... V.get() ... call methods ... });
The above structure has several advantages. Firstly, it allows a very specific range of ‘validity’ of the variable to be specified – something that could not be achieved with a regular ThreadLocal, which is a kind of data bag. In the above case, V does not have a .set method – so it is (unfortunately, only in a ‘shallow’ way) non-mutable additionally, it should be declared as final, and its value is only set in the where method. In a somewhat convoluted but effective way, this is supposed to solve the problem of accidental substitution of a reference value coming from ThreadLocal.
What about the good old ThreadLocal, already summoned in this text? I will reassure you that the new variable type from JEP 429 is not intended to replace it and force its migration. Both solutions will live in parallel. However, I recommend reading the new JEP to any (aware) ThreadLocal user – with the motivation of extending Java with extent-local variables, the developers have pointed out quite a few disadvantages (but also advantages) of the existing solution.
You can see from the JEP above how strongly Loom is driving the further development of the language. And speaking of Loom…
Sources
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs.
Download the app and read the good stuff!
2. Jetty gets support for Project Loom
Jetty, a library providing a stand-alone implementation of a web server and servlet container, remains one of the most popular solutions of its kind. Although the competition in the form of Embedded Tomcat, Undertow or Netty has been biting it somewhat hard recently, this is very good news from the developers’ perspective – the competition forces continuous development. That is why we are happy to announce official project support for Loom.
The changes will come into effect with new versions of Jetty 10.0.x (10.0.x is to be supported first), but the whole thing is eye-catching for more than just being the next big project to support Loom. Personally, I find it cute that Alan Bateman himself suggested in the closed PullRequest the improvements that the developers have made. There’s always something very charming to me about how Java developers respond to Reddit/hackernews threads or just do Code Review on projects.
If anyone is curious about how the whole thing was implemented – here you have a specific commit.
Sources
3. Android 13 brings Java 11 support
At the beginning of the week, the new Android 13 was premiered. This shows well a certain change in thinking about this system. Where once its release was a big event, today’s launch meant “merging” the whole thing into the main branch of AOSP (Android Open-Source Project) and releasing a new version for Pixels, while waiting for the rest of the market players to make their moves – a bit like the Linux Kernel. Also, from my perspective, the list of new features is quite similar to what update of Linux internals brings – from a user’s point of view, Android 13 is a bit more customisable (e.g. language version of specific applications)… and that’s all.
From a programmer’s point of view, there is a bit more. Of course, there are the standard performance improvements (better Garbage Collector and faster JNI access) in addition to new features for developers, such as a new font API to make it easier to work with non-Latin characters and better rendering performance, as well as support for the COLRV1 standard. Bluetooth LE Audio, MIDI 2.0, and better shader support also come live. The icing on the cake is the mass of new permissions developers must collect from users before accessing their data.
However, I’m mainly writing here because Android is transitioning to JDK 11. The latest edition internally transitioned to Java 11, introducing the platform min. The ability to use var, VarHandle with java.utl.concurrent or many other auxiliary APIs (like ifPresentOrElse() on Optionals ❤️). It is apparent that the results of the Google/Oracle trial last year have untied the developers’ hands and they will be slow to implement Java innovations into Android.
The full list of changes can be found here from the invaluable XDA Developers.
BTW: Did you know that Google continues to internally use dessert names to name the next versions of Android? “Thirteen” is internally “Tiramisu”.
Sources
- Android 13 is in AOSP!
- Android 13 ‘Tiramisu’: Everything we know so far about Google’s next big update!
Discover more IT content selected for you
In Vived, you will find articles handpicked by devs.
Download the app and read the good stuff!
4. (Kotlin) Release Radar
And finally, Release Radar. This time a very Kotlin-esque one.
graphql-kotlin 6.0
Do you use GraphQL? If so, especially for you, we will start with the new major release of Kotlin GraphQL, a library developed by ExpediaGroup. With the new release, it is supposed to be much simpler to propagate coroutine context, which will now be directly available to API users. The whole thing has also received all the fixes coming from graphql-java, over which it is a wrapper – the developers have updated the ‘guts’ to its version 18. The library has also received support for the Apollo Federation v2 specification, making it easier to modularise GraphQL ‘graph’) and APQ – Apollo Automatic Persisted Queries.
And while we’re on GraphQL and Apollo, the developers of Apollo Kotlin have gone very much Multiplatform, with the platform getting a new Memory Manager, which will become official with Kotlin 1.7.20.
Kotlin API for Apache Spark 1.2
We now call for a response from Spark users. The new Kotlin API for Apache Spark 1.2 is a big breath of fresh air for Spark users. After a long wait the developers have finally provided support for previously unavailable User-defined Types and User-Defined Functions. Now application developers can create new data structures using the Kotlin API and operators that can then be used when querching a dataset. Compatibility with Jupyter Notebook has also been enhanced.
In addition, a Scala API for Resilient Distributed Datasets has been sported. Until now, the basis was the Java variant, which, however, had several limitations, enforced by the limited expressivity of Java itself. As Kotlin is a more modern language in this respect, it was decided to base the new API variant on the Scala edition.
Interesting fact: in order to maintain full compatibility with Spark and the Scala edition, JetBrains has released 14(!) different versions of the API, supporting combinations of Spark from 3.0.0 to 3.3.0 and Scala from 2.12 to 2.13 – they are doing this for all those who, for some reason, are unable to use the latest versions of either project in production.
Ktor 2.1
And finally – Ktor. One of JetBrains’ standard projects has indeed received its first major update following the release of version 2.0.
The new ktor is first and foremost a toolbox. First and foremost, the Ktor CLI (interestingly, written in Kotlin Native!) allows you to create a new project. The tool is now available for macOS and Linux, with a Windows version available in the future. Download instructions can be found in the project’s official repository.
However, this is not the only way to create a new project with ktor’s support. Do you still remember Yeoman? This once very popular frontend project generator has expanded its scope over the years, providing so-called ‘generators’ for other technology stacks. Let’s confess: who has used or is still using yeoman?
The new Gradle plugin is the last of the tools that can make our work with Ktor easier, making it easier to release applications. The resulting artifact can now be easily configured with the help of the Grail DSL into a FatJar, Docker image, or GraalVM binary.
And as a bonus, fans of YAML can now use this standard to define configurations.
Sources
Discover more great content!
- Save time and effort
- Read handpicked articles
- Free yourself from spam
