Java Full-Stack Report January 2022: New & Noteworthy
What’s This?
Here are the most important news for Java developers from last month - in my opinion, at least.
New & Noteworthy
Critical Log4j Vulnerability Log4Shell with Zero-Day Exploits
Unless you’ve been under a rock for the last month, you’ve heard (and probably dealt with) Log4Shell. It’s an attack against applications with vulnerable versions of the popular Log4j logging library. If an attacker tricks Log4j into logging a so-called JNDI link to a JAR file, then Log4j will execute that JAR file. And the attacker can then run any remote code on the computer that runs the Java application!
“Tricking Log4j” may be as easy as sending an HTTP request with a JNDI link in the HTTP header. And it doesn’t have to be our code that uses Log4j. A library in our application could use Log4j and allow for an attack. Or a Java tool we use could have Log4j.
The US cybersecurity and infrastructure agency director called it “one of the most serious that I’ve seen in my entire career, if not the most serious”. It made headlines around the world in non-tech media.
This is probably even worse than it already sounds: Remember Heartbleed, the OpenSSL vulnerability discovered in April 2014? Its severity was 7.5. Log4Shell scored a 10!
Log4Shell was exploited before it was publicly disclosed, though not on a wide scale.
So how do you fix Log4Shell? There are too many variables here to have a definitive solution here. But one way is to upgrade Log4j to the latest version, which is 2.17.1 at the time of writing.
Please also read my editorial about this topic: Log4Shell Shows The Need for “Trustworthy Java”.
Garbage Collection Improvements from JDK 8 to JDK 17
They say that you often get a free performance boost when upgrading Java. This is certainly true for garbage collectors: Benchmarks show better throughput and latency. And G1, the default collector, also uses less memory.
Red Hat Reluctant on Proposed 2-Year Java LTS Cadence
When Oracle released Java, they proposed to shorten the Java Long-Term Support (LTS) cadence from three years to two years. Oracle has two goals: Faster delivery of new Java features and increased appeal of non-LTS Java releases. This move seemed like a foregone conclusion with public support from various OpenJDK contributors.
But now Red Hat cautions against this move and urges “Oracle to seek broader input from vendors and customers who certify on the Java platform”. They make a valid point: It’s easy to imagine organizations who would upgrade Java only every four years instead of two because “two years is just too fast”. And having fewer non-LTS releases doesn’t make them more attractive in my mind. Why do four Java migrations (three non-LTS releases plus one LTS) with minor benefits each time when we can do one migration (to the LTS version)? It’s less work overall and has all the same benefits, just about a year later than they were available. If anything, I think fewer non-LTS releases are less appealing: The wait for the next LTS release is shorter!
And you know, asking Java customers - vendors, developers, and organizations using Java - seems like a good idea. To be honest, I’m not sure Oracle did enough of that before they announced their plans.
JetBrains IDEs Get Remote Development
Our developer machines are often tricky to set up: Many tools, SDKs, IDEs, and settings to install and maintain, and developers can mess it all up. There are two ways to fix that: Standardize the set-up and maintenance and make it more “un-messable”, or move the development environment to the cloud as “remote development”, shielded off from “developer messiness”.
Visual Studio Code has had remote development for a while now. It’s called GitHub Codespaces. GitHub uses it as the default development environment and recently updated it.
Not to be outdone, JetBrains now offers this feature for many of its IDEs as well. We run a thin client called JetBrains Gateway on our development machine. And the IDE back-end runs somewhere else - another physical machine, a VM, or in the JetBrains cloud as so-called Dev Environments.
Since this is a beta, we don’t know the pricing yet.
JetBrains Clones Visual Studio Code - But At What Price?
Talking about “not to be outdone by Visual Studio Code” (VS Code): JetBrains is working on a VS Code clone called Fleet. It’s easy to see why: VS Code is rapidly becoming the one thing we never had - a free, fast, good-enough, cross-platform, cross-language IDE for every developer. That makes VS Code an existential threat to JetBrains: How much longer will developers pay for heavy, “one per language” JetBrain IDEs in light of VS Code?
Like VS code, Fleet is lean, multi-language, and multi-platform. At first sight, it seems to have at least one feature that VS Code doesn’t have out of the box: Multiple users working in the same Fleet instance.
Will Fleet run IntelliJ plug-ins? Or will it require new ones? We don’t know. I think VS Code has the better plug-in model right now: Most update without restarting the IDE and mess less with the IDE. Now in IntelliJ, the first advice from JetBrains for any sort of unexplained trouble usually is to “disable all 3rd party plug-ins”, demonstrating a lack of IDE control over plug-ins. And most plug-in updates in IntelliJ require a restart.
The price of Fleet is unknown. On the one hand, that means: Will Fleet be free to use? Being free is certainly part of the appeal of VS Code. On the other hand, that means: What happens to the existing JetBrains IDEs? Now JetBrains said that “Fleet doesn’t replace our existing tools” and promises “to invest in all our IDEs”. But there are only so many JetBrains developers to go around: Will the A team work on Fleet, the B team on IntelliJ, and IntelliJ move much slower as a result?
I’m personally invested in this: VS Code already replaced WebStorm for website maintenance for me. Yep, you’re reading a site that’s built with VS Code! But I have to use IntelliJ because JRebel doesn’t work with VS Code.
Fleet is in early private preview.
An Oral History of Stack Overflow – Told By its Founding Team
I don’t need to tell you how valuable Stack Overflow is. For a trip down memory lane, listen to this podcast.
Benedict Evans’ Annual Tech Presentation
Benedict Evans is a smart tech analyst. He’s got a weekly, free newsletter that’s worth reading.
Once a year, Ben publishes a “State of Tech” presentation. If you read only one presentation on technology trends a year, let it be this one. It’s called “Three Steps to the Future” and is currently at the top of his presentation page.