Java is not dead…in fact, it’s got more than enough energy to kick your app in the butt. Too often, critics focus on niche issues and make unfair comparisons to other technologies or languages that do not have the same level of widespread use, applicability or history as Java. It’s like comparing a car to a carpet.
Children today are able to learn Java. It’s widely adopted among Web and Enterprise App producers. It has seen some amazing improvements in recent years and even more good stuff is on the way. But even excluding those latest additions, Java is still pretty darn cool: consider the widespread applicability and excellent engineering behind the JVM platform, the clarity of syntax, the rich ecosystem of tools and libraries and the fact that Oracle says there are over 9 million Java developers out there (and many billions of app/device users). So why do I hear remarks about Java being “on its way out” or, since back in 2007, that it is becoming “the Cobol of the 21st century”?
The Java platform is an engineer’s dream
First there’s the Java platform. The HotSpot JVM is a marvelous piece of engineering. It does stuff the CLR can only dream of and is so heavily optimized that often Java apps can even match the performance of C programs. Also, there is quite a selection of other virtual machines available (such as JRockit, Zing), should your environment have some specialized requirements.
Secondly there’s a multitude of JVM-based languages, which makes the platform even more amazing. It goes way beyond the famous ones like Groovy, Jython, JavaFX and Scala. Java now includes such treats like invokedynamic opcode and the java.lang.invoke package, making it easier to build dynamic languages for the JVM. There’s already a line up of over 50 JVM-based languages, one of the most interesting ones being php.reboot, which aims to keep the philosophy of PHP but remove its shortcomings. And it also works for Android, too.
Java is mature, but not a language for old people
Java as a language has been the target of much criticism, whining and cursing. I say the language is not dying or Cobol’ish either, quite the contrary. When complaining about Java and recommending better alternatives, people often use strange comparisons. Some people seem to think that Java is still in version 1.4, written in Notepad and requires EJB2 to write a simple guestbook. It is then compared to a high level framework or even a CMS!
As a Java developer, this comparison doesn’t make any sense to me. It is wiser to compare how Java measures up to more intelligently-chosen contestants…How about pure Java vs pure PHP, Python or Ruby? Or comparing the Play! Framework vs Ruby on Rails? Or Spring MVC vs Zend Framework? When put in this light, I feel that Java does not seem like a “language for old people” anymore.
Java is verbose? Of course it is!
People say Java is so verbose, and it slows them down. Critics often refer to the strong static typing and lack of bleeding-edge features in the language. However, I believe this is actually deliberate and a good feature of Java.
Dynamic languages are popular when starting a new small project, but consider this – with the help of modern frameworks and proper tools (i.e. consider using an IDE instead of Notepad), creating a “Hello Guestbook” type of application in Java is a simple, 10-minute affair.
If you want to test that, try Spring Roo and use a stopwatch if needed. Now, let’s take a step outside the trivial CRUD matrix used by cool languages and frameworks in their marketing talk.
Imagine you’re building a system for a mobile carrier and want to allow clients to sign up on their website. You will have to collect a lot of data and possibly invoke various subsystems in the backend. Cool frameworks often break down the minute your program model does not match the user model anymore. For more, I can recommend this wonderful post on that topic by Joel Spolsky.
Java is strong with static typing
Strong static typing has many benefits. I love its simple visual appearance. I can glance at a piece of code and usually figure out immediately what’s going on. It’s like the visual feedback in English – the lgnaugae is so esay to raed taht the lettres can be miexd up isinde wrods, and it’s sitll redaalbe.
Some other benefits of the type system include strong IDE support. Dynamic languages will always be at a disadvantage here. Having a simple, no-nonsense language in a huge project with great IDE and tooling support is priceless. Nothing else comes even close IMHO.
Critics have a point that Java may lack some of the expressiveness when reading a file, transforming xml or iterating through a collection, but you can always create a sub method to handle common cases, or use FileUtils.readLines(). There is also a huge number of libraries available for Java that handle most of the “expressiveness shortcomings” of the language.
Java 7 saw some neat enhancements such as auto-closable resources, String support in switch statements and underscores in numeric literals (I urge you to read up on project Coin). Java 8 promises even more (most interesting part being closures).
The takeaway here is that the language is getting some fresh blood. However, the features will not be some experimental ideas which may or may not be around in two years, but proven and mature concepts. This does not mean the philosophy is mutually exclusive with having fun when programming. It isn’t.
A Fanboy Rests His Case
Is everything about pure Java perfect and justifiable? Of course not. And that is why there is Java 8 in the works. And Java 9. What I personally dislike most about Java is the not-so-smooth core API, and there is a debate whether this has actually more to do with the platform than the language. The core contains the evolution of API design spanning two decades, and modernizing it all will break backwards compatibility. Some parts are too abstract, some not abstract enough. Some bits are too fragmented. Some are just plain weird. Looking at the competition, the core API could do well with the unified communications API like .NET for example. Java 8, with the help of project Jigsaw, may change that.
So there you have it. Pure Java, used properly, is an awesome language. Even more so than Klingon. It will continue to improve and will not go away anytime soon. The effort should not be on replacing pure Java, but using it together with other JVM languages where it makes sense. But for my next Pet Clinic, I’ll stick with Java.
P.S… An Example of Java in Use
This article, like Java, is a bit verbose, so I’ll leave this example for any readers who want to continue.
Say you need to build a web application and you need control over the html output or http requests. Consider the stack of pure Java, Spring MVC and Hibernate. Yes, it’s an old combination, almost like a cliche, but it works beautifully. It has many benefits and little downsides, most of which can be eliminated with a little help from your tools.
Writing Java code is fast when using a modern IDE (Eclipse, Netbeans, IntelliJ). All of them have code completion and shortcuts that take much verbosity-related angst out of your day. Using relatively modern (i.e. less than 3 years old), versions of Spring and Hibernate, you don’t need to write five miles of xml to have red buttons with rounded corners (it has never been that bad but people love exaggerating). You can use annotations most of the time. Even when you need applicationContext.xml, using a Spring IDE plugin makes that a breeze. With JEE 6, you don’t even need a web.xml. Even if you have to use an older servlet spec, IDE will generate web.xml for you. It can generate a project layout and add servlets just like Grails’s command line console, but better.
The last bit you might complain about is the turnaround. Making a small change and seeing the result has always been fast in PHP, but not so much in Java. Again, tools are there to help you. Without tooting our own horn, JRebel, for example, will instantly reload classes in the running application regardless of your stack. Same goes for refreshing Spring and Hibernate configuration. It goes even further by mapping resources between the workspace and the deployed application. This makes your life easier when working with static resources too – you don’t need to copy jsp’s to the right place or run any build script to see the changes. Just press ctrl-s.
You get to keep all that’s good about Java. In short – you’ll have the best of both worlds.