There's no two ways about it -- this article is ambitious. In it, I set out to define the perfect technology platform and see how the Java platform measures up. Then the article flicks into solution mode, proposing both tactical and strategic changes to the Java platform to address any identified weak points.
Setting the stage
First, why should you care whether Java is a perfect programming platform? It works well enough at the moment, doesn't it? In short, no. I believe that by the end of this article I will have showcased well-defined weaknesses in the Java platform that can be put right. Addressing these weaknesses will result in a platform that is easier (read faster) and more intuitive to develop against, takes advantage of deployment platform strengths as appropriate, and in short becomes the de facto technology standard across all industry verticals and market segments -- a universal language for programmers.
What is a perfect technology platform?
I should define my vision of the perfect technology platform before I go much further. Simply put, I believe the perfect technology platform is a software system programmable by both novice and advanced developers, admits the creation of both simple and advanced applications, is available on all hardware platforms, and at runtime, operates in native or close to native mode.
Defining this article's scope
With an article like this, it's important to set the scope right away. First, this article does not consider any technology platform other than Java. Is that being too blinkered? I don't think so. The scope I've set for the article is simply to look at the Java platform in isolation, not as part of a competitive lineup. I'm interested in creating constructive criticism for the Java platform with a view to strengthening that platform. Ideally, avid supporters of other technology platforms will perform and publish similar exercises for their preferred technologies.
In addition, I will make the assumption up front that the core Java programming language is already the best programming language to build any technology platform around. I have no issues with the extensions planned for Java 2 Platform, Standard Edition (J2SE) 1.5, although I do feel that some changes are simply "keeping up with the Joneses" modifications aimed squarely at the C# language. The stability of the language specification itself over the last eight years bears testimony to its strong initial design. New features implemented in J2SE 1.5 such as autoboxing, enumerations and static imports are widely regarded in the development community as syntactic sugar, although the availability of parameterized collections is a noteworthy addition to the core specification.
Making this assumption also removes any discussion over the fact that Java is inherently an object-oriented programming language with a strong C and C++ heritage, and that in my opinion, this is the right core programming language around which to base a technology platform for the future. Technically, I could examine other object-oriented languages from Eiffel to Smalltalk, and expanding the dragnet further, why not see if fundamentally different languages such as functional programming languages like LISP or Haskell or declarative programming languages like SQL could form the semantic core of the perfect technology platform? Because that debate my dear friends would require a book in its own right! But make no mistake: If a major player like Sun Microsystems Inc., Hewlett-Packard Co., or Microsoft Corp. decided to take one of those languages and base the next technology platform around it, it would stand a reasonable chance of success; support and commitment is everything to nurturing a technology through its infancy.
I'm interested in analyzing Java as a platform, however; and in that context, the Java language actually plays a smaller role than the overall platform itself.
Having set the scope of the analysis, I now move on to define the most important features of any platform.
Perfect technology platform feature analysis
This list can either be very long and detailed or short and sweet. I'm going the short and sweet route. Interested readers can note that the very long and detailed list has a lot of words that end with "ility," also known as the ility matrix.
In my opinion, any potential candidate for the perfect technology platform must:
- Be easy to develop against, yet provide multiple access levels
- Be stable
- Be easy to deploy, in particular to client platforms; and when deployed operate in native mode
- Have adequate performance and scalability as required
- Have industry buy-in and be open standards based at least if not in name, then in spirit
How Java measures up
Now that I've defined a set number of characteristics, let's see how Java shapes up when compared to this list.
To be brutally honest, Java is not particularly easy to develop for. Simple projects are fine, but as projects grow in complexity, infrastructural issues cause more and more problems. A good example is working with Java 2 Platform, Enterprise Edition (J2EE) application servers. Proportionally, I spend more time tracking down issues such as classloading problems than debugging actual business logic coded in Java. In addition, the disquiet felt by programmers around Enterprise JavaBeans (EJB) in general is a clear warning sign that EJB may be simply too complex and has not taken root as the de facto persistence or business logic solution for J2EE applications. This point also speaks to tool support for the Java platform, as opposed to any weakness in Java technology itself. Bluntly speaking, Microsoft leads the way with Visual Studio, and Java needs to catch up.
My earlier reference to multiple access levels means allowing developers/users to work with Java technology as befits their level of technical expertise. Hard-core developers can use emacs/vi plus a command-line debugger to develop and deploy Java-based systems, while business analysts or even end users should be able to access and modify systems within reason using WYSIWYG tools.
Java is not particularly easy to deploy either. Sure, applet and Java Web Start technology help to some degree, but both approaches have their drawbacks -- not least of which is requiring an up-to-date Java Runtime Environment (JRE) to be already deployed on the target client machine.
The Java platform is quite stable. I can't remember the last time a JVM crashed on me because of a JVM or core library bug. I'd rather build a business-critical application on the J2EE platform than on .Net.
Java's performance and scalability on the server side is more than adequate when applications are designed correctly. Swing performance on the client is just about adequate but still falls short of native speed. For resource-constrained devices such as smart phones, building applications in Java rather than using a native toolkit directly is a luxury rather than a pragmatic development decision. The extra layer imposed by the Mobile Information Device Profile (MIDP) on resource-constrained devices creates a notable performance lag over native applications, particularly at application launch time.
Clearly, Java has massive industry support from all major software vendors with the notable exception of Microsoft. Players such as IBM, HP and Oracle have aligned their own technology strategies with the Java platform, which is good news for all concerned. The more support for Java the better; it means that corporations have significant time and money invested and will be keen to see Java continue to grow both mind share and market share in the mobile device, PC and server segments.
The good
What are Java's strengths at the moment?
Platform support: the J2SDK is available on all commonly used operating systems/hardware combinations across all industry verticals, from financial services to entertainment, scientific research and home computers.
A clear separation between the Java language specification and the Java runtime specification has allowed researchers to implement compilers that generate mappings from programming languages other than Java to Java byte code -- ready for execution by any compliant VM. The importance of this flexibility will become apparent when I mention strategic changes later on.
An extremely active developer community seems to churn out new frameworks, libraries and components by the hour. Java probably has one of the most vibrant development communities in the world.
Java is the most mature and stable platform for enterprise computing available today. Microsoft is still spinning .Net, and it might eventually be as good or better than Java (but only on the Windows platform); right now, it's not. Also, a new front has opened up in the war for technology supremacy -- on mobile devices. Despite the additional overhead incurred by Java on resource-constrained devices, Java is definitely the current leading contender in this space.
Java has strong support in academia. Java has become the first programming language that most computer science majors see when they go to college or university to study computer science. In other words, most university programs create computer programmers who count Java as one of their strongest languages. This ready pool of programmers has two knock-on effects: postgraduate research to MS and PhD levels is more and more often completed using Java which lends additional weight to the platform; and just as importantly, companies across all industries know there's no shortage of Java programmers available to staff software development projects, bolstering Java's image as an industry-oriented platform.
The bad
Now for the major weaknesses:
A developer community that creates new frameworks and libraries almost hourly is both a strength and a weakness. Instead of coming together to promote one best-of-breed library, different developers and organizations end up competing against one another -- often with almost identical feature sets. Users (developers in this case) get caught up in the arms race and become thoroughly confused. Even Sun engages in this activity. A prime example is the current Java Data Objects (JDO)-EJB debate (debacle?). Surely one should go and one should become/remain the incumbent. The current state of affairs is simply sending the Java community confusing signals. For example, if you're a J2EE architect, are you 100% comfortable that the ideal J2EE architecture you hold in your head (or your heart!) is the best available solution at the present time? I am not, but my ideal J2EE architecture is the best pragmatic solution at the moment.
An overly complicated technology "story" around Java. Is there anyone who knows all of Java's capabilities from server to PDA? There was a time was when I could keep up via an hour or two of reading a week. Not anymore. This complexity is perhaps unavoidable given the sheer strength and depth of Java as it vies to become all things to all people, but at the same time it threatens to alienate developers and limit the take-up of new and worthwhile developments to the platform.
The classic Sun attitude is, "Hey, we've given you this cool core technology. Now you build the development tools and implementations to make it production strength." Jini/JavaSpaces is an example that springs to mind. This technology was doomed to remain an interesting academic research tool by Sun's own attitude toward it, not through any technological weaknesses. In fact, the JavaSpaces event-based programming model is probably one of the simplest and most powerful available today.
Poor integration with the most widely distributed client platform of all: the Microsoft Windows suite. Unless Java gets its act together on this platform, it will retain a permanent disadvantage in the corporate market when compared to the incumbent in this space: Microsoft technologies. In fact, Java as a thick-client technology will lose even more ground as .Net picks up momentum -- as it undoubtedly will.
I don't think Sun makes enough money from Java. This is potentially the most disturbing weakness of all. What motivation does Sun have to continue to invest in the Java platform? Personally, I would like to see Sun garner greater monetary rewards for its role as "benevolent dictator" presiding over Java's future not from developers or end users but from companies like BEA Systems Inc., IBM, Hewlett-Packard Co., et al. I worry that in any shake-up at Sun initiatives such as Java could suffer. A healthy, strong Sun Microsystems bodes well for Java; a shaken, sickly Sun Microsystems must mean change in how Java is developed and governed, and there's no guarantee in changes for the better.
Addressing identified weak points
Clearly, I believe the Java platform has weak points that must and can be addressed. The following sections detail these changes and contain both tactical and strategic proposals.
Expand what ships with J2SE