Maybe I Was Wrong about Java – Part 1

[special]Editor's Note: Being in a Java channel, most of us know the language very well and have been in its ecosystem for at least a couple of years. This gives us routine and expertise but it also induces a certain amount of tunnel vision. In a new series Outside-In Java non-Javaists will give us their perspective of our ecosystem.[/special]

I'm not the biggest fan of Java. I can read Java if necessary, and I've written some in emergency situations, but I don't make a habit of it. I have the same stereotyped impressions of it as many other non-Java people: It's big and slow and exclusively written by people who wear ties while programming.

I'm perhaps best known for an elaborate deconstruction of PHP, but that happened because PHP sparks a unique frustration in me. Java mostly inspires, ah, boredom.

But wait. PHP is popular because it has a singular advantage: It removes a few of the steps from the nightmarish ritual that is web development. Java doesn't have a comparable massive advantage, so it must be doing something right. Otherwise Oracle wouldn't brag about the nine trillion devices running Java. It wouldn't power the guts of a notable number of big websites. The dominant smartphone OS wouldn't be built entirely atop it. I wouldn't have a toaster that runs a JVM. (It works better than you'd think! You just have to wait a bit for it to warm up.)

So maybe — maybe — I have Java all wrong. Maybe I've been unfair to it. Maybe.

It might be time to re-examine my preconceived notions about Java. To bust some myths, if you will.

For reference, I've dabbled in a number of languages, but I mostly do Python and like many of its design decisions. Python has a little philosophical overlap with Java, so it's an interesting point of comparison.

Java Is Slow

Java definitely feels big and slow to me. The word is like molasses in my brain. When I think of Java, I'm reminded of the very few encounters I've had with it on the desktop. Perhaps most infamous was Azureus, the Java BitTorrent client that everyone used to download Ubuntu releases over a decade ago. It was surprisingly sluggish considering that all it did was download files, and everyone jumped ship to µTorrent when it came out. µTorrent is of course written in C++, which makes it faster and more performant.

The thing is, this doesn't make any sense. The only BitTorrent client I've used in years is Deluge, which is written in Python. (C)Python is definitely not as fast as Java by any measure, yet Deluge has always been snappy for me. The JVM is used in part because it's pretty fast, so whence came this association with slowness?

As much as we'd like to think otherwise, it's tough to make any real measurements here; so many factors affect speed that even benchmarking a single program against itself is unreliable, let alone comparing two completely different pieces of software. Did the machine get bogged down doing something else? Did the GC kick in at an inopportune time? Is one language better at a particular task? Am I using a bad JVM? Is one app better-written than the other? Even if I could control all of these factors, it's still tricky to measure the perception of speed, which is what this is really about. The best I can do is think this through.

Slow Programs, Slow Language

And I suspect a little bit of confirmation bias here. If a program is slow, we blame the program — but if a Java program is slow, we blame Java. Java's even at a particular disadvantage here; it's easy to notice that a GUI program is written in Java, since Swing sticks out like a sore thumb, but harder to be sure that it's written in C++ or similar.

In my experience this is especially visible in gaming circles, where you can find deep insights on game performance from people who've never written a line of code. Minecraft is slow because it's written in Java, you see, whereas Starbound is slow because the developers didn't "optimize" it. Whatever that means.

Another possible factor, though I don't know how true this is: I get the impression that many developers write C++ because they want to, but write Java when they have to? I've encountered a lot of C++ code that has no compelling reason to be written in C++, but a lot of Java code with a story that starts "we wrote this with Rails and ported it when it got too slow". (Or "it's for Android so we had to".) In other words, Java seems to be a common go-to for speeding up code that's already too slow, so any given Java program is reasonably likely to be doing some very heavy lifting. It's not that Java is slow; it's that slow programs tend to be written in Java. A problem of self-selection.

Meanwhile, much C++ is written purely out of spite. Or, rather, there's a subset of programmers who are obsessed with maximum performance and will reach for C++ whether or not they need it, because being against the "bare metal" gives them warm fuzzies and is totally worth the risk of spurious segfaults and memory errors. So a given C++ program isn't necessarily likely to be doing the kind of intensive work that would justify using C++.

Is The JIT At Fault?

I was originally tempted to blame some of the perceived slowness on JIT warmup, but I'm not sure that's likely. I've started experiencing JIT warmup more frequently myself, as I've been using PyPy more. PyPy is a JITted Python implementation (written in itself, hence the name), and one of the big barriers to wider adoption is that it takes a few seconds to warm up. Python programs that run more or less instantly with stock Python cause a noticeable delay when run with PyPy — and since Python is commonly used for command-line tools, that delay impacts quite a few programs.

But for anything that takes more than half a minute or so to run, PyPy is significantly faster. I would expect a JVM to have a much more advanced JIT than PyPy's relatively young one, so surely the warmup time would be even shorter. I doubt Java would get a reputation for being slow just because it dawdles a bit in the first twenty or thirty seconds.

I've also watched JIT warmup happen in realtime with LÖVE, a game engine that uses LuaJIT. If you draw the framerate on the screen, you can watch it start around 10 and ramp up to 60 over the course of several seconds. After that, it runs fine. Again, the slowdown is fairly brief, and it's never given me the impression that the engine or JIT as a whole is slow.

Java As A Toy

I'm willing to bet that this is largely gossip dating back to when Java first came out. Surely some C++ developers would've perceived Java as a reinvention of C++ that was comically slow... relative to C++. The original Sun JVM didn't have a JIT for several years, so very early Java was bytecode interpreted like most Python is now — but on much slower hardware.

It makes some sense from a cultural perspective, too. Java was presented as a "serious" language — i.e., a competitor to C++ — at a time when the only "serious" language was, er, C++. Anything that even smelled like an interpreted language was largely regarded as a toy. Even more so than now, I mean. If the entire spectrum of "languages anyone would use for serious development" ranged from C++ to Java, of course Java would look like a lumbering beast. Automatic garbage collection? What are you, some kind of infant? I bet your language can't even segfault.

Fast-forward twenty years, and half my operating system is written in JavaScript. I even once wrote a desktop app in Perl (yolo). At least Java looks better in comparison?

Java Is Bloated

Continue reading %Maybe I Was Wrong about Java – Part 1%

by Eevee via SitePoint