How to Build Java Applications Today: #53
Follow-up on Docker Desktop & Spring One predictions, Kotlin to mostly ignore back-end usage now, more on Spring 6 & Spring Boot 3, Quarkus 2.2.2.
Welcome to my weekly newsletter “How To Build Java Applications Today”! I read all the Java newsletters so you don’t have to. And it’s “Java news with a smile”.
Quote of the Week
To achieve great things, two things are needed: a plan, and not quite enough time.
I’m looking forward to speaking at JAX London in early October. I was looking forward to an on-site conference, meeting people face-to-face instead of over Zoom. Keyword being “was”: Last week, the conference changed from “hybrid” to “online”. Bummer!
Talking about seeing: I see palm trees! They don’t grow in Milton Keynes in England, where I live. So I'm either hallucinating, or I'm on vacation. It's the latter: Sea, sun, palm trees, excellent breakfast - I’ll probably put on 20 pounds over here in Tenerife!
22 YEARS OF FULL-STACK JAVA FOR HIRE NEXT FEBRUARY
I’m a full-stack Java developer with 22 years of experience: Spring Boot, Angular, Flutter. I’m looking for a project in February 2022, in Milton Keynes, London, or remote. I’ll work as a contractor or fixed-term employee but don’t take permanent positions.
Interested? Then check out my resume & work samples!
Issue 52 from Sep 6, 2021
Last week I wrote about how more enterprises will have to pay for Docker Desktop. I didn’t mention why do we Java developers care. So why do we?
We care because „Docker Hub + Docker Desktop“ is the App Store for us developers, giving us all the software we need. And it gets our development configuration closer to the production configuration, saving us time when recreating production issues.
Want a database? Docker Hub has it. A cache? It’s there. A proxy server? A logging stack? Analytics software? There, there, and there, easy to install, easy to upgrade. And we can run as many different versions of a given software as we want, bypassing the troubles local installations can give us.
And Docker gives us the same software we run in production. So no more character set or sorting differences between, say, MySQL on Windows and MySQL on Linux.
So if Docker gets more expensive, life will be harder for those developers whose enterprise doesn‘t want to pay. That’s why we Java developers care about Docker Desktop.
Issue 51 from Aug 30, 2021
I completely forgot: Two weeks ago, I made these predictions for Spring One: „I expect its GraalVM support to be the highlight, with Java 11 as the new baseline. […] So when’s Spring Boot 3 going to appear? Next spring is my best bet.“ How did I fare?
I got just 1 out of 3: GraalVM was one of the two highlights, receiving its own session on day 2. But the baseline for Spring 6 is Java 17, as I wrote about last week, not Java 11. And Spring Boot will appear somewhere after October 2022, not in the spring. 😩
Kotlin to Mostly Ignore Back-End Usage Now
Kotlin is the “modern Java”: A statically typed JVM language that has niceties that Java doesn’t - null safety for fewer NPEs, coroutines for better concurrency, and more. Kotlin can make us Java developers more productive!
The downside of introducing Kotlin is a whole new language to absorb: Training, new tools, new conventions, etc. We need to convince our boss and our colleagues that the pain of switching is worth it. Is Kotlin going to make that convincing easier for us Java developers?
No - not according to an interview with Roman Elizarov, Kotlin project lead at JetBrains. That’s a shame because it means we Java developers are less likely to get Kotlin’s productivity boost!
So the most investment will not go to Kotlin on the back-end but to Kotlin as a multiplatform, front-end language. Well, maybe Kotlin’s in such a great shape on the back-end that it doesn’t need much boost?
Roman certainly thinks so: He says, “the future of Kotlin on the server-side is bright and clear”. He cites the Snyk JVM Ecosystem Report 2021 (see issue #41), saying that “18% of JVM developers already use Kotlin”. Roman also expects “this number to grow steadily”. That’s splendid, isn’t it?
Not necessarily. The 18% number is cherry-picking: The JRebel "2021 Java Developer Productivity Report" (see issue #27) put the number of Kotlin developers at half that value - just 9%. And counting as a Kotlin developer is easier than ever: Technically, you’re one if you just configure Gradle with Kotlin.
And why should the number of Kotlin developers “grow steadily” in the future? The biggest competition for Kotlin on the server is not, as the interview suggests, Rust or Swift - it’s plain old Java! And Java does get better, though slowly:
var for local variables in Java 10, the new
switch expressions with Java 14, and records with Java 16 (the equivalence of data classes in Kotlin). And though it may not kill reactive programming (see issue #49), Project Loom could kill the need for Kotlin coroutines.
Here's another way of looking at Kotlin: After ten years of a big productivity advantage, Kotlin only grabbed 9–18% of JVM developers. Why should that number grow much over the next ten years with a shrinking productivity advantage?
Frameworks & Libraries
More On Spring 6 & Spring Boot 3
Last week I wrote about what’s in store for Spring 6 and Spring Boot 3. A day later, VMware made the session videos available to registered users. So here are more details.
Spring 6 is so much work that for the first time since 2010, we will not get a major release of Spring this year. We do get a minor release soon that supports Java 17.
The upcoming 0.11 release will make Spring Native more competitive with GraalVM: Project lead Sébastien Deleuze commented on Slack that a “Spring Boot + MVC + Tomcat application consumes less than 40M after startup on Mac”. That’s much closer to the 15 MB that a similar Quarkus app takes up than the 126 MB Spring Native mustered way back in May.
Spring Native will disappear as a separate project with Spring Boot 3, which will offer a native starter configuration and native build packs. But even with Spring Boot 3, some of the Spring Initializr libraries won’t work in native mode: VMware currently focuses on architectural changes for native compilation before going back to getting dependencies ready.
We also got more answers on why Spring Observability is needed as a new project in Spring 6: Unlike traditional, agent-based observability, Spring Observability also works when natively compiled. And as part of the Spring core, it will also provide better information more effectively.
Pruning, the removal of cruft from Spring 6, is a potentially scary proposition: Will they remove something we use today? Unfortunately, VMware just gave a handful of examples. Beyond the autowiring setters by name/type and EJB I mentioned last week, there’s just “some FactoryBean arrangements”, “certain web-related options”, and JAX-WS. It seems VMware isn’t too sure itself. That’s why they’re asking for community feedback. I suppose we can always file a Github issue of “Don’t take away X in Spring 6”.
After fixing the showstopper bug that prevented the release of “Let’s focus on bug fixes with 2.2.0” (see last week’s issue), we now got a proper maintenance release: “bugfixes and documentation improvements”. And yes, I’d put a space between “bug” and “fixes”, too.
If you’re getting sick of reading about Quarkus upgrades: I can’t help if they’re the only ones who are releasing that quickly!
Karsten Silz is the author of this newsletter. He is a full-stack web & mobile developer with 22 years of Java experience, author, speaker, and marathon runner. Karsten got a Master’s degree in Computer Science at the Dresden University of Technology (Germany) in 1996.
Karsten has worked in Europe and the US. He co-founded a software start-up in the US in 2004. Karsten led product development for 13 years and left after the company was sold successfully. He co-founded the UK SaaS start-up “Your Home in Good Hands” as CTO in 2020. Since 2019, Karsten also works as a contractor in the UK.