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 (see Resources) 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, Hewlett-Packard, or Microsoft 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 (see below for more details)
- 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 (see my past article, "To EJB, Or Not To EJB?") 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.
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.
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 percent 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, IBM, HP, 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. Figure 1 below addresses the issue of who should own/be responsible for what in the Java technology platform.
Figure 1 shows a high-level schematic depicting an idealized Java technology platform. The color scheme is important as it demarcates components that should be truly community-owned (green) and those that Sun Microsystems/platform partners should retain exclusive control over (orange).
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
Hands up all those who use Ant as their build tool of choice. Hands up all those who prefer the Jikes compiler over the bundled javac compiler for efficiency reasons, particularly on larger developments. Wouldn't it be great if J2SE contained Ant? What about XDoclet? The point can be argued that these tools should ship as part of an IDE and not as part of the core SDK, and I'm happy with that. But I believe that Sun should put in place an initiative to gather these value-added tools in one package that can be installed on top of an existing SDK.
This is a thorny issue. I already touched upon it when I mentioned replacing the current javac with Jikes, but here I expand this concept to become a general rule of thumb for the Java platform. Simply put, the Java platform needs to become a technocracy, i.e., an environment where the best implementations rise to the top and become de facto standards because of technical reasons, not political or commercial reasons. When two strong implementations of a specification or tool exist, they should be merged. An outstanding example of this is the current NetBeans-Eclipse struggle. There should be only one winner here.
I use Eclipse, but why can't we have a best-of-breed merger between the two and focus all our resources on the combined tool instead of allowing two Java IDE projects to compete against each other? The Standard Widget Toolkit (SWT) certainly has performance lessons to teach to Swing/Abstract Window Toolkit (AWT). For starters, NetBeans has better support for JavaServer Pages (JSP) development—developers should be able to have their cake and eat it too.
Sun: Deliver a consistent technology message!
Think about persistence frameworks: EJB—both BMP and CMP, JDO, and Hibernate. What about Struts and WebWork in the Web framework space? This depth of choice is wonderful and is often seized upon as a sign of strength by the Java community. But this explosion of options brings with it design and implementation headaches. As a system designer, I welcome choice but only within reason. For example, what is the ideal J2EE architecture? The easy answer is to say "it depends on the requirements," but that is a cop-out. The three major tiers in an enterprise application— presentation, business logic, and persistence—should be addressable by one, maybe two candidates each.
Companies feel the same way about application servers. I appreciate multiple vendors that support the J2EE 1.3 specification, but internally I have a preferred implementation. Choosing one server cuts down on development and testing complexity and also allows support teams to manage call volumes more easily. If I encounter a showstopping bug with my implementation or the vendor goes bust, then the J2EE specification acts like a technology insurance policy giving me the option to select a new preferred server.
Creators of new specifications and implementations should be compelled to create a blueprint application that shows exactly where their new subsystem fits into the greater Java taxonomy. Hell, before anything gets created, incontrovertible proof should be produced that an existing subsystem, API, or specification could not be extended to provide the required functionality.
A new Java mantra: Expose a simpler everything
The person who articulated what I have in mind here is James Gosling at the 2002 JavaOne conference. He talked about the Swing API being like a Boeing 747 cockpit—tons and tons of configurable behavior but intimidating to new and experienced developers alike.
Taking his analogy a bit further, the powers that be at Sun, Java Specification Request (JSR) leads, and even open source project leaders must be increasingly aware of the pushback against overly complex software, be it a specific API, installation of a software module, shipped documentation, or something else.
The Java world needs to adopt the KISS mantra: Keep It Simple, Silly!
Embrace Windows as the client deployment platform of choice
This may well be a controversial point! Simply put, Java doesn't exactly rock anyone's world on Windows, does it? In fact, for me, the most compelling aspect of the Eclipse project's SWT is its native look-and-feel and performance on Windows, coupled with tight integration to the clipboard and OLE mechanism on the Windows platform.
Don't get me wrong. I'm not saying that the Java platform should support the Windows platform to the detriment of other platforms such as Mac or Linux, but Windows support needs to improve dramatically. User-friendly initiatives like www.java.com are a step in the right direction (albeit a very glitzy step), but there's still a lot to be done.
Position the Java platform as a blank canvas for other technologies
I've already touched on the separation between the semantic representation of Java as a programming language and the actual runtime representation as byte codes executed by a compliant JVM. This point builds on that and calls for Java to become all things to all developers. Mappings can be developed (and indeed have been—see Resources for a list) for multiple languages to the JVM. This is a transitionary measure. Ideally I would like to see the core Java language remaining preeminent, with perhaps a scripting language also gaining prominence to facilitate rapid prototyping and glue code.
The Java Community Process (JCP) is one of the key mechanisms that allows Sun to act as a benevolent dictator guiding the progression of the Java platform and other parties (both commercial and individual) to protect their interests by participating in the process of adding new functionality to the Java platform.
However, certain key specifications that will have a huge impact on J2ME, J2SE, and J2EE are being held up in the JCP process due to commercial considerations, political maneuvering by vendors, and plain ol' red tape.
Each JSR specification should have two versions: the version we have now and a stripped down version with an absolute maximum of 50 pages for developers who actually have to use and understand the specification as an end user.
Figure 2 lists Java's current weaknesses along with proposed solutions.
The final grade
So then, what does Java's report card say at present? It would have to be that hackneyed phrase "tries hard, could do better." Java has the potential to be a rip-roaring success on every target platform throughout the computing world, from PDA to server. But Java can really only lay claim to the server as an area where it currently dominates. Issues such as memory footprint, installation barriers, and performance have prevented Java from attaining the same success on the client—and winning that battle or at least contesting it strongly is crucial.
Despite this current state of affairs, I do believe Java has the potential to become the basis for a perfect technology platform. Perfect in that through clear separation of concerns, low barriers of entry for developers, ubiquitous hardware, operating system support, and possibly even multiple language support, the Java platform can become all things to all levels of developer. And through intelligent and dedicated support to all client platforms, Java applications can achieve the same level of success on the PC and mobile device as they currently enjoy on the server.
Learn more about this topic
- Humphrey Sheil's "To EJB, Or Not To EJB?" (JavaWorld, December 2001) describes the points used to decide whether EJB technology should be used on a particular project
- The Eiffel programming language/platform, the end result of Bertrand Meyer's one-man assault on the perfect technology platform
- Haskell, the unsung hero of programming languages?
- Check out the JSR for J2SE 1.5
- You can find a fairly definitive list of programming languages that target the JVM other than Java itself here
- Visit the Java 2 Platform, Standard Edition (J2SE) section of JavaWorld's Topical Index
- Browse the Enterprise JavaBeans (EJB) section of JavaWorld's Topical Index
- Visit the Java 2 Platform, Enterprise Edition (J2EE) section of JavaWorld's Topical Index
- Browse the Micro Java section of JavaWorld's Topical Index
- See the Java Community Process (JCP) section of JavaWorld's Topical Index
- Visit the JavaWorld Forum
- Sign up for JavaWorld's free weekly Enterprise Java email newsletter