TL;DR
Oracle's Ron Pressler thinks most Java developers or their bosses don't care about money, Spring 6 supports Java modules, Adoptium OpenJDK Java 17, Micronaut 3.0, and Spring Boot 2.5.5 & 2.4.11.
README
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”.
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
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
The "human" that Martin Fowler, a luminary of our craft, is talking about here could be "me in six months". Or, with progressing age, "me next week".
Stand-Up
My InfoQ article about Spring 6 & Spring Boot 3 came out last Friday. In it, VMware confirmed something that I first reported here back in May: Spring 6 supports Java modules! Read below for more.
On Wednesday, I gave a talk at the Java Forum Stuttgart. Inevitably, it was "How Should Java Developers Build Front-Ends for Web, Mobile & Desktop Today?". I've given this talk now at four conferences and three JUGs, but I still find ways to make it better. The talk was pre-recorded, so I just showed up to answer questions for about 20 minutes. Nice!
ADVERTISEMENT
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!
Check out my resume & work samples
Bookmarks
Java
Oracle's Ron Pressler Thinks Most Java Developers or Their Bosses Don't Care About Money
Oracle's Ron Pressler says people on Java 8 lose money every day. I mostly disagree and state my reasons. What do you think?
Ron Pressler is the technical lead of Project Loom at Oracle, which reinvents threads in Java (see issue #49). In an InfoQ panel discussion on the future of Java, he said this:
The numbers I have say about 60% and dropping on 8. I expect that by the end of the year, the majority will be on 9 plus. Unless you're a company that doesn't care about money, you can stay on 8. If you do care, I suggest you move because you're losing money every day on 8. You're just wasting on hardware and support. The cost that you'll save by upgrading will almost surely dwarf the cost of the transition itself very quickly.
If I understand Ron correctly, he's saying: Java 8 uses hardware less efficiently than Java 9 or later. That's why spending developer time on moving to Java 9 or later quickly pays for itself. Most of the millions of Java developers still use Java 8, so these developers or their bosses don't care about money.
I mostly disagree. But why do I care? And why should you?
If Oracle doesn’t know why we upgrade to new Java versions, they probably won’t do the right things to make Java more attractive. And if Java doesn't get more attractive, then our life as Java developers gets harder: Java's fight isn't between Java 8 and Java 17. It's between Java and other languages, like JavaScript or Python. Look at the TIOBE index for Java or questions on Stack Overflow - Java's line has been going down for years...
So let me address Ron's arguments.
First of all, most of us write Java software to create business value for our customers (giving our users features they ask for, creating more revenue, making our stakeholders happy, that kind of thing), not to save costs. So if the business value we can get in X developer days is greater than the costs we can save in that time, then we'll probably add business value instead of, say, migrating to a new Java version.
Secondly, we need to spend developer time here to save on hardware costs. From where I sit, developer time gets more expensive over time, while hardware cost goes down. So arguably, moving away from Java 8 gets more expensive and saves less money over time.
And yeah, I know the COVID pandemic made hiring cheaper, remote developers more feasible. But it also drove up demand for developers. Correct me if I'm wrong, but from what I'm seeing, developers haven't gotten much cheaper overall, if at all.
Thirdly, let's check the evidence that Ron presented for his assumption "The cost that you'll save by upgrading will almost surely dwarf the cost of the transition itself very quickly".
(searching…)
Oh wait, there is none: Ron presented no evidence for how much the Java upgrade will cost or how much it will save. A Return on Investment (ROI) calculator? Multiple case studies? A single case study? Anecdotal evidence? Anything? Nope.
Yes, I know it's a bit unfair to expect this level of detail in a panel discussion. But he brought it up. Ron represents Oracle, the owner of Java, so I hold him to a higher standard. And Ron made sweeping statements without evidence in the past, such as “not many people like” reactive programming.
And last but not least: Maybe, just maybe, millions of Java developers looked at Java 9 and later and said, "Nope, this isn't worth the trouble". I mean, it's been four years since Java 9, so there was plenty of time to investigate. This view may be right, it may be wrong, but Oracle isn't helping to educate us Java developers!
Just look at the endless "What's new" section in the Java 17 release notes. Why can't Oracle give us a summary of the most important features, as everybody else did? The Oracle Java website has that summary. But we Java developers don't look for a press release on Oracle's Java page. We look in the Java documentation.
And why can't Oracle give us a summary of what's changed from Java 8 through Java 17? This blogger can.
Now our bosses don't read release notes. If Oracle wants us to upgrade to Java 17, why don't they give us something that convinces our bosses? You know, like a ROI calculator or case studies? I think the Java leadership at Oracle should be able to rattle off the ROI for migrating to Java 17 when woken up at 3 am! If they can't make a good case for Java 17, then who can?!
And why aren't the release notes actionable? Let's take the var keyword that we got in Java 10: var string = "This is new";. For starters, that's not mentioned in the "What's new" section of Java 10. It's only in the "Language Updates" section. Really?
But the critical point is that most of us maintain existing Java systems. So if we think var is a good feature, we need to apply it to our existing code base - without changing every single variable declaration by hand. Now how do we do that?
Oracle doesn't tell us.
Look, there are only three, maybe four Java IDEs in wide use today - IntelliJ, Eclipse, Visual Studio Code, and maybe Netbeans. So why doesn't Oracle tell us if and how to automatically convert all eligible variable declarations into var declarations with these IDEs? It's been 3.5 years since Java 10.
It certainly took me a while until I found how to do this in IntelliJ: Right-click on a file/folder, "Analyze - Run Inspection by Name…", then search for "omitted", select the rule "Local variable type can be omitted", then select all the files/variables you want to change, and finally push the "Replace existing types with var" button on the right.
To sum up, I disagree with Ron's statement on why people don't upgrade from Java 8: We create business value first, hardware gets cheaper while developers get more expensive, he presented no evidence for costs or savings, and Oracle is no help in convincing us developer or our bosses.
Agree? Disagree? Don't care? Let me know on Twitter: @karsilz
Frameworks & Libraries
Spring 6 Supports Java Modules
In May, I stumbled across an issue comment where Juergen “Spring” Hoeller revealed the “introduction of module-info definitions across the codebase”. I speculated that this may mean that Spring 6 will let us build applications with Java modules (see issue #35).
Turns out I was right:
Spring Framework 6 is indeed expected to introduce module-info descriptors for all core framework modules, with minimal required dependencies on core Java modules, enabling the JDK's
jlinktool to build custom runtime images for Spring setups.
VMware didn't announce this at Spring One, but they did confirm it in a Q&A that was in my article about Spring 6 & Spring Boot 3.
Before you get too excited about Java modules - it may be too little, too late for Java modules. Why?
From what I know about Java modules, they have two benefits for us Java developers: They give our code stronger partitioning so that my class can't access something in your class that it shouldn't. And jlink produces a smaller, custom version of the Java runtime to ship with our Java applications.
Now we can get the partitioning without Java modules with ArchUnit. Granted, a compiler error from Java modules is better than a failing unit test with ArchUnit. But unlike Java modules, ArchUnit works with all Java programs.
And it seems the Java world has settled on how to make Java small at runtime: With GraalVM and native programs. Maybe Java modules can make GraalVM even better, but GraalVM seems to do fine for applications without Java modules.
But there's one thing that Java modules have in common with GraalVM: We don't know if our Java libraries work with them. Here's what VMware said about Java modules in Spring:
There might be constraints with optional third-party libraries and certain configuration strategies, so it is still unclear how popular such explicit module usage will become among Spring users.
Releases
Adoptium OpenJDK Java 17
The project formerly known as AdoptOpenJDK has Java 17 ready for Windows, Linux, and Mac. It's still a work in progress. For instance, at the time of writing, Linux installers seem to be missing.
Micronaut 3.0
When we talk about the new Java frameworks that challenge Spring Boot and Jakarta EE, we usually say "Quarkus and Micronaut". Quarkus publishes releases like there's no tomorrow. Well, now it's Micronaut's turn. So what's new?
Micronaut 3 switched out its reactive framework from RxJava2 to Project Reactor. Classes don't automatically inherit annotations anymore, only those with @Inherited. Annotations in the javax.annotations namespace got replaced, and inversion of Control (IoC) saw refinements. Server filters are now called exactly once, even if errors occur.
That's not all, so please see the InfoQ article or the release notes for details.
Spring Boot 2.5.5 & 2.4.11
As foreshadowed last week by the Spring Data releases (see issue #54), Spring Boot 2.5.5 and 2.4.11 saw the light of day last week. We get 41 bug fixes, documentation improvements, and dependency upgrades with 2.5.5 and 32 of those with 2.4.11.
Announcement 2.5.5, announcement 2.4.11
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.
Discussion (0)