21
How to Build Java Applications Today: June 21, 2021
snyk JVM Ecosystems Report 2021, Google's UI toolkit Flutter 2.2, Eclipse IDE gets a working group, Eclipse 2021-06, Spring Native 0.10.0, Keycloak 14.0.0, and WildFly 24.
This is issue 41 of my weekly newsletter, “How To Build Java Applications Today”. I read all the Java newsletters, so you don’t have to! 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.
Idealism is what precedes experience; cynicism is what follows.
David T. Wolf, an American writer (born 1943), may be a bit harsh. Can’t we have realism following?
Last Wednesday, I gave a 40-minute conference talk about “Pick Technologies & Tools Faster by Coding with JHipster”. It’s in German, and it’s behind a paywall. I guess that’s the definition of “in-accessible” to most of my readers. I hope to hit some JUGs in the fall, so there could be a publicly available, English version of this talk in our future!
The second of the two “What tech do we Java developers use?” reports is here: 62% of developers use Java 11 in production, 25% even Java 15, AdoptOpenJDK leads with 45%, Spring Boot is at 58%, Kotlin is the second-most popular JVM language, IntelliJ IDEA is 3x as popular as either Eclipse or VS Code, and Maven is used twice as much as Gradle.
Before we dive into the details: We can’t compare this year’s numbers against the ones from last year because the survey allowed for multiple answers this year. But the data is fresh: The survey ran for six weeks in February and March 2021. Don’t ask me why it took three months to publish.
The biggest surprise is that 62% use Java 11 in production and “only” 66% use “Java 8 & older”. The “JRebel 2021 Java Technology Report” (see the section of the same name in issue 27) says only 36% use Java 11 and 84% use “Java 8 and older”. That was based on 876 responses from August to November last year. Where does the difference come from?
I don’t think that half a year (February/March vs. August-November) makes a big difference. To me, it comes down to the surveys. Surveys are hard, even if you’ve been doing it for decades. Just look at the last two US presidential elections as an example. And even if you ask 2,000 randomly selected, perfectly representative people, you still get an error of +/-2.2%. And I think neither of these two surveys asked “perfectly representative Java developers”. What is that even?! And these are global surveys, which complicates everything by an order of magnitude or two.
Just look at the Java version numbers from the JRebel report: Java 8 increased from 58% in 2020 to 69% in 2021, “Java 7 or older” grew from 7% to 15%. I don’t think we’re seeing an increase of Java 8 or older in the wild. I believe we’re seeing bad surveys.
We can’t compare framework numbers between the two reports directly because JRebel only asked for the main project. But we can compare the ranking: JRebel put Java/Jakarta EE into the “Other” bucket (17%) and declared DropWizard (9%) the runner-up behind Spring (62%). snyk makes Java EE (24%)/Jakarta EE (13%) the runner-up and puts DropWizard at a paltry 4%. snyk even distinguishes between Spring Boot (58%) and Spring MVC (29%) and makes Quarkus the leader of the “Hip Framework Pack Chasing Spring Boot” (11%).
AdoptOpenJDK has 44% JDK market share; its Eclipse incarnation Adoptium already 1.3% in this report (see section “AdoptOpenJDK Gets Eclipse Working Group and Access to TCK” in issue 29. Next is Oracle’s OpenJDK at 28%, followed by Oracle’s “Non-OpenJDK” at 23%. The third place among OpenJDK distributions goes to Azul with 16%.
No surprise: Java is the most popular JVM language with 91%. Kotlin is second with 18%, Groovy third with 13%. You know, that Groovy which is 3.5 times as popular as Kotlin in the TIOBE index (see last issue). Sigh.
IntelliJ IDEA reigns supreme with 72%, Eclipse is second with 25%, and Visual Studio Code has a strong 23%. Every second developer uses more than one IDE, every fourth developer four or more. Guys: I hope somebody forces you to use four different IDEs! I can’t imagine why I would want to do that…
Build tools are the last stop here: 76% use Maven, 38% Gradle - the usual 2:1 split. My condolences go out to the 12% who still use Ant.
Dear snyk, dear JRebel! Every year you run surveys, asking us Java developers about the technologies & tools we’re using. We love to read those results! But surveys are hard, and you’re not good at it. And you already know the answer to our most pressing questions. You, snyk, scan our build files: So you know what frameworks we use and what build tools. And you, JRebel, sell a class loader: You also know what frameworks we use - and which Java versions & which Java distributions on top. So please stop asking us those questions and put a “Share data anonymously with vendor” option into your tools instead. Thank you!
I think Google’s Cross-Platform UI Toolkit Flutter is the best way for Java developers to build native business applications on iOS & Android. Google claims it’s also the most popular one now. Version 2.2 is a bug fix & stabilization release.
I’m shamelessly ripping myself off here by writing about an article that I published today on InfoQ. And yes, I snuck a “2.5 alliteration” into the title. 😁 Even “more rip-some”: I often talk about how Java developers should build front-ends with Flutter, most recently at a conference in Japan.
But I really think that Flutter is the best way for us Java developers to build native iOS & Android apps today.
But doesn’t Flutter use Dart? We don’t want to learn another language! I agree - but this is Dart:
class MyClass extends AnotherClass {
String myString;
int myInt;
List<String> myList = new List<String>();
String sayHello(String name) {
var feedback = "Hello, " + name;
return feedback;
}
}Looks a heck like Java, doesn’t it? Only the new List<String() doesn’t compile in Java.
Now Flutter doesn’t use the native UI elements but emulates them instead. But I think it’s good enough for our iOS & Android business applications. And are you tired of waiting for your Angular app or Spring Boot server to restart? Flutter code changes are live in less than a second. See for yourself in my short video!
So what did Google announce for Flutter 2.2?
You can tell that lots of people still ask, “When will Google kill Flutter?”. Why? Because half of the release announcement is Flutter touting how it’s the most popular framework now, and how all these wonderful companies use Flutter for all these wonderful-ler apps, and how the wonderful-lest companies even port Flutter to new environments. Look at Google’s Angular 12 announcement a week earlier for contrast: No chest-thumping, no name-dropping, just stuff that’s in the new release.
To be honest: There isn’t much new in Flutter 2.2. It’s a lot of bug fixes, performance optimizations, and some new features we probably don’t care about in our enterprise applications (Google Ads, in-app purchases, and in-app payment). That’s a good thing, in my mind - Flutter added a lot of functionality recently, so some clean-up is welcome.
So if you’re curious about Flutter, then you can quench that thirst by watching 16 minutes of my talk - or 8 minutes at double speed (time-stamped YouTube link). I compare Flutter to React Native and tell you what I liked and didn’t like about using Flutter in my current project. And my talk page has links to get you started.
If you’re an Eclipse project, then you can’t get by without a working group. Adoptium, the “Eclipse version of AdoptOpenJDK”, got one before it’s even done setting up shop at Eclipse (see section “AdoptOpenJDK Gets Eclipse Working Group and Access to TCK” in issue 29). MicroProfile delayed their 4.0 release by nearly half a year to install one. So, how’s the Eclipse IDE working group doing these days?
Splendidly, because it was just created! Yep, the Eclipse IDE that had its first release in the Eclipse Foundation 17 ago never had a working group! How did they function all these years? How did they know what to do? Are some Eclipse projects more equal than others?!
To be fair: The Eclipse IDE project started at IBM years before the Eclipse Foundation was created in January 2004. So the foundation probably let the “working group” slide the first year. Or maybe it didn’t even require one back then. And somehow, the “working group” topic never really came up again for 16 years! I can see the MicroProfile guys silently weep when they read this…
Let’s stick with Eclipse: There’s another quarterly release. And like with any other Eclipse IDE release that I’ve had the “pleasure” to cover, the release notes are a freakin’ dumpster fire of disjointed links. Some look like it’s 1995, some lost the links altogether, some don’t know that strike-through text is hard to read, some look Eclipse-like, and some don’t.
If the Eclipse guys can’t be bothered to sort out this mess once a quarter, then I don’t, either. The main page says Eclipse now supports Java 16 and Apple’s M1 Macs and improves the Java tooling and the terminal. The rest is up to you (to read). Good luck!
Spring Native uses GraalVM to turn Spring Boot applications into small native images that load quickly. We need Spring Boot 2.5 and GraalVM 21.1 to try it out.
This version makes one-third of all Java developers happy who use Gradle: Spring Native works with Gradle now! It can also run tests now and handle proxies on classes for the ahead-of-time compilation with GraalVM.
And as the Spring Boot fans in the Quarkus team like to point out: Spring Native needs some more time to bake in the oven! Spring Boot used 126 MB in one of their tests when compiled natively - vs 15 MB for Quarkus. Even in “interpreted JVM mode”, Quarkus used less memory (115 MB)!
That was quick: Six weeks after version 13.0.0 (see issue #36) comes version 14.0.0. A refresher: Keycloak gives us OAuth 2.0 and OpenID Connect for authentication, LDAP and Active Directory for that “enterprise feeling”, and “social logins” for Google, Facebook, GitHub, Twitter & more.
As we expected, they didn’t add much in those six weeks. Keycloak now officially supports Financial-grade API (FAPI) and improved user profile management & offline sessions. The full issue list is in JIRA.
We all run Java in containers, Kubernetes, the cloud, or all of those at once. Or so they say. Now here comes a release for the old-fashioned among us: an application server! Apparently, they are not extinct yet. So, what’s new?
The “MicroProfile Reactive Streams Operators subsystem“ is now up to version 2.0, client passwords can specify character set & hash encoding, an older SSL protocol is supported, and we can use multiple SSL certificate revocation lists.
What’s not in the release?
Karsten Silz is the author of this newsletter. He is a full-stack web & mobile developer with 22 years of Java experience, author, and speaker. 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.
21