Day 9 - In Defense Of The Modern Day JVM (Java Virtual Machine)

By: Gene Kim (@realgenekim)
Edited By: Joshua Smith (@jcsmith)

In this post, I'm going to tell you something very surprising that happened to me earlier this year, which has led me to make an impassioned (and perhaps surprising) defense of something that I feel has been unfairly maligned, and share with you some things you may find surprising.

In September, I had the privilege of attending the Sensu Summit here in my hometown of Portland, Oregon. On the evening before the first day of talks, I ran into so many friends I've met over the last 10+ years. Not surprisingly, It was great to catch up with everyone, and hearing about all about their their great new adventures.

When people asked what I’ve been up to, I remember enthusiastically telling everyone how much fun I've been having programming in Clojure, which I later wrote extensively about in a blog post called "Love Letter to Clojure."

I told people how initially difficult I found functional programming and Clojure to be, given that it was a LISP ("doesn't even look like code!") and didn't allow mutation of state ("you can't change variables!"), but the sense of incredible accomplishment I felt being able to quickly, easily, and safely solve problems, in a manner completely unlike the first 35 years of my programming career ("even after 3 years, my code base hasn't collapsed in on itself like a house of cards!").

I remember laughing, jubilantly telling everyone this, and then looking around, and then freezing in surprise... Something had changed... People weren't smiling at me anymore. In fact, people were looking at me as if I had said something incredibly impolite, uncouth, or maybe even immoral.

"Uh, what did I say?" I remember asking everyone in the group. No one said anything, instead just looking back at me with a forced smile. "No, really, what did I say?" I insisted. Still just polite smiles.

In my head, I furiously went through everything I had said, trying to figure out what I might have said that was offensive. I had mentioned Clojure, functional programming, LISP, that I loved that Clojure it ran on the JVM, the programs I had written, what I learned, and...

"Wait, is it because I said I loved that Clojure runs on the JVM?" I asked. Several people around me finally laughed, apparently with complete disbelief that a fellow enlightened DevOpser could say such a thing. When I asked what was so surprising, it’s like the floodgates had opened.

They tell me about all their horrific war stories of their lives in Ops, being thrown incomprehensible and completely opaque Java JAR files, which then invariably detonated in production, resulting in endless firefighting, at night, on weekends, during birthday parties...

"Holy cow," I remember saying, shaking my head in disbelief. "I totally forgot about all of that..."

Basically, when I said the word “JVM,” they heard, “Here's my JAR file. Good luck, chumps. Kbye.”

Why I Love And Appreciate The JVM! And It’s Not Just Me!

Until that moment, if you asked me what I thought about the JVM, I would have told you something like this:

"The JVM is amazing! Clojure runs on the JVM, and takes advantage of the billions of dollars of R&D spent over twenty years that has made it one of the most battle-tested and performant compute platforms around.

“And it can use any of the Java components in the Maven ecosystem — Maven -> Java as NPM -> NodeJS, Gems -> Ruby, Pip -> Python, etc... And there’s so much innovation happening right now, thanks to Red Hat's Quarkus, Oracle's GraalVM, Amazon AWS, Azul, and so much more.

The JVM has enabled me to be so productive! There’s never been a better time to be using the JVM than now!”

But after that astonishing evening at Sensu Summit, for weeks, I kept thinking, “Am I having so much fun programming in Clojure, being a Dev, that I’ve completely forgotten what it’s like to do Ops? Is it possible that Dev and Ops really do have two very different views of the JVM?”

As an experiment, I put out the following tweet (and this one, too) :

I recently observed something interesting/unexpected. I’m performing an experiment & will report out results.

Please reply to this tweet w/following info:

1. Which do you identify as? Dev or Ops

2. Then type any words / emotions that come to mind when I say ‘JVM’ or ‘Java Virtual Machine’.

Begin. Thx! 🙏❤️

Amazingly, I got over 300 replies, which included some of these gems that evoked bad memories from the past:

• Very-annoying memory-hog
• "Write once, run anywhere" and "It's running slow... Let's just give it more memory."
• Pain, anguish, suffering, and screams of "Whhhhyyyyyyy?!?!?"
• Possibly fast, definitely difficult-to-troubleshoot opaque process that is not working and no one knows why! But it's the most important thing in our stack!
• Oh no, this thing runs in what now? It's horrendously slow, and will crash at inopportune times
• Bane of my early Ops existence.
• Pain
• Oh FFS, another 3am callout!!
• Out of memory again

And yet, I got a couple comments like these:

• Amazingly cool under appreciated tech under the hood. See Clojure, JRuby.
• My life 10 years ago. Can be really really fast and stable if you really really understand how to drive it.

My sample skewed decisively “Ops.” Last week, I asked some friends in the Java Dev community to repeat the tweet, and again, we quickly got over 200 responses. Here is a sample from the replies we got — my thanks to Stu Halloway from Clojure fame, Dr. Mik Kersten from Tasktop, and Josh Long from Pivotal.

Look how differently they talk about the JVM!

• Fast, reliable, ubiquitous, large ecosystem, easy packaging
• Brilliant piece of engineering
• Love the JVM, bored with the core language, great library ecosystem, solid, reliable, familiar, Clojure runs great on it.
• Robust, ubiquitous, ponderous, vintage, solipsistic
• Solid, battle-tested with great ecosystem
• Impressive, stable, rich, complex, ubiquitous, pervasive, Graal, native-awkward, powerful, elegant, clever, surprisingly long lived, under threat (licensing), tool supported, marketed.
• It's not just for Java; Reliable; It's grown with me over the years; Runs everywhere including my toaster; Under-valued
• Safe, known, capable, low risk
• Backend, concurrency, stability, performance, maturity, excellent design
• Runs everywhere. Java va Kotlin vs Scala. Spring Boot.
• useful, but not trendy with the webdevs
• Polyglot, JIT, fast, happy

I plan on creating a word cloud of all the amazing replies, and grouping them by sentiment — which will be written in Clojure and run on the JVM, of course. But due to deadlines, I’m not sure I can get it done in time for it to be included here. Stay tuned!

My Top Six Things You Should Know About The Modern JVM

To the Syadvent community, I wanted to share some things that excite me most about the JVM, which may surprise you. My hope is that you’ll see the JVM as a vibrant and viable way to run kickass applications in production. And that you’ll see some incredibly valuable characteristics of it that benefits all of us, and that we can move dramatically more of the JVM responsibilities to Dev (e.g., “you build it, you configure it, you run it”).

1. The JVM runs more than just Java: some of the well-known languages include Groovy, Kotlin, and Clojure. There are also implementations of other languages, such as JRuby (I had fun reading the slides from this 2019 presentation from the JRuby core team) and Jython, which were created to take advantage of the amazing run-time performance and multi-threaded capabilities of the JVM. You can find a more extensive list here.
   
2. The JVM runs some of the most compute- and data-intensive business processes on the planet, including at the technology giants (aka, the FAANGs, or Facebook, Amazon, Apple, Netflix, Google, and really, Microsoft should be in there, too — although I suspect it’s unlikely you’ll see too much of the JVM at Microsoft).
   
   You can see some of the fun stats and names in posts like this one.
   
   And most of the most famous data platforms all run on the JVM, either entirely or significant components: Hadoop, Spark, Storm, Kafka, etc…
3. The JVM runs some of the biggest web properties on the planet, like eBay, Google, Amazon, Alibaba, Twitter, Netflix, and more. The JVM has been used at scale for decades, and this lived-experience has born a rich, mature ecosystem of options for application developers. Frameworks like Spring (and increasingly Spring Boot) power Netflix, eBay, all of Alibaba’s various online properties, and more. Developers do not need to choose between simplicity and power: they can have both.
   
4. There are many JVM options out there, beyond the Oracle version and OpenJDK. And there are now really great utilities that make it easy to install, upgrade and even swap JVMs on your laptop,, thanks to utilities like SDK for MacOS — it supports many JVMs, including Correto (Amazon), GraalVM (Oracle), Zulu (Azul)...
   
   Personally, I’ve found it remarkably easy using SDK to switch my Clojure programs between different JVMs — I used this fabulous tutorial here. I used it to explore the GraalVM, which I’m very excited about, which I’ll describe next.
   
   And new JVMs now have a bunch of new memory garbage collectors, including the Shenandoah GC, written by Red Hat, which finally brings continuous compaction to the JVM, eliminating the need for “stop the world” GC pauses. Here’s a great talk about A New Age of JVM Garbage Collectors by Alexander Yakushev that I saw at the Clojure/conj conference two weeks ago!
   
5. I think the GraalVM project is so exciting! For me, GraalVM defies easy explanation — it’s an ambitious, entirely new polyglot JVM that allows running Java and other JVM languages, as well as being able to host languages such as JavaScript, Ruby, R, Python and LLVM-based languages. (!!!)
   
   GraalVM also enables native-image compilation, which essentially compiles your code into native executables, which allow nearly instant, sub-millisecond startup times, which addresses one of the primary complaints of conventional JVMs. These binaries are usually small (e.g., 33 MB executables instead of 300 MB uberjar files).
   
   GraalVM is the brainchild of Dr. Thomas Wuerthinger, Senior Director of Research at Oracle. You can listen to an interview of him on Software Engineering Daily. I suspect you’ll be blown away by his ambitious vision, and the massive productivity advantages they’re gaining by writing a JVM in a language that’s not C++.
   
   I loved this video of how Twitter is now using GraalVM to run all their Scala workloads by Chris Thalinger, resulting in a 20% improvement in performance and compute density. And here’s a video of Jan Stepien presenting on how to create native images for Clojure programs. Here’s another great article from AstRecipes, showing how native images resulted in a 300x improvement in startup times.
   
   GraalVM seems to be energizing a flurry of innovation outside of Oracle — Red Hat has created Quakus platform, intended to optimize the JVM for Kubernetes and similar environments. I remember reading the this blog post, getting excited about instantaneous startup times and significantly reduced memory footprints. You can find an interview of Guillaume Smet and Emmanuel Bernard on Software Engineering Daily — I found it especially fascinating that they are using Go as the benchmark to beat.
   
6. The JVM and Maven packaging ecosystem is a calming breath of fresh air: The Maven packaging ecosystem is one of the longest-lived and most successful package repositories. In terms of number of packages/components and versions, only NPM for NodeJS is larger.
   
   In a presentation that I did with Dr. Stephen Magill at GitHub Universe, we presented on the findings from the State of the Software Supply Chain research we did with Sonatype, studying the update behaviors within the software supply chain in the Maven ecosystem.
   
   One of the things this research reinforced for me is that packaging churn is growing to be untenable, especially in NPM in NodeJS. This funny tweet thread sums it nicely: “When npm was first released in 2010, the release cycle for typical nodeJS package was 4 months, and npm restore took 15-30 seconds on an average project. By early 2018, the average release cycle for a JS package was 11 days, and the average npm restore step took 3-4 minutes...."
   
   Of course, the catastrophic “nodularity” is a joke — but there are so many stories of projects where “I didn’t touch the project for 4 months, and now it no longer builds if you update any of the dependencies, and I probably need to update nom, too.”
   
   In other words, if every dependency you rely on is updating every week, and they are introducing breaking changes, you are in a world of hurt. In a world where the best way to keep your software supply chain is to integrate updating dependencies into your daily work, this becomes impossible.
   
   The Maven ecosystem are full of components that just work, have been working in production. In fact, there have been almost no breaking changes to the Clojure core libraries in 12 years!
   
   If you choose carefully, the components in the JVM ecosystem are stable, reliable, and updates can be made quickly, reliably, easily, without everything blowing up in your face.
   
   And by the way, one of most amazing talks I've seen is from @BrianGoetz, the Java language architect, on his stewardship of Java ecosystem from Clojure/conj 2016. What's unmistakable & so admirable is his sense of responsibility to not break the billions of lines of code that 9MM developers have written over the last two decades.
   
   The promise they make to them: “we won’t break your code”
   
7. Devs should configure and run their own applications and JVMs: The days of Devs throwing JAR files over the wall to Ops, who must figure out how to run it in production. Instead, the more modern pattern is having the Devs configure their own JVMs however they want, which then get deployed into a platform that Ops creates and maintains — but it’s the Devs who will be woken up if and when things blow up...
   
   

Conclusion

I hope I’ve told you something about the JVM that you may not have known, and made the case that the modern day JVM should be a great thing, both for Devs and for Ops!

PS: You can read more about Clojure and functional programming here, and more about how critical it is for Ops creates platforms that enables developers to be productive in my description of the Five Ideals here, featured in “The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data” (this book about DevOps is now a Wall Street Journal bestseller!!)