Everything you might have missed in Java in 2024 - JVM Weekly vol. 114
As they say - new year, new us. But before we jump full-speed into 2025, it’s time to clear our heads and go through a (slightly overdue) recap of 2024.
And the truth is - I thought it would be a bit shorter... but quite a lot happened.
JDK 22 and JDK 23
Let’s start with the "foundational" stuff. As in every year, 2024 saw the release of two new JDK versions. While they may not be as groundbreaking as JDK 21, they still introduced several significant features that will undoubtedly "make a difference" in certain projects.
One of the standout developments is the stabilization of the Foreign Function & Memory API (JEP 454). After years of anticipation and experimental iterations, we finally have a full release. It's about time — interoperability with native code is becoming increasingly important, and having a stable API for it is a welcome development. This also ties into the broader closure of platform loopholes,like JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal introduced in JDK 23.
The year 2024 also saw steps aimed at simplifying the usability of the entire platform. JEP 467: Markdown Documentation Comments is a long-awaited refresh of JavaDocs, while JEP 456: Unnamed Variables & Patterns and JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) are steadily finalizing efforts to introduce pattern matching in Java, making it work consistently across all the syntax. Additionally, efforts to reduce "ceremonial" in coding have made strides with JEP 458: Launch Multi-File Source-Code Programs and JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview), which aim to lower the entry barrier and reduce the tooling requirements (would you really want to learn maven/gradle in parallel with for loops?) for newcomers. Modules also received some attention — JDK 23 introduced an experimental version of JEP 476: Module Import Declarations, significantly simplifying dependency management in modular applications.
What’s still missing? Valhalla (with the poor Vector API still stuck in incubation despite increasing adoption) and the long-awaited children of Project Loom: Structured Concurrency and ScopedValues, which remain preview features. However, considering that JDK 24 will introduce a test version of the solution to the biggest Virtual Threads issue (Thread Pinning), it seems the creators are gearing up for a more substantial release — perhaps a Virtual Threads 2.0.
Of course, JDK 22 and 23 encompass much more than the above features, and many of the changes they introduced will significantly influence JDK 24 (and likely JDK 25) this year. There were also numerous under-the-hood changes. However, to keep this edition from becoming a marathon, you can find more details in the newsletter issues dedicated to these releases:
Java 22 and GraalVM for JDK 22 Released! - JVM Weekly vol. 76
Java 23 and GraalVM for JDK 23 Released - JVM Weekly vol. 100
However, no yearly summary would be complete without mentioning a feature that surprisingly disappeared from the list of active JEPs.
String Templates – The First Preview Feature Sent Back to the Drawing Board
In 2024, the Java developer community witnessed an unusual situation: the String Templates feature, initially introduced as a Preview, was withdrawn and sent back to the drawing board for redesign.
String Templates aimed to simplify and streamline working with dynamic strings, removing the need for manual concatenation and formatting. However, after analyzing user feedback, the JDK development team decided to rethink the feature. This decision was largely influenced by the discovery of better solutions to some of the original design challenges, though implementing these solutions required broader rework.
The process of withdrawing and reworking String Templates highlights that even advanced Preview features are, indeed, previews. They may require additional refinement and significant evolution before being permanently integrated into the language.
Read more in:
GraalVM for JDK 22 and JDK 23
We talked about JDK, now it’s time to discuss its younger sibling – GraalVM. A lot of significant improvements were made, especially regarding Native Image.
The GraalVM for JDK 22 release introduced an enhancement with its new default class initialization strategy, first introduced as an experimental feature in GraalVM for JDK 21. This strategy simplifies the process of distinguishing between classes intended for build-time and run-time initialization during image generation. For classes designated for build-time initialization, their static fields are preserved and carried over into the runtime, maintaining the state established during the image generation process. Conversely, classes marked for run-time initialization remain uninitialized at runtime, even if they were previously initialized during the build, effectively mirroring the current "re-run initialization at run time" method but without its complexity or unintended side effects.
Similar to other "native" compilers, GraalVM users can control the optimization level using the -O option. GraalVM for JDK 23 introduced a new optimization level -Os, which allows executable files to be reduced by up to 35%, at the cost of reduced performance during compilation.
In 2024, GraalVM team also introduced a mark & compact GC for the old generation of the Serial GC, aiming to reduce peak memory usage compared to the copying GC, which can use up to 2x the current heap size when all objects survive. Additionally, GraalVM brought the Oracle GraalVM Buildpack (a set of open-source buildpacks designed for building and deploying applications in containerized environments), making it easier to integrate with existing projects, especially those based on Spring Boot. We also got a new feature for generating a Software Bill of Materials (SBOM) directly in the native image or as a resource on the classpath.
But I've saved the most exciting surprise for last. In Oracle JDK 23 (and, as far as I understand... only in it?), the Oracle GraalVM JIT compiler (Graal JIT) was introduced as one of the JIT options available to JDK users. Thanks to this, all Oracle JDK users can take advantage of code optimization techniques that were previously only available in Oracle GraalVM. The integration of Graal JIT offers new possibilities that can help developers and administrators optimize application performance. Although Graal JIT in Oracle JDK is treated as an experimental feature, it is fully supported commercially by Oracle and Oracle Cloud Infrastructure. This change is quite... surprising—to say the least, it's like a second attempt at the subject. Graal JIT was already added and removed from JDK. Moreover, it appears that this is not related to the Galahad project, whose goal is to integrate JIT with OpenJDK.
Read more in:
Java 22 and GraalVM for JDK 22 Released! - JVM Weekly vol. 76
Java 23 and GraalVM for JDK 23 Released - JVM Weekly vol. 100
JetBrains Released Kotlin 2.0
It’s not just Java that’s advancing — in May, JetBrains officially released Kotlin 2.0.
The most significant change is the stabilization of the new K2 compiler, which has become the default for all supported platforms, including JVM, JavaScript, Native, and WebAssembly. The K2 compiler, in addition to performance improvements (BTW: have you ever seen release notes that say, "Honestly, we completely botched performance this time"?), features a unified architecture across all platforms. This simplifies the development of multiplatform projects and streamlines tooling enhancements for the language development team. Kotlin 2.1.0 also allows generating classes using JDK 23 bytecode.
Kotlin 2.0 (and Kotlin 2.1, which has already been released this year) also brings new language features. For instance, it introduces guard conditions in when expressions, enabling more advanced logic in branches, as well as non-local break and continue, which increase code flexibility in inline functions. Kotlin also enhances multi-dollar string interpolation, making it easier to work with template systems and formats that require dollar signs.
Read more in:
JVM Weekly vol. 77: Kotlin 2.0 getting closer, IntelliJ Idea introduces K2 Mode
JVM Weekly vol. 84: Kotlin 2.0 & opinionated Wrap-up of KotlinConf 2024
JVM Weekly vol. 110: Release Radar: Spring, Kotlin, IntelliJ... and Advent Calendars
Clojure 1.12 - the first new version in over two years
One of the key new features in Clojure 1.12 is the add-lib function, which allows dynamic addition of libraries during a REPL session without restarting the environment. This function enables interactive experimentation with new dependencies, greatly improving the prototyping and testing process.
This version also brings improvements in interoperability with modern Java APIs. Support for "functional interfaces" has been added, enabling direct passing of Clojure functions as arguments to Java methods expecting functional interfaces. Additionally, stream handling has been introduced, allowing transformations of Java streams into Clojure sequences using functions like stream-seq!, stream-reduce!, and stream-into!.
Notably, Clojure 1.12 is the last version compiled to Java 8 bytecode. Future releases will raise the minimum Java version to a newer LTS, requiring developers to update their runtime environments accordingly.
And while Clojure's star has dimmed a bit recently, I believe its time will come again.
Read more in:
The Jakarta EE is slowly Bidding Farewell to EJB
The upcoming work on Jakarta EE 12 marks a new direction for the platform's development. A significant shift is becoming increasingly evident – the move away from Enterprise JavaBeans (EJB), a technology that was once a cornerstone of the old platform but is now giving way to more, more approachable solutions - as a platform has an opinion of rather... bloated.
The history of EJB, which began in the 1990s with Sun Microsystems, reflects the evolution of technology from a tool for transaction management and synchronization to a symbol of "heavyweight" and complex architecture. In response to these challenges, Contexts and Dependency Injection (CDI) was introduced in Java EE 6, providing flexible mechanisms similar to Spring. CDI has since become the preferred technology, replacing EJB with its greater modularity and simplicity.
The current plans for Jakarta EE 12 emphasize the complete replacement of EJB with CDI technology. Proponents of this change argue that EJB is not only challenging for new users but also less competitive compared to alternatives like Spring. On the other hand, EJB advocates point out that it offers useful features such as automatic transaction management and concurrency handling, which are not fully available in CDI.
As a result, there are suggestions to introduce migration guides, modernize documentation, and develop new CDI stereotypes to facilitate the transition from EJB for the user using the features only available there.
Read more in:
We’ve wrapped up the major platform releases, so let’s take a look at the community.
1BRC – Testing the Limits of Java's Performance
In January 2024, Java developers were invited by Gunnar Morling to participate in the One Billion Rows Challenge (1BRC), a contest designed to test the limits of Java’s performance in processing massive datasets. The task was to implement a program in Java 21 capable of processing one billion records from a text file in the shortest possible time. The challenge included constraints such as a ban on external libraries and the requirement to complete the solution in a single code file. The event attracted both language enthusiasts and optimization experts.
When the results were announced, the top teams had achieved processing times of under two seconds, demonstrating Java’s tremendous potential for performance optimization. Many of the submitted solutions leveraged advanced techniques like efficient parallelism, memory allocation optimization, and data buffering strategies. Additionally, allmost all of the solutions were ultimately executed on GraalVM. The 1BRC challenge highlighted the incredible possibilities offered by advanced JVM mechanisms when combined with the right knowledge and approach.
The 1BRC also served as a reminder of how far the JVM has come, showing that performance boundaries can be pushed with innovative solutions... but also some plain old algorithmic knowledge. The more you will find in the following video:
It reaffirmed that Java, despite being "mature", remains a competitive language for highly demanding data-processing tasks. It warms the heart in a world where all developers are being "cyborgized" - with all my fondness for the latter.
Read more in:
JVM Weekly vol. 67: 1BRC: Who's the Fastest to Process a Billion Java Records?
JVM Weekly vol. 70: Results of #1BRC: So what do we need Moonshots for?
Early Steps Toward the MicroProfile AI Specification
The MicroProfile project community has been actively working on introducing an API for AI, focusing on integration with large language models (LLMs). The MicroProfile AI initiative, launched in March 2024, has gained momentum quickly. Currently, the team faces a strategic decision regarding its technical foundation—whether to directly adapt the API from the LangChain4J project by Dmytro Liubarskyi or to develop dedicated MP AI interfaces. A key aspect is also ensuring integration with existing MicroProfile technologies, particularly MP Telemetry.
A significant milestone in the project’s development was the creation of the reference implementation SmallRye LLM. Special attention was given to implementing the RAG (Retrieval Augmented Generation) pattern and integration with vector databases. The team is also working on extensions for CDI, enabling AI integration across various runtime environments. Inspired in part by the success of Spring AI, the initiative aims to establish a comprehensive AI programming model within MicroProfile, including APIs for interacting with language models and integrating with popular OpenAI libraries.
To be honest, I have a bit of an issue with the name of this project – AI nowadays is more often directly associated with GenAI/LLMs, but it's actually a much broader term. Well, such are the times we live in.
Read more in:
jSpecify: An Attempt to Tame Nulls
Once upon the time, Nicolas Fränkel 🇺🇦🇬🇪 published article Null safety: Kotlin vs. Java, in which he attempted to compare how the approaches to the concept of Null differ between these two languages. As part of his analysis, he summarized the existing null-related annotations on the market and listed eight(!) different variants, having different packages and (worse) slightly different behaviors.
But there is hope. In July 2024, version 1.0 of the jSpecify project was announced. This initiative aims to standardize nullability annotations in Java, providing a consistent set of annotations that enable static code analysis to identify potential NullPointerException issues, thereby reducing such errors.
jSpecify introduces four key annotations:
@Nullable: Indicates that a variable, parameter, or return value can be null.
@NonNull: Indicates that a variable, parameter, or return value cannot be null.
@NullMarked: Applied at the package or class level, it designates all unannotated types within that scope as non-nullable by default, reducing the need for repeated use of the @NonNull annotation.
@NullUnmarked: Allows disabling the effect of @NullMarked within a specific scope, facilitating a gradual adoption of annotations in large projects.
The introduction of jSpecify has been well-received by the Java community. For instance, the main development branch of the Spring Framework has migrated to using jSpecify annotations to improve null safety support in both Java and Kotlin. By standardizing nullability annotations, jSpecify has the potential to significantly enhance code quality and streamline integration between various static analysis tools and JVM languages (for example, Kotlin 2.1 has already begun respecting these annotations).
Read more in:
Vavr Loses and Gains a Maintainer
In 2024, the Vavr project, a renowned and respected functional programming library for Java, faced challenges in its management. Daniel Dietrich, the founder and main maintainer, announced his withdrawal from active development of the project. He cited a desire to focus on other initiatives and his personal life as reasons for stepping back. During this time, the Vavr community expressed concerns about the library’s future, as it continues to play a key role in promoting functional programming in Java with features like immutable collections and monads. The search began for a new maintainer capable of not only sustaining the project but also driving its development to meet the community’s needs.
In July 2024, it was announced that Grzegorz Piwowarek , well-known in the Polish (and broader) Java community. His first goal is to release the long-promised version 1.0. Congratulations Grzesiek! I still remember your old talks about Vavr and I'm glad the project is in very good hands.
Read more in:
Follow the Money: The Financial Background of Open Source in the Java Ecosystem: JVM Weekly vol. 88
32-bit Java Loses the Main Maintainer… and Vavr Gains a New One: JVM Weekly vol. 93
Deno Creator Seeks to Reclaim the JavaScript Trademark from Oracle
In November 2024, Ryan Dahl, the creator of Deno and Node.js, filed a formal request with the United States Patent and Trademark Office (USPTO) to cancel Oracle's trademark for "JavaScript." Dahl argues that "JavaScript" has become a generic term and that Oracle does not actively use the trademark for commercial purposes, providing grounds for its cancellation.
On January 7, 2025, Ryan Dahl shared an update on X:
It will be interesting to see developments of this case.
Lightbend, the Creators of Scala, Are Now Akka
In November 2024, Lightbend, the company known for supporting the Scala programming language and creating the Akka platform, announced a rebranding to Akka , emphasizing the framework's importance in its portfolio.
Alongside the rebranding, the company launched Akka 3, a platform designed to simplify the development and deployment of resilient, agile, and fault-tolerant applications. The new version integrates existing products such as Lagom, Play Framework, and Akka Streams, offering a streamlined SDK and support for Serverless and BYOC (Bring Your Own Cloud) environments, automating operations for application maintenance.
Read more in:
The Near Final End of 32-Bit Java
Aleksey Shipilev, a well-known expert in JVM performance and OpenJDK development, announced his resignation as the lead maintainer of the 32-bit x86 Java port. This decision stems from his belief that the costs of maintaining the port outweigh its benefits, especially as implementing new features like Loom and the Foreign Function & Memory (FFM) API becomes increasingly challenging. Shipilev emphasized that support for 32-bit platforms is now minimal, as most of the industry has transitioned to 64-bit systems.
Despite some advantages, such as compatibility with older platforms, the effort required to maintain the port is no longer justified. Shipilev suggested replacing it with the Zero interpreter, which, while slower, demands significantly fewer resources. This decision led to the deprecation of the 32-bit x86 port, with plans for its removal in a future release. The deprecation was formalized in JEP 501, which will be integrated into JDK 24.
Read more in:
Maven Central Introduces Bandwidth Limits
Maven Central, a key repository for the Java community, has announced the implementation of rate limits to prevent excessive resource consumption by a small group of users. Analyses revealed that 83% of total bandwidth is consumed by just 1% of IP addresses, primarily originating from some of the world's largest companies. This disparity highlights a phenomenon known as the "tragedy of the commons," where the overuse of shared resources by a few leads to their depletion, negatively impacting the entire community.
To ensure the long-term stability and availability of the repository, Maven Central has decided to restrict download speeds for the most resource-intensive users. Organizations are encouraged to use corporate repository managers, such as Sonatype's Nexus Repository, which can locally cache frequently used artifacts, reducing the load on Maven Central's infrastructure.
Read more in:
James Gosling Retires
James Gosling , known as the "Father of Java," announced his retirement in July 2024. Gosling created the Java programming language in 1995 while working at Sun Microsystems, where he spent 26 years. After leaving Sun Microsystems in 2010, he worked at Google and Liquid Robotics, and since 2017, he served as a Distinguished Engineer at Amazon Web Services (AWS), focusing on Internet of Things (IoT) projects.
Throughout his career, Gosling made a significant impact on technological development. His contribution to creating Java has shaped the modern programming landscape. His retirement marks the end of an era in the tech world, but the legacy he leaves behind will continue to thrive through the global developer community.
P.S.: James also had the opportunity to give a talk at the last JVM Language Summit. If you're curious about the "Father's" perspective on the evolution of his child, check out the video:
Read more in:
And now it is time to check some projects... still in development
Project Valhalla
In 2024, Project Valhalla was still making progress toward integrating value classes into the Java ecosystem. As a reminder, the goal is to blur the line between reference types and primitives, enabling the creation of types that "act like an int but behave like a class." The introduction of value classes aims to enable more efficient memory management through flat and dense data layouts, potentially boosting application performance significantly.
A notable development in Project Valhalla is the JEP draft: Null-Restricted and Nullable Types (Preview). This proposal introduces nullability markers to Java, allowing developers to specify whether reference types can accept null values. Two new markers have been introduced: Foo! for null-restricted types and Foo? for nullable types. By default, Java types remain undefined in terms of nullability, but this new syntax allows developers to explicitly declare their intent. Null-restricted types must always be initialized before their first use, which is enforced by the compiler. Nullable (Foo?) and null-restricted types (Foo!) can also be used in complex data structures such as arrays or generics, enhancing flexibility and code safety.
At JVMLS 2024, Brian Goetz also discussed proposals for introducing nullness markers and an extended construction protocol for fields with nullability constraints.
Read more in:
Project Leyden
Over the past year, Project Leyden also made some updates. JEP 483: Ahead-of-Time Class Loading & Linking introduced a method for shifting costly operations like class loading and linking to a preparatory phase known as "training runs." This allows the JVM to cache information about loaded classes, reducing application startup times. These innovations are fully compatible with existing applications and require no code modifications, making them an attractive alternative to solutions like GraalVM.
Project Leyden has also laid the groundwork for further advancements, including integration with various garbage collection mechanisms, such as ZGC, and simplifying the caching process. They also collaborated with the Quarkus teams to check the potential of combining Leyden’s technologies with existing frameworks, significantly speeding up application startup processes without sacrificing the JVM’s dynamic flexibility.
And of course, full update from JVMLS:
Read more in:
Project Babylon
Project Babylon has also captured the attention of the Java community, particularly following Paul Sandoz's publication Exploring Triton GPU Programming for Neural Networks in Java. The publication highlights advancements in using Code Reflection as a bridge between the Java ecosystem and GPU solutions, including the Triton programming model.
Triton was created by OpenAI, and is domain-specific programming model and compiler that enables Python developers to easily write GPU-accelerated code without requiring deep knowledge of low-level languages like CUDA. With tensor abstraction and automated synchronization, Triton simplifies the process of creating efficient GPU code. Project Babylon leverages Code Reflection to symbolically represent Java code, which is then automatically transformed into Triton code.
The process involves generating a code model in Java, analyzing it, and then transforming it into Triton-compatible code while maintaining precise type and structure alignment. The result is highly efficient GPU code that introduces Java developers to advanced parallel processing in a manner nearly as intuitive as in Python.
JDK team also continues the development of HATS (High-Performance Abstractions for Tensor Systems), a complementary framework that builds on the foundation of Babylon's GPU capabilities. HATS aims to provide an even higher level of abstraction for defining tensor operations and managing memory layouts, further simplifying the process of creating high-performance, GPU-accelerated applications in Java.
For more details, check out the presentation from the latest JVMLS:
Read more in:
New Project: Brisbane
Project Brisbane is an OpenJDK project aimed at creating a Java Cryptographic Extension (JCE) provider for environments regulated by FIPS 140. The project leverages the Foreign Function & Memory API to integrate with the FIPS 140-validated OpenSSL library, ensuring proper safeguards for its correct usage. Denis Gauthier, leader of the cryptographic team at Oracle Cloud and a member of the OpenSSL Release Steering Committee, serves as the project lead. Project Brisbane was approved in April 2024 and is supported by the Security and Core Libraries groups.
Read more in:
New (potential) Project: Skogsluft
The release of the Foreign Function and Memory API and the growing emphasis on pushing hardware to its limits (thanks to, of course, "AI") has led to a significant increase in the use of native code in Java.
This trend creates a need to prepare Java's entire tooling ecosystem for this shift. One response to this challenge is the new project proposal, Skogsluft, introduced by Jaroslav Bachorik from DataDog.
It aimed to enhance Java Flight Recorder (JFR) by introducing advanced features for profiling both native and Java code and focused on three key improvements: an integrated stack trace mechanism for native code, a flexible CPU sampling scheduler tailored to different operating systems, and extended support for thread labeling in JFR.
However, we are till to see official start of initiative, however it was never discarded as well.
Read more in:
And finally - the most interesting releases of the year.
Spring Framework 6.2 and Spring Boot 3.4
Spring Framework 6.2 and Spring Boot 3.4, released in November 2024, bring significant improvements to support developers in building modern Java applications.
Spring Framework 6.2 introduces support for escaping characters in property placeholders, new URL parser implementations, and enhanced support for data streams in WebMvc. Additionally, the framework now enables rendering view fragments, benefiting libraries such as HTMX. Other updates include task metadata, support for split cookies, and binding HTTP header data to controller method arguments.
Spring Boot 3.4 adds native support for structured logging, compatible with popular formats like Elastic Common Schema (ECS) and Logstash, simplifying application monitoring and analysis. New functionality for configuration property validation through annotations ensures greater consistency in application settings. Furthermore, integration with Testcontainers allows dynamic assignment of configuration properties in tests, streamlining testing of components dependent on external services.
Both versions also feature improvements in security and application monitoring flexibility, thanks to optimizations in Actuator endpoint access mechanisms.
Read more in:
Java Mission Control 9.0
JDK Mission Control 9.0, released in 2024, introduces significant enhancements for monitoring and profiling Java applications. The new version requires JDK 17 or newer to operate but still supports analyzing Java Flight Recorder (JFR) recordings from JDK 7 and later. Key updates include support for dark mode, improved JFR parser performance through reduced allocations, and a shift to Flame Graph visualization based on Java Swing, enhancing efficiency and performance.
Additionally, JMC 9 offers a configurable refresh interval for the JVM browser and new analysis rules, such as detecting GC Inverted Parallelism using the GC CPU time JFR event.
Read more in:
Alpaquita Support for CRaC
Alpaquita, the Java distribution by BellSoft, introduced in 2024 brings support for the CRaC (Coordinated Restore at Checkpoint) project. This functionality allows Java applications to resume instantly from previously created checkpoints, significantly reducing startup times. This is especially critical in cloud and serverless environments, where fast scaling and energy efficiency are top priorities.
Read more in:
Quarkus 3.15
Quarkus 3.15 is the latest LTS version, supported for the next 12 months. Users migrating from the previous LTS, Quarkus 3.8, can take advantage of new features introduced in recent releases, such as the renaming of Reactive modules (3.9), the standalone POJO mapper in Hibernate Search (3.10), Flyway 10 support (3.10), Dev Services for Observability (3.11), Kotlin 2.0 support (3.12), OpenTelemetry Metrics (3.13), Hibernate ORM 6.6 (3.14), and integration with Let’s Encrypt (3.14).
Read more in:
Oracle Code Assist
Oracle Code Assist stands out for its focus on Java and SQL languages and its deep integration with Oracle Cloud Infrastructure (OCI). Unlike the broad language support offered by tools like GitHub Copilot or Amazon CodeWhisperer, Oracle's tool prioritizes delivering precise code suggestions tailored to popular Java libraries, Oracle-specific development practices, and SQL specifications.
The tool is also designed to support the analysis of enterprise infrastructure telemetry, facilitating audit processes. With its specialization in enterprise technologies, such as older JDK versions, EJB, Struts, and Enterprise Service Bus, Oracle Code Assist has the potential to become an invaluable asset for teams working on large corporate systems.
Training Set Matters – It's likely that cool-kids copilots hasn't "fed" on enough legacy code. Oracle, with its deeper access to such codebases, likely has an edge in this area.
Read more in:
Java in 2024: Final touches before Kotlin 2.0 and Oracle's new tools – JVM Weekly vol. 82
Diagrams, Diagrams, Diagrams: Classloaders and More – JVM Weekly vol. 87
Official Java Client for OpenAI
In December 2024, OpenAI launched the "12 Days of OpenAI" initiative, where new features and products related to their AI technology were unveiled over 12 business days. On the ninth day, they announced new models — o1 and GPT-4o Realtime API —along with the introduction of the OpenAI Java SDK (in beta). This simple API client enables integration with OpenAI's services, serving as a foundational tool before delving into more advanced solutions.
Read more in:
Semantic Kernel for Java 1.0
In May 2024, Microsoft announced the general availability of Semantic Kernel for Java. This open-source library supports Java 8 and newer versions, offering tools for building intelligent applications that combine traditional programming approaches with the power of artificial intelligence. The GA release introduces API compatibility with other languages, such as .NET, making it easier for multilingual teams to collaborate. It also includes detailed documentation and code examples to support quick adoption of the technology.
Personally, I use it to postprocess every edition, and I like library a lot. Though it's amusing how quickly Microsoft seems to have forgotten about its creation and switched to Langchain4j.
Read more in:
Spring Model Context Protocol
Anthropic, the creators of Claude.ai, developed the Model Context Protocol (MCP) — an open standard that facilitates AI access to up-to-date, contextual data from various sources. MCP standardizes communication between AI models and external data sources, eliminating the need to create custom solutions for each integration.
The Spring community responded by creating an implementation of MCP for the Java ecosystem (mostly Spring).
Read more in:
MicroProfile 7.0
MicroProfile is a set of specifications developed by the Eclipse Foundation, designed for building microservices in Jakarta EE environments.
The main change in MicroProfile 7.0 is the replacement of MicroProfile Metrics with MicroProfile Telemetry 2.0, which provides metrics, logs, and tracing capabilities, offering a more comprehensive monitoring solution. MicroProfile 7.0 now declares a dependency on Jakarta EE 10 Core Profile, simplifying integration and eliminating the need to package it. Other updates include MicroProfile Config 3.1, MicroProfile Health 4.0, MicroProfile OpenAPI 4.0, and MicroProfile JWT Authentication 2.1.
Read more in:
Jetbrains Amper
Amper is an experimental tool for project configuration and application building, developed by JetBrains to enhance user experience and provide robust IDE support for languages like Kotlin, Java, and Swift. With a declarative configuration approach using YAML, Amper simplifies the process of creating and maintaining projects while offering seamless integration with popular JetBrains environments such as IntelliJ IDEA and Fleet.
The tool supports a variety of platforms, including JVM, Android, iOS, macOS, and Linux, facilitating the development of cross-platform applications and libraries. One of Amper's standout features is its interoperability with Gradle, allowing Amper and Gradle modules to coexist in a single project, ensuring a smooth migration path for existing Gradle-based projects. Additionally, Amper provides native support for Compose Multiplatform, accelerating the development of user interfaces across different platforms.
Read more in:
(A Bit of a Cheat but...) Chicory 1.0
Chicory is a JVM-native WebAssembly interpreter, written entirely in Java, enabling the execution of WebAssembly programs without requiring native dependencies or JNI. This allows Chicory to run anywhere the JVM is available, offering simplicity and security.
Version 1.0.0-M1, released in November 2024, introduces significant improvements, such as an updated public API, a new mechanism for defining host functions, and an enhanced WASI implementation. These changes aim to improve compliance with the WebAssembly specification and simplify integration with existing JVM-based projects.
Ktor 3.0
Finally, Ktor 3.0, released in October, introduces several important updates. One key enhancement is the migration to the kotlinx-io library, which standardizes IO functionality across Kotlin libraries. This version of Ktor also adds support for OpenTelemetry.
Another thing worth mentioning is integration gRPC, allowing developers to create and consume gRPC-based services in a Kotlin-idiomatic way, making RPC implementation as natural as HTTP or REST.
Ktor 3.0 is also now compatible with Kotlin 2.0.
Read more in:
Now, we can officially kick off 2025 🍾
And after 2024, I’ll leave you with one thought:
P.S. I’ve prepared a short survey with a few questions about both the format and content of this newsletter. Much appreciated, help me be better 🙏
PS2: Are you a staff engineer or aspiring to become a tech lead, team lead, or architect? JVM Weekly is a media partner of L8Conf - the conference for Staff+ Engineers in Warsaw🚀
Join us in Warsaw on 17-18 March 2025 for L8Conf, where we’ll explore Leadership in Engineering, Mentoring, Organizational Culture, and Strategy for Tech Teams. Gain actionable insights, valuable connections, and inspiration to lead with impact, whether you’re a leader or aspiring to grow your career. Follow L8 Conference for updates on the agenda and registration.
Our reader can use the code for 15% discount: JVM_WEEKLY
Additionally, if you join conference newsletter now, you will receive code for 30% discount.
