javac “—release” flag, Java 8 security updates until 2030, SOLID principles, Jira for all, Micronaut 2.5, and Spring Data 2021.0.
This is issue 34 of my weekly newsletter, “How To Build Java Applications Today”. I read all the Java newsletters, so you don’t have to! And I try to entertain you a bit while presenting Java news.
If you like my newsletter, then subscribe to it on Substack!
The universe is a cruel, uncaring void. The key to being happy isn't a search for meaning. It's to just keep yourself busy with unimportant nonsense, and eventually, you'll be dead.
Mr. Peanutbutter, a character in the animated TV show “Bojack Horseman”, misses out on writing yet another life-affirming self-help book.
It’s been a quiet week for me: No talks, no conferences, no articles, just working on my web & mobile apps.
I wrote about the GraalVM 21.1 release in the last issue and said this about its multi-tier compilation:
Because some optimizations now run later, we also get “later peak performance”.
Multi-tier in GraalVM helps reach peak performance faster, not later.
He also pointed to this Twitch video for detailed explanations.
Nevertheless, we can see that multi-tier approaches peak faster, especially early on.
But the article also shows scenarios where peak performance is achieved later, as I claimed last week was always the case. Here’s the first one (highlights are mine):
In many practical scenarios, we are interested in short-running programs such as command-line tools or single unit-test executions. In other scenarios, we expect that the program achieves decent execution performance as soon as possible, even if it achieves the best possible peak performance much later.
So some long-running programs achieve peak performance later. The same is true for a program called TruffleSqueak that the article cited:
As an expected tradeoff, it takes a bit longer to reach peak performance.
So my categorical statement about “later peak performance” in the last issues was wrong. Instead, it’s a mixed bag: Some programs reach peak performance earlier, some later. I should have read the article more carefully.
Thank you, Oleg, for pointing this out!
Java compilers can produce byte code that runs in earlier Java versions. But what happens if our code uses a Java API that’s not available in that earlier Java version?
We’ll get a runtime error, as it turns out. You can try yourself:
- Write code that calls
List.of()(which is only available in Java 9).
- Compile this with Java 9 or later and use
—target 1.8. to create bytecode for Java 8.
- Then run the compiled code in Java 8. Boom -
The way to fix this is by using the compiler flag
—release 8 instead. That will now give a compile-time error on
List.of(). Yeah, I didn’t know this flag either!
How does Java 9 know about the
List methods of Java 8? Read this excellent article to find out! I stole my example there.
BTW: In my current project, I work the other way around: I compile with Java 14 and run with Java 15. I would love to compile & run with Java 16. But that’s as far as I got without compilation or runtime error that I just didn’t want to deal with.
Here’s an article you want to hide from your boss. Bad: Java 8 is still the most used Java version (69% market share, according to JRebel - see issue 27, “JRebel 2021 Java Technology Report”). Worse: We can run Java 8 until 2030 if we pay Oracle for “Extended Support”!
So, why am I showing you this? Because it’s better you learn the bad news before your boss tells you: “No need to upgrade to Java 17 because we can stay on Java 8 for ten more years!”
SOLID is an abbreviation to die for:
- Single Responsibility Principle
- Open-Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
If you’ve never heard of SOLID or need a refresher, then this article is for you.
As with many of these laws & principles, I find myself sometimes breaking them. For instance, my classes sometimes have more than one responsibility, violating the “S” in “SOLID”. I’d like to think that I’ve gotten better there over the years (Jonathan, if you read this, I’m terribly sorry for
BusinessMethods). But then again, maybe I’m just fooling myself, and nobody tells me because I code alone these days…
Jira is hands-down the best issue tracker I’ve ever used. And I’m not just saying that because I was as Jira/Confluence admin for many years. At least I think I don’t.
Well, Jira doesn’t want to be an issue tracker just for developers anymore. Instead, it now wants to organize the work of “all teams within an organization”. So Atlassian, the makers of Jira, released “Jira Work Management for business teams like marketing, HR, finance, operations, design, legal, sales, and more”. They also updated the issue view. That’s great because the issue view was already confusing to unsuspecting developers, let alone mere mortals.
Why is Atlassian doing this? Here’s my answer, and it’s pure speculation on my part.
First of all, it’s always good if you can dramatically expand the market for your product/service, as Atlassian just did.
Secondly, Jira faces more competition in their biggest market - developers. As I reported in January about Spring Data’s migration from Jira to GitHub issues, when your code is in GitHub, then GitHub issues offer several advantages over Jira:
- One login
- No additional issues for pull requests anymore
- Auto-linking references to issues, pull requests, source code, and commits across all GitHub projects
- Mention & notify any GitHub user
This probably also applies to Gitlab, but they have less market share than GitHub.
That was quick: Only seven weeks after Micronaut 2.4 (see issue 27, section “Micronaut 2.4 Released”) we already get version 2.5. But I guess that’s one way of differentiating from Spring Boot - they only release every six months.
So, how much can you do in seven weeks?
Not a lot of features, as it turns out: Micronaut Data now supports Java 16 records, Kotlin immutable data classes, reactive data sources with R2DBC, and optimistic locking. The “dependency bump department” contributes Java 16, Gradle 7, and GraalVM 21.1. And those are the big-ticket items.
Not bad for seven weeks, but a bit “micro” in scope for a major release. I know, a bit of a cheap shot, but I didn’t call the framework “Micronaut”, they did!
Talking about six-month release cycles: Spring Data just had its second one. Well, they must have gotten much more done than the Micronaut guys, right?
But then again - it’s a Spring project, it’s the incumbent (JRebel pegs Spring Boot’s market share at 62% - see issue 27, “JRebel 2021 Java Technology Report”). So it doesn’t need to be the best or the fastest. It just needs to be not much worse than, say, Micronaut Data.
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 entrepreneur. Karsten got a Master's degree in Computer Science at the Dresden University of Technology (Germany) in 1996.
Karsten has developed software in five European countries and the US. In 2004, he co-founded a software product start-up in the US. During power outages, the software protected TV, Internet, and phone services for 50 million North American cable TV households. Karsten led product development for 13 years and left after the company was sold successfully.
Karsten has worked as a contractor since 2017. He co-founded the UK SaaS start-up "Your Home in Good Hands" as CTO in 2020.