Life On The JVM

This article was written to those who still think that the JVM equals Java and that in turn means “enterprise”. If you already understand this isn’t true, you can ignore this text below. With that clarified, let’s move on!

What is Java?

One of the first things people say when they hear the word Java is to complain over how “slow” it is. While that might have been true at some point in time, it certainly doesn’t ring true now. Far from it. It’s just one of many myths Java still hasn’t shook off. But when referring to Java we often mean the entire Java platform. Yes, Java is a platform that includes the Java Virtual Machine (JVM), the Java language and the APIs (the JDK). Pie chart showing JVM/API/Java

Often cited as an unbreakable trinity, those three aren’t inseparable. Quite the opposite. During the last five years people have realized that the virtual machine is capable of so much more than running Java. In hindsight one could argue that this was a failure by Sun to market this trio as “Java” instead of dividing them. So instead of focusing on myths that’s been dispelled for years, I’ll try to lay out some arguments to why the JVM is something you really should embrace. Now more than ever.

History

Java and the JVM has been around since the mid-nineties. That was when (the now late) Sun released the first JDK. The shipped VM was pretty basic and was completely interpreted. Much like CPython or Ruby MRI is today but I’ll get to that later. It wasn’t until 2000 that the HotSpot JVM was released with JIT support and shipped with the JDK. Although JIT was introduced in ‘98, this was the first JVM to support JIT compilation, enabling substantial increase in performance. HotSpot still powers Sun’s official JVM and probably this won’t change anytime soon. It is inside HotSpot where Sun has put the last decade of VM research. Constantly improving and enhancing execution speed, memory management and platform availability.

Grown up

As I mentioned above, the first JVM was released in the mid-nineties. That’s 15 years ago.. time really moves fast. Counting in internet years, that’s 150 years or something like that. Anyway, what I mean to get across that the JVM is software that’s been around for many years. All those years come with battle-tested, first-hand experiences, all collected and drawn upon by HotSpot. Not many platforms comes this kind of guarantees. I sure don’t know many.

Due to being open and mature, the platform has become quite ubiquitous. Seen anywhere from smart cards to mobile phones to big multi-core servers shows its penetration. In fact, it’s very likely that you or your company have the JVM deployed today in a production system. This is good news to anyone wanting to adopt more fully. Why? Because few things will make the ops people grouchier than telling that gizmo X must be deployed to Y machines (and yes, the ops people could mean you). However, if you continue to support what’s already running and working, you’ll be in a lot less pain.

Multi-lingual

When the word JVM is mentioned people almost always recall it as the “the VM that runs Java”. While that used be true years ago, much have happened the past years. Developers have realized that you target Java as a platform, or more specifically, the JVM.

To make ideas work, you only need to produce byte-code for the VM to run. Simple, eh? This is the very fact why we’ve seen such an explosion in languages targeting the JVM. Just looking at JVM languages on Wikipedia gives you a list of over 50 languages. And that list is non-exhaustive.

Tag cloud of JVM languages

I won’t dwelve into each of these, check them out if they interest you. But in this seemingly jungle of languages there are some more prominent ones. Scala, Clojure, JRuby, Jython and Groovy are languages that see a high momentum right now. Scala is often touted as the successor to Java. Even the creator of Java, James Gosling, likes to think so. Quite reasonable as it solves a lot of pain points with Java.

So what about the language Java?

Lately people have been dumping the language Java in favor for better and more hip languages. Maybe to try out a JVM-only language such as Clojure. Some aren’t migrating to a new language but rather moving to a better VM - compare JRuby to Ruby.

This may seem like there’s no other way but down for Java to head. In some sense, this is true. People will use Java less in the future. But not all is lost. The JVM is still written for Java, with all optimizations that come with it. This means Java is still the top performer on the JVM, making it very attractive for performance-critical parts. Somebody once said that “Java is the assembly language of the JVM”. There’s a lot of truth about that.

An analogy could be drawn between C and say, Python. You’ll write your low-level, critical parts in C and implementing the high-level, domain specific stuff in Python. The same thing could be done with Java and high-level languages but without the need to drop down to platform specific native code.

By the way, looking at benchmarks of raw performance of Java shows that it’s one of the fastest languages around - despite common myths.

True platform independence

What’s common held up as a pinnacle of many languages is that they are platform independent. While this is very true in theory, it turns out it’s not so true in practice. The reason for this is that languages with weak VM implementations always have to resort to a low-level native language to speed things up. Ruby, Python and PHP are examples of this.

Have a look at PHP - it provides a reasonable speed if you make use of SDK functions only. Define your own array helper functions and see performance come to a grinding halt. This is because almost all SDK functions in PHP are implemented in C. And this is where the ugly begins. Keeping all these libraries available cross-platform is truly a PITA. C compiler versions, native SDKs, 32/64-bit problems, different OSes, the list can be made long.

However, on the JVM, life is quite the opposite. Porting something to another platform is never a problem. Send away that WAR and install your favorite JVM and off you go. What you expect would work actually works. Again, the reason the JVM can have this luxury of not dropping low-level is that it’s so highly optimized.

There’s also projects trying to remove the OS completely and have the JVM run as an OS, yielding potentially even higher performance. In addition, specialized hardware like Azul’s servers take Java performance to the extreme.

Ecosystem and tools

Java has a very broad ecosystem of library and tools available. There’s something available for almost every problem. While this plethora of libraries is nice I would say the availability of high-quality developer tools is what makes Java stand out. Java has a couple of the most productive IDEs out there. NetBeans, Eclipse IDE and IntelliJ are major players. The latter is a real mean productivity machine for code!

Together there’s also really mature build and CI servers available, not to mention build tools. Something that’s usually a good indicator of a platforms maturity is the availability of profiling tools. Without such a tool, countless hours can be wasted figuring out performance bottlenecks in your code.

Luckily, life isn’t like that on the JVM, we have high-quality commercial tools like JProfiler and YourKit. It’s this kind of maturity that you really appreciate as a developer doing real-world development.

Where the platform is heading

Currently, Java is a bit at crossroads. For the platform to survive, serious commitment must be made from Sun, erhm.. Oracle’s side. Even though there are lots of languages on the JVM today, there still is a lot of room for improvement making the JVM a friendlier place for non-Java languages.

What every dynamic JVM language is currently waiting for is “invokedynamic” (JSR292), which enables dynamic calls without “hacking” the VM. But regardless Oracle’s recent takeover, things look bright for the platform.

The Da Vinci Machine is implementing and trying out loads of new features of a future VM. Tail calls, continuations and lightweight bytecode loading are on the horizon.

JVM is a platform!

In closing words, I hope I lighted some fire in you as a JVM skeptic. The JVM is a big machine where improvements are constantly made and a great place to be on. Comparing this development on the VM to CPython or Ruby MRI wouldn’t be fair.

But in turn, the Java virtual machine has no competitors (sorry, CLR isn’t even close). Finally, what needs to be said is that the JVM is a platform. We don’t need divide and conquer individual languages.

Your string or Twitter library can be used by all languages on the same VM. Keep this in mind next time you hack on your non-Java JVM project.