What does the “State of Developer Ecosystem 2022” tell us about Java and the JVM ? – JVM Weekly vol. 123

1. Oracle turns Oracle JDK pricing upside down

Java very rarely goes viral in the development community. While we may be interested in new versions of the JDK, changes to the VM, and other news from the ecosystem, someone “uninvested” in it mainly hear about Java when there is internet drama… and one just happened last week. And all because Oracle decided to change the way it charges for its JDK.

Let’s start with the facts: On January 23, Oracle announced that it is changing the Oracle JDK licensing model to Java SE Universal Subscription. Instead of being based on workstations and processors, the new pricing will be calculated on the number of employees a company employs: for those up to 1,000 employees, fees will be $15 employee/month, and for larger ones, it will be $5.25 employee/month. For many (most?) companies using Oracle JDK, this will mean a massive increase in costs, since the calculation takes into account not only programmers but all employees of the company – including those outside the IT department, as well as contractors.

I’ve been trying to estimate what the use of individual JDKs looks like today, and I managed to dig into the State of the Java Ecosystem report published by New Relic. It shows that the popularity of Oracle JDKs has been declining strongly penultimate years (75% in 2020 to 35% in 2022), so if the trend continues, by early 2023 we’ll be talking about even lower numbers. I suspect, moreover, that recent pricing changes will only accelerate this drain.

Unfortunately, I have a feeling that we are in a self-reinforcing spiral here – so let’s play devil’s advocate first. Since the number of companies using Oracle solutions is falling, and the cost of Java development remains constant, the obvious (albeit painful) solution turns out to be to raise prices to make the whole business viable. It should also be remembered that it’s not as if the Oracle JDK has been free until now. After all, the licensing model assumed a fee for each processor and each workstation on which the JDK was installed. The existing model, which was considered more favorable and which we will miss, was quite similar to the heavily criticized Akka license change last year, also introducing per-processor fees.

The changes will also not affect already paying customers, who will be able to settle on old terms (although I have not been able to dig into how the license extension, for example, will be resolved). Ending on a positive note, the provisions could benefit some companies, especially tech startups with few employees. Enterprises lose probably in any configuration, but small scaleups may gain (if these even use Oracle JDK).

However, this part:

Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual number of employees that use the Programs

is scary. Oracle JDK is often used by companies whose core is not technology, so it simply drives existing business. However, new Java license considers ALL employees, not just those directly involved in the technology. Unless Oracle introduces some discounts, these types of companies can be surprised. Nathan Biggs of House of Bricks has done the first calculations and his synthetic (but not unrealistic) examples show a huge increase in costs.

Note that Oracle is not the only JDK vendor, so anyone wanting to use Java for free can use Adoptium, for example. In the worst situation are companies that still haven’t migrated to the latest JDK editions, so they have to pay extra for support of such JDK 1.8. However, if a company has a reasonably up-to-date technology stack, but needs a paid support option, there are a bunch of alternative vendors.

What’s sad is that people familiar with the Java ecosystem know this, but for the general public, it is a highly unintuitive state. After all, there are no alternative distributions of Go or Rust (or they are statistically negligible). That’s why I have concerns that the whole thing will very much affect Java’s reputation as a language.

And to conclude with something shareable – if you are currently just facing a decision on what steps to take after the aforementioned pricing change, the best study of available alternatives can be found at whichjdk.com

Sources

• Oracle Java SE Universal Subscription FAQ
• House of Bricks dokonał pierwszych wyliczeń
• 2022 State of the Java Ecosystem Report
• Oracle changing Java licensing from per-processor to a multiplier of employee headcount – costs could go up singificantly
• whichjdk.com

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. AtomicJar receivers 25 millions USD in funding and opens TestContainers Cloud

While in the case of JavaScript infrastructure projects it’s quite common (or at least 2021 and 2022 have spoiled us on this topic quite a bit) to see announcements of new rounds of external funding (Vercel, Deno), it’s relatively rare to hear of any Java library setting up its own cloud (unless we’re considering the likes of Confluence and Kafka here). So it was with a big smile that I greeted last week’s announcement from AtomicJar, in which the company boasted a funding round of $25 million.

To introduce what the funds are supposed to go to, it’s worth remembering what AtomicJar does. Are you familiar with TestContainers? It’s a support library for JUnit, providing lightweight, disposable instances of popular databases, web browsers for Selenium, and generally anything that can be easily run in a Docker container. While many people will probably grumble about running containers in unit tests, the popularity of TestContainers proves how common this use case is.

The money from the investor is to go towards further development of the company’s own Software-as-a-Service solution – TestContainers Cloud. It allows the containers in question to run not on a local machine, but in the cloud. The creators claim that such a solution frees developers’ machines from resource-intensive processes, as well as being agnostic to the architecture (the whole project was reportedly inspired by Docker’s initial lack of support for ARM). And while the latter argument seems a bit of a stretch, the former appeals to me. Firing up a heavier suite of tests on a computer with 16GB of RAM (and in some cases 32GB) these days is a mandatory coffee break…

The funding announcement is also accompanied by the launch of the open Beta version of the TestContainers Cloud service. We can’t help but congratulate AtomicJar and keeping fingers crossed for their success. I really wish products like theirs weren’t needed, but unfortunately, they very much are.

Sources

• AtomicJar Secures $25 Million in Series A Funding and Launches Public Beta of Testcontainers Cloud
• A letter to the Testcontainers community
• testcontainers.cloud

Discover more IT content selected for you

In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

3. What does the “State of Developer Ecosystem 2022” tell us about Java and JVM ?

And since we already proved to ourselves in the first section that statistics are useful, at the very end I have a interesting report for you.

JetBrains has had its publication cycle pushed back a lot lately. First, we had to wait a very long time for the company to finally officially acknowledge Kotlin 1.8 released at the end of the year, and now in January 2023, we got their State Of The Developer Ecosystem 2022. Seemingly, there’s nothing surprising about this – after all  (as we’ve already compared to JavaScript on the occasion of AtomicJar) the big reports from this ecosystem also didn’t appear until January this year, but the State of Developer Ecosystem was published every year in the fall. I’ll admit that I’ve been waiting for this report – for as much as it touches on a broader group of languages than just the JVM ones, it provides a very good source of statistics that I’ll be able to steward for the rest of the year.

So let’s take a look inside what’s also interesting about the JVM languages, or at least the three included – as Java, Kotlin, and Scala have found their place in the report. I have selected for you the tidbits that, from my perspective, were the most interesting.

Let’s start with the usage statistics of specific JDK versions. Although it no longer had much support at the time of publication, JDK 8 is still king when it comes to adoptions. However, it is important to note the slow shift away from this release – as it scored a decline from 72% to 60%, a drop of 12 percentage points. This does not change the fact that it is the old-school “eight” that remains the most popular JDK, and is chased by JDK 11 (48%) and JDK 17 (30%). The use of non-LTS versions is (probably according to the plan) rather homeopathic. I remind you that the data is collected for the first half of 2022, so the situation could still change a bit

Spring Boot and Spring MVC also indivisibly rule, any competitor rate could not hit 5% usage. The inclusion of JSF in the statistic is an odd choice – a bit like comparing apples to oranges IMHO. It will be interesting to see if, given Spring’s total dominance, its abandonment of JDKs older than JDK 17 will affect State Of The Developer Ecosystem 2023.

The chart above shows why I like these kinds of statistics. Based only on the presence in the discussion, it would seem that Gradle has already taken over the ecosystem of tools for building Java projects. However, it turns out that while Gradle has indeed broken through the 50% adoption mark, it’s still a long way short of the older and quieter Maven.

As for Kotlin, perhaps the most interesting statistic is the use of language across environments. This is because, percentage-wise, mobile adoption (both Android and MultiPlatform) is growing relative to the server-based one, which is the only one that has scored declines in percentage points. I wondered if this was the result of a larger user base, but the amount of Kotlin Developers more or less matches that of last year (based on data on the number of users as well as the percentage of them using Kotlin, according to my rough calculations, about ~4500 Kotliners participated in both 2021 and 2022). I wonder how much of this is a one-off or a more regular trend.

Finally, let’s take a look at Scala. In the case of this language usage, it is clear that we are dealing with rather already established use cases, albeit not as dominant as Spring in the case of Java. Based on the report, if someone has Scala in a project, you can assume with high probability that he uses it for Akka or Spark, and additionally has some library supporting functional programming in the project. At least that’s how I read the above data.

And finally, let’s take a look at the adoption of the different versions of Scala. Here I have good news for the language – version 3.0 is definitely growing, all other releases are declining. However, it is clear that all versions from 2.11 upwards still have a sizable adoption, the process will still rather take some time.

There is much more interesting data, you can find the full report at The State of Developer Ecosystem 2022.

Sources

• The State of Developer Ecosystem 2022
• The State of Developer Ecosystem 2022 – Java
• The State of Developer Ecosystem 2022 – Kotlin
• The State of Developer Ecosystem 2022 – Scala