Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
Three reasons why I came back to Java and the JVM
- The Java community – an awesome and critical driver maintaining the spirit of open development, collaboration and experimentation in software
- Java tools & technologies – the tools used in Java (from IDEs to code analysis to profilers) benefit programmers more than the tools in other languages, such as C++ & Python
- The JVM (and Java) – the best balance productivity, performance, stability and more better than other platforms available to developers today
So if you feel like leaving Java and the JVM behind, I wish you luck. But be aware that you may find yourself back here again ;)
Leaving Java behind
Maybe you’ve never experienced this, but during my third year at Terracotta, I started to feel bored as my work gradually moved me away from the JVM-level clustering awesomeness that had me join the company. The integration of higher-level products like Ehcache and Quartz didn’t excite me as much.
But luck was on my side: Earlier that year, I had discovered a revolutionary new electronic musical instrument: the Eigenharp. After learning to play the portable 18-key Pico version, I quickly moved on and invested in the top of the line Alpha version with 132 ultra expressive keys.
Somehow the stars aligned and right when my passion was fading for my day job, Eigenlabs, the makers of the Eigenharp, posted a job opening for a senior C++ and Python developer to work on their core software. Although it had been more than a decade since I used any of the technologies involved, but they decided to hire me and the next couple of years became an enthralling ride through software engineering realms that were completely uncharted territory to me.
Eventually, Eigenlabs created a formal charity around the software and I accepted to become one of the founding trustees, leaving me to look for a new day job.
ZeroTurnaround immediately jumped to mind as their products are solving many problems that have frustrated me during my own development and deployment process, I’m totally psyched to be one of the Rebels now!
Reason #1: The Java Community
By early 2000, the Java ecosystem had become one of the front-runners in open-source software development. The spirit of open development, collaboration and experimentation became present everywhere. Everyone started to rely on the work of others and now it’s widely accepted that many of the tools are open-source, inciting companies to contribute back in some form or another.
Sadly, it doesn’t work like this in the music software world, where a lot still hinges on a singular excellent idea that’s closely guarded or those few DSP algorithms that provide a particular sound.
The technology of the music industry is stale and essentially hampered by hardware that needs to sell at ridiculously low prices. MIDI, the newest widespread standard that allows interoperability, actually stems from 1980s, warts and all!
Judging from what others tell me, the existence of MIDI is actually a miracle and very few people believe that a successor might come to life, given how inert and isolated the industry is.
So if you compare that with all the Java community’s protocols, APIs, tools, standards, platforms, languages and frameworks that we’ve devised over the years, you’ll probably see a huge gap. Some technologies stick, some don’t, but we always move forwards and the community mindset makes it easy for new ideas to prove themselves.
Reason #2: Java Tools & Technologies
We all know the saying: good coders don’t need an IDE. You know what, that’s a lie!
The best cross-platform C++ and Python development environment we found was Vim with a couple of plugins, using standard Unix tags to provide some form of project-wide indexing and symbol-based navigating. Don’t get me wrong, I love Vim for system administration tasks and it’s amazingly useful to remotely make changes to scripts and configuration files, but it’s a far cry from IntelliJ IDEA, NetBeans or Eclipse.
I’m an IntelliJ IDEA fan and to me the key benefit of our Java IDEs is that they provide us with the confidence to refactor. It’s not a problem to be bold and start ripping your code apart. The IDE’s understanding of the abstract syntax tree of your entire project makes this a deterministic operation.
The lack of such refactoring support in other languages, however, makes the rate of change in a project grind to a halt. Any broad modifications turn into multi-week projects with a huge amount of syntax twiddling and testing.
This means that since the impact of any changes is so immense, they’re almost never done, causing a lot of the code to turn stale.
Interestingly, I found that this also played on my morale as a developer. Improving what bothered me couldn’t realistically be done together with the scheduled tasks for upcoming milestones, causing the frustrating parts to pile up over time, always remaining there to nag me.
On-the-fly code analysis provides another benefit when combined with quick-fix intention actions.
I like to write the whole logical unit of code I’m working on, including fields, classes and methods that don’t exist yet. This keeps me focused on the problem I’m solving. Afterwards, the quick-fix suggestions use all the contextual information that’s at hand and automatically write the required skeleton API for you.
This removes a lot of the boilerplate typing and file creation, while still keeping Java verbose enough to keep it friendly and readable. This approach is virtually impossible in dynamic scripting languages and requires a manual process with constant iterative recompilations in C++, removing most of the benefits.
The final key piece of tooling that I missed were the profilers. It’s amazing what can be inferred from the Java Virtual Machine.
The first time I stumbled onto excessive memory creep in our C++/Python application, it took me a week to pinpoint and I could only alleviate parts of it. DTrace and MacOSX Instruments seemed the most useful tools, but I could only find the root causes by modifying the code and actually resorted to manual logging and statistics aggregation.
Afterwards we still weren’t happy with the memory usage, but with our small team we couldn’t realistically schedule more time to dig deeper, I wasn’t the first to try to get it further down. When I was at Terracotta, we solved a lot of difficult memory and performance problems across multi-node clusters, tools like YourKit always felt like a secret weapon and after being deprived from them, they feel even more precious!
Reason #3: The JVM and Java Language
I could write many pages on what I love about Java and the JVM, but since we’re limited on space here, I’ll just say that after my time away from the platform, Java, even with all its faults, can still be summarised as being the most well-balanced compromise between writing productivity, reading intuitiveness, execution performance, project maintainability, technology evolution, application stability and runtime visibility.
Anything else I use always has major shortcomings in one of more of these areas, vastly outweighing the improvements there might be in other areas. For me, this is a situation where negatives tremendously outweigh positives.
I’m glad that JDK 1.8 is finally adopting lambdas and that JDK 1.7′s invokedynamic bytecode is opening up the world of dynamic and domain-specific languages. It’s exciting to be part of the Java world again and my head is boiling with ideas, can’t wait to touch base with other developers at some of the upcoming conferences.
Please leave all your “Welcome Back Geert!” messages below, and tell me what you think about JVM/Java vs. other language platforms. Always nice to hear from you :-)