1. What’s interesting to learn in 2023 from the State of Developer Ecosystem and Jakarta EE Developer Survey.
We’ll begin with numbers and charts, as we’ve received two industry reports that focus on aspects of the ecosystem that are also relevant to this newsletter. These include the State of Developer Ecosystem 2023, which is released by JetBrains and contains a wealth of intriguing Kotlin/Java data, and the Jakarta EE Developers Survey 2023, which I hope is self-explanatory. This won’t be an exhaustive analysis, as the reports are publicly accessible to anyone interested. However, I will highlight the parts that grabbed my attention.
We’ll initially focus on the former, and prior to delving into the specifics of Java, Kotlin and Scala, let’s examine the current state of migration between languages as per a survey of 27,000 developers.
Programmers have certainly entrenched themselves in their positions and it’s difficult to observe any significant migration trends (except perhaps Rust and Go, these two languages appear to be drawing developers slightly more). Honestly, I anticipated much higher figures with Python. The language wars in general appear to be gradually becoming less and less captivating, at least when compared to the excitement of a few years ago. It’s challenging to search for any potentially great success stories for the upcoming years, similar to Rust or Go.
From the report’s intriguing findings, it’s important to note that “Scalians” are extremely loyal to their language…
… but when they see the upcoming graph, it’s easy to understand them 😉.
Languages seem to be decreasing in importance, according to the survey. It suggests that English, or other natural languages, are becoming the universal language for programmers. The survey indicates a general agreement on this matter:
Generally, the section on generative AI provides intriguing insights into the adoption of specific tools or models. While I won’t dissect the entire content due to constraints of space, I suggest you take a glance. Perhaps, you might discover some inspiration.
Now let’s move on to Java.
It appears that we currently have a two-speed Java, as per data collected by JetBrains. On one side, projects continue to use the outdated Java 8, even though it’s no longer supported by the ecosystem and there have been numerous announcements about its abandonment by key players. On the other side, JDK 17 is being widely adopted as well. In my view, this suggests that some companies will continue using JDK 8 indefinitely. However, if a company has already undergone the migration process, they are likely to stay on the fast track for upgrading to the next LTSes.
Here we have also interesting info – Docker’s first place doesn’t come as a surprise, but it is surprising that application servers still take the lead over standalone *.jar – although this may correlate a bit with Java 8 from the previous section. I’m saddened by the relatively low popularity of GraalVM, and am amused by the homeopathic use of jlink – as part of one of my conference presentations, like the last troll, I ask people about the linking phase in Java, and if even one person makes the association, I already know that a strong group has been hit.
I want to point out that I’ve used 2022 as a reference to highlight the incredible success of Spring. Despite the intense competition, it continues to maintain its momentum.
There are even more comparable intriguing statistics, pertaining to libraries, servers, and so on. However, the JetBrains team along with guest editors have already conducted their own examination on this. Therefore, I direct you to the original document.
It is now time for Kotlin.
There is not revolution. The server usage has returned to the 2021 percentage, and Multiplatform is on the rise. Nothing to see there…
… but here, if we look at this in comparison to the outcomes with Java, Gradle’s complete supremacy is just as striking as Spring’s dominance in the realm of Java frameworks.
I’m simply presenting this chart to highlight the observation that the question, “Which JetBrains Kotlin libraries and tools do you currently use?” is likely identical to “Which Kotlin libraries and tools do you currently use?“. JetBrains clearly dominates in response to this question.
The full report can be found here.
Now a little more about Scala.
The data presented might seem simple to interpret as “Scala 3.0 is lagging behind”, however, they don’t necessarily indicate a pattern. To put things into perspective, consider the statistics from the previous year.
Scala 3.0 is certainly expanding, and doing so with grace. The expansion of Scala 2.13 is equally perplexing – and intriguingly even when compared to 2021. It might be that there are just two routes of cannibalisation of Scala 2.12 and 2.11 – with some projects opting to transition to the most recent version of the 2.x branch.
When discussing Akka, it’s astonishing to see the stability in the statistics, even amidst the uproar surrounding the new licensing model. However, it’s likely challenging to eliminate the foundation of the current systems, which is why projects initially invested in Scale.
You can find the full report here once again.
And also some additional insights from the Jakarta EE Developer Survey 2023 – although the report is somewhat less detailed, since it only cover a single technology, and we also have the ‘Executive Summary’ at our disposal.
While Jakarta EE 10’s popularity is understandable, considering the entire Java ecosystem’s shift towards it, what surprised me the most was the significant rise in… Jakarta EE 8. On further thought, however, this makes sense – these are likely migrations from Java EE 8. From an upgrade perspective, this is a natural initial move.
The community’s priorities are intriguing – it’s evident that the demand for containerisation remains high, which will inherently encourage solutions associated with reducing start-up time. I believe this aligns well with the second point, which is microservices (though from my viewpoint, the implementation of Core Profile is already quite considerable) and the fourth point – serverless. Additionally, I’m eagerly anticipating the resolution of Virtual Threads standardisation and curious to see how specification will include them.
I have to confess that I perceived the report to be somewhat lacking. For instance, we have depicted some trends:
Personally, I’m interested in the complete distribution of not only Long-Term Support Java Development Kits, but also versions older than JDK 9 or the use of specific application servers. Regrettably, the comprehensive data is only accessible to the members of the Jakarta Enterprise Edition Working Group. However, I’m diligently working on this “issue” and hopefully, I’ll have some updates for you soon.
You will get the report by providing your e-mail and a soul here.
2. The stewards of Spring have been acquired by Broadcom
This is an announcement at the intersection of business and the world of technology. It’s no surprise that large open-source projects typically have corporate sponsors nowadays, with many developers working on them as part of their corporate roles. A week ago, we discussed the surge of new releases and significant launches in the Spring ecosystem, indicating that the project is in its best state in years. However, it’s disheartening to learn about the turmoil occurring behind the scenes. To clarify this situation, I must introduce some corporate structure, at the very least.
Pivotal Software, the company behind Spring, and VMware share a robust historical and business connection. Pivotal, known for its specialization in cloud platform and software tools development, was initially established as an independent entity by EMC Corporation. EMC Corporation also owned a majority stake in VMware, a leading name in the virtualization and cloud infrastructure industry. In 2012, a joint investment in Pivotal was made by VMware and EMC, and by 2013, Pivotal was officially launched as a separate company. In 2019, VMware’s acquisition of Pivotal not only solidified their relationship but also fortified VMware’s standing in the application development and cloud services sector, leveraging Pivotal’s expertise in this field – including their Cloud Foundry solutions.
The story doesn’t stop here. Broadcom, a company primarily known for its semiconductor manufacturing, chose to venture into the software market. This move was part of a broader strategy to diversify the company. They selected VMware, a company renowned as a leader in virtualisation and cloud infrastructure, which was an appealing path for Broadcom. The acquisition, which started in May 2022 and was one of the biggest deals of its kind at $69 billion, was finally concluded last week, on 22 November.
Transitioning to the now – shortly after the transaction, the company executed a series of layoffs. The full extent of these layoffs is unknown, but it’s clear that they impacted the team in charge of the most popular Java framework. Oliver Drotbohm, a Spring architect who has been at the helm of the Spring Data project for over ten years, provided a succinct summary of the situation.
As there have been no formal announcements, I won’t entertain speculation in this space… yet. My only wish is for those of you who have been affected to take a break and swiftly discover a new place that is just as good, if not better.
3. Release Radar
Micronaut 4.20
In the most recent release of Micronaut Framework 4.2.0, several notable modifications have been made to Kotlin and Gradle. To begin with, the integration with Kotlin Symbol Processing (KSP) has been enhanced. Support has also been added for Kotlin 1.9.20 and KSP 1.9.20-1.0.13, as well as Ktor 2.3.5. In addition, new applications now default to using Gradle with Kotlin DSL, which offers improved integration with the IDE. Micronaut Data has introduced coroutine versions of connection and transaction operations, specifically CoroutineConnectionOperation and CoroutineTransactionOperatio..
The latest version of Micronaut Data now includes procedure calls in repositories and association support in DTOs. Other enhancements include support for GraalVM with the --strict-image-heap flag, which is set to become the default in the upcoming version of GraalVM Native Image. Users now have the option to select Java 21 in Micronaut Launch or CLI. In addition to these, updates have been made to several other modules such as Micronaut Test, Micronaut Tracing, Micronaut Micrometer, Micronaut OpenAPI, and support has been extended to various technologies including GCP, Kafka, RabbitMQ, Redis, among others.
Vert.x 4.5
Do you recall Vert.x? This multilingual toolkit, designed for building reactive applications on a JVM server, has seen a decrease in popularity due to the waning enthusiasm for reactive programming. It’s clear that it needs some reinvention, a fact made even more evident by its latest release.
Vert.x 4.5 brings an unexpected feature with the incorporation of virtual threads from Java 21. This is a notable development as Vert.x is recognized for its asynchronous (and reactive) query processing within sequences of successive actions. The introduction of virtual threads enables code to be written in a way that seems synchronous. This makes managing complex workflows simpler, while maintaining the asynchronous foundation. However, in my perspective, this encapsulation of queries in Future.await completely changes my approach to writing in Vert.x, particularly since I have extensive professional experience with this solution.
Verticle verticle = new AbstractVerticle() {
@Override
public void start() {
HttpClient client = vertx.createHttpClient();
HttpClientRequest req = Future.await(client.request(
HttpMethod.GET,
8080,
"localhost",
"/"));
HttpClientResponse resp = Future.await(req.send());
int status = resp.statusCode();
Buffer body = Future.await(resp.body());
}
};
However, it might just be my perspective, and for someone embarking on a project, it would seem quite normal.
This version introduces dynamic SQL connection creation, allowing for flexible connections to various databases. It also provides support for transactional connection pooling modes for network level 7 proxies like PgBouncer.
The capability to update the SSL TCP configuration in real time is a new feature, beneficial for certificate rotation. Vert.x 4.5 also presents a distinct WebSocket client, enabling improved separation between HTTP and WebSocket interactions. Lastly, a builder is now available for the creation of Vert.x clients, simplifying their configuration process.
EclipseStore 1.0
Here we have a truly interesting release. However, before we delve into Eclipse Stora, it’s crucial that we first discuss MicroStream.
MicroStrea is designed with microservices and serverless architecture in mind, creating a ‘databaseless’ persistence layer (cause since we have `serverless` term, we might as well coin that term too). This enable a graph of Java objects to be stored in memory, irrespective of their size or complexity, while maintaining complete transaction consistency. Data is automatically loaded and retrieved from memory, and the Lazy-Loading mechanism optimizes its consumption.
Not long ago, the Eclipse Foundation officially adopted a project named EclipseStore 1.0, which is built on the MicroStream 8 code. As a result, MicroStream development has come to a halt, with all future features being released exclusively under the EclipseStore project. Despite this, the MicroStream team remains committed to the project, working diligently to develop new features and showcase them at the forthcoming EclipseStore Summit 2023 – they are certainly gaining momentum.
Interestingly, we are not confronting the usual ‘death by open sourcing’. EclipseStore continues to be a crucial project for MicroStream, serving as the foundation for their commercial products like MicroStream Cluster and MicroStream Enterprise.
Hibernate 6.4
The latest version of Hibernate ORM 6.4.0 brings several significant updates. Among these is the introduction of ‘soft deletion’ through the new @SoftDelete annotation. This feature allows values to be flagged as deleted (like in a deleted boolean type column, if you understand what I mean). A new hibernate-vector module is also included, providing support for vector types and mathematical functions. These are particularly useful in the AI/ML field for vector similarity searches. Currently, it only supports PostgreSQL with the pgvector extension enabled.
Additionally, Hibernate ORM 6.4.0 introduces new features for managing arrays in HQL and Criteria queries. The support for Java Flight Recorder (JFR) events has been updated as well – due to variations in JFR implementation, a distinct hibernate-jfr module has been established to guarantee compatibility between the two. Another notable new feature is the support for using tenant-id with types other than String, a sought-after feature for applications with MultiTenancy support. The utilization of tenant-id enables efficient access management and data segregation, ensuring that the data of one client is not accessible to another.
PS: Version 2.2 of Hibernate Reactive has also been released, but it primarily serves as a wrapper over Hibernate ORM 6.4.0.
AWS SDK for Kotlin
The yearly conference of Amazon Web Services, re:Invent, is happening now in Las Vegas. Last year, we were informed about AWS Lambda SnapStart, which integrated CRaC with AWS Lambda. This year, there have been less JVM-oriented announcements. However, I found an interesting one – the AWS SDK for Kotlin is now available!
The API of the library has been crafted in the idiomatic Kotlin language, creating useful DSLs and facilitating asynchronous AWS service calls through coroutines. The present version enables developers to operate on JVM or Android API Level 24+ platforms. There are plans to extend support to more platforms like Kotlin/Native in upcoming releases.
Micrometer 1.12
Micrometer is gradually establishing itself as the standard for monitoring Java applications. Notable enhancements in version 1.12 encompass support for Jetty 12 in JettyConnectionMetrics, support for recently announced generational ZGC, the elimination of native-image.properties from micrometer-core, and the introduction of observation instrumentation for Jakarta JMS. Assigning dynamic tags to metrics has also been simplified..
Several bugs have been addressed, including but not limited to, those found in the metadata serialization of Dynatrace v2, the counting of asynchronous log4j2 events, and dependencies on Guava in the Stackdriver module. You can find more details here. Furthermore, numerous dependencies have been updated in this version, such as archunit-junit5, mockito-core, junit, and mongodb-driver-sync.
The leftovers of the Spring release – new versions of Modulith and Vault.
Finally, there are two related issues to Spring that were not included in the previous edition.
The most recent release of Spring Vault 3.1 brings an upgrade to Spring Framework 6.1, introduces JWT authentication support with JwtAuthentication, and a fresh interface AuthenticationEventMulticaster. This allows for the renewal of Leases when a login token has expired. Additionally, there is enhanced support for reactivity.
Spring Modulith 1.1 now notably supports event externalisation to AMQP, Kafka, JMS, AWS SNS and SQS, and includes an API for managing completed and uncompleted event publications. The relationship constraints for code in the application root have been enhanced, meaning that Spring Modulith now checks and enforces rules about how modules can communicate and interact, reducing the chance of creating unwanted dependencies between them. Additionally, support for actuators in native images and the Neo4j Event Publication Repository implementation have been introduced. On a personal note, I find the Kotlin and Gradle variants of the Kotlin DSL extremely useful for both code examples and configuration.
Bonus – Advent of Code 2023 with Kotlin! 🎄
There’s more – who has PTSD seeing this picture?
As the holiday season draws near, the Advent of Code is set to kick off. This yearly coding contest sees brave participants vying to complete progressively complex programming challenges… the latter weeks are truly tough. Trust me, I’m participating for the fourth year in a row.
Just like the previous year, JetBrains has once again invited the community to solve more tasks in Kotlin, offering their own leaderboards and promising rewards to anyone who completes at least three tasks without using LLM. They have also prepared a ready-to-use repository for anyone who wants a basic structure for solving tasks. If you encounter any difficulties, they will also be broadcasting live streams of task solving in idiomatic Kotlin. You can find more details on their blog.
However, if you’re interested in joining a local LeaderBoard, I encourage you to participate in one where I’ve competed myself. However, I suspect that my commitments, including writing this newsletter and other responsibilities (one of which is 2.5 years old), will likely mean that I won’t be a tough competitor 🥴
You can use this code 3230435-45a28415 (and input it here), and our active support group you will find here.
Although I’ve learned in recent years that during the Advent of Code, it’s more crucial to be methodical and tenacious, rather than just churning out code mechanically. Just leave the latter to GPT-4 – there is no fun in that.
PS: I am certainly not going to overthink this year and I will be using Kotlin. Enjoy waking up at 6:00!
