TL;DR
Quarkus 2.0.3, Docker Dev Environments, GraalVM 21.2, Spring Boot 2.4.9 & 2.5.3, and Scala 3.0.1.
README
This is issue 46 of 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”.
If you like my newsletter, then subscribe to it on Substack! Or read it on dev.to, the Java Cafe, or Medium. Even better: Share it with people who may be interested.
Quote of the Week
There are only two problems in life:
- You know what you want, and you don’t know how to get it.
- You don’t know what you want.” David Allen, author of the book “Getting Things Done”, describes most users of our applications.
Stand-Up
I spent most of last week with family in Germany, driving back to England only today. So this is another short issue, just like last week.
Another article of mine appeared on InfoQ. It’s about the Snyk “JVM Ecosystem Report 2021” that I wrote about in issue #41.
ADVERTISEMENT
FULL-STACK JAVA FOR 22 YEARS
I’m a full-stack Java developer with 22 years of experience, looking for a project in October 2021, 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!
CHECK OUT MY RESUME & WORK SAMPLES
Code Review
Issue 45 from July 19, 2021: “JavaFX - One Codebase for Web, PC, and Mobile?”
Last week I discussed the Java-based UI framework JavaFX. Because too few people use it, I recommended Google’s Flutter instead. Flutter uses Dart as the programming language, but that’s close to Java. As proof, I showed Dart code that nearly compiles in Java:
class MyClass extends AnotherClass {
String myString;
int myInt;
List<String> myList = new List<String>();
String sayHello(String name) {
var feedback = "Hello, " + name;
return feedback;
}
}
The part that doesn’t compile in Java is this line:
List<String> myList = new List<String>();
In Java, List is an interface, not a class, and we can’t instantiate it. But we could if we used a class instead:
List<String> myList = new ArrayList<String>();
Frameworks & Libraries
Quarkus 2.0: New Mission, Rocky Launch
Quarkus is a modern Java microservice framework. It now wants Java to dominate applications on Kubernetes. But its 2.0 launch came before the new version was fully ready.
Quarkus isn’t „supersonic subatomic Java“ anymore. Yep, that‘s how this Spring Boot competitor billed itself until last month. And no, that slogan never made full sense to me. Supersonic as in „loads very fast“? Ok, loading 270 times faster (0.016 seconds vs. 4.3 seconds) than a “traditional Cloud Native stack” (wink, Spring Boot, wink) does feel supersonic.
But „subatomic“? Quarkus claims a 12 MB Java application memory footprint, compared to the 136 MB of the “traditional Cloud Native stack”. That is smaller by an order of magnitude, but it‘s not „subatomic small“. The atom of memory (as in „the smallest piece“, and let’s leave electrons, protons, and neutrons out of the picture here) is a single bit. Quarkus needs 96 million of them! How’s that for “sub-bit”, ahem, “subatomic”?!
But I guess that as one of the underdogs in the fight against the duopoly of Spring Boot and Java/Jakarta EE you have to yell louder than the other guys. And one school of thought is that there‘s no bad news as long as they get your name right…
Now „Quarkus 2.0 continues the mission of making Java the preferred framework for Kubernetes-native development“, as the Quarkus page now boldly proclaims. Funny - I didn’t even know that Quarkus was on that mission! By all accounts, Kubernetes will be the default enterprise application deployment method. So Quarkus‘ real mission is „making Java the preferred back-end language for enterprises again“. Java was that language in the late 90s and early 2000s, as the downward-pointing Tiobe Index reminds us so painfully.
Now Java‘s up against some formidable opponents. First, we have JavaScript/TypeScript. Running in browsers everywhere and on the back-end through NodeJs, the pair now carries the „Write once, run anywhere“ mantle that Java once held. Then there‘s the dynamic duo of Google‘s Go, as in „the language that Kubernetes is written in“, and Firefox‘ Rust, the language that now can be used to write Android OS and the Linux kernel. Both languages try to win over C++ developers with the promise of „Looking familiar, but with fewer ways to shoot yourself in the foot“. In other words: It‘s a tall order for Quarkus.
And it looks like that mission was off to a rocky launch: The 2.0 release needed three bug-fix releases in as many weeks (see issues #45 and #44). So here we go again: Another maintenance release with mostly bug fixes.
Dear Quarkus team: Please let your next major release bake a little longer. It‘s hard to win over non-Quarkus/non-Java developers to Quarkus when they have to apply three bug-fix releases in three weeks just to keep your software running well. You know, „Move fast and break things“ doesn‘t sound so good when it applies to the foundational framework of our applications!
Tools
Docker Dev Environments: IDE Configuration With Git & Docker Compose
Docker Dev Environments want to solve the “madness” of developing applications with Git branches. To Java developers, this poorly explained beta feature of Docker Desktop looks like a solution in search of a problem instead.
Docker was supposed to fix the “But it works on my machine!” problem. And it does for me with my admittedly simple production set-up: Docker Compose with containers for Java, database, web proxy, and some additional tools. Then again, I’m the only one working on the code, so what do I know?!
Docker now says they failed to solve this problem when comparing our work with what our teammates are doing in other Git branches. Now Docker wouldn’t mention these problems if it also didn’t give us a solution. So they did with “Docker Dev Environment”. And then they explained this really badly. I dare you to read the blog post and tell me which IDEs you can use with Docker Dev Environments!
Go on. I’m waiting!
Ok, it’s VS Code. And I only know because I watched the video from the “DockerCon 21” conference that tried to explain it. Selling a new solution to developers and not telling them which IDEs you support is a bad start. And it didn’t really get better from there. Here’s my understanding of “Docker Dev Environments”:
“Docker Dev Environments” are here because working with Git branches is “Git madness” (their words, not mine): We also need to share the dependencies of our apps and their context. Sharing work on a Git branch as a “Docker Dev Environment” creates a Docker Compose file on Docker Hub. When other developers run this Docker Compose file, they get the Git branch content from that Docker Compose file which also launches the IDE and configures it.
So as Java developers, we scratch our heads when we read this.
- Our Maven/Gradle build files already define the dependencies of our Java applications. And JavaScript applications have their own build files. What do Docker Dev Environments add here?
- And the trouble with Git branches isn’t getting them - checking out a different Git branch is trivial. It’s comparing & merging a branch that’s hard. How does that get easier if we get the branch through Docker Compose?
- And what’s that “application context” that we get from Docker Dev Environments? Is it command-line parameters for applications, like memory limits or the location of config files? If so: Sometimes these are different for a reason - memory limits differ when our machine has only 16 GB of RAM and not 64 GB like our colleague’s. And config files with secrets aren’t supposed to be in Git and could be anywhere on our local disk.
So if you use VS Code and find this still to be an intriguing feature, then you need Docker Desktop 3.5 (release at the end of June) to try this.
Only time will tell whether this is a solution searching for a problem or whether Docker is really onto something here. To me, as a Java developer, it sounds like the former for now. After all, Docker sold their enterprise business nearly two years ago and now only makes money by addressing developer problems. So Docker’s incentivized to find developer problems it can solve, real or imagined.
Releases
GraalVM 21.2
GraalVM makes our Java programs small and fast to load - after an excruciatingly long native compilation process, that is. Oracle published another minor release of this tool.
And it likes to remind us that some of the optimizations are only available in the enterprise edition, not the free community edition most of us use. Many changes don’t affect Java, so the “minor release” designation is well-earned.
Spring Boot 2.4.9 & 2.5.3
As the Spring 5.3.9 announcement promised last week, the two Spring Boot releases building on that Spring release are here: 2.5.3 has „58 bug fixes, documentation improvements, and dependency upgrades“, while 2.4.9 has 35.
2.5.3 announcement, 2.4.9 announcement
Scala 3.0.1
Scala 3.0 saw the light of day in May this year (see issue #42). Its first maintenance release got out in early July. I couldn’t find an announcement, so I suppose that release is a drop-in replacement for 3.0, and we should use it.
About
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.
Karsten has this newsletter, a developer website, and a contractor site. He's on LinkedIn, Twitter, and GitHub. Karsten is also an author at InfoQ.
Oldest comments (0)