Java Lives

What does the future of Java look like? Many say Java is reaching the end of its life, while others go so far as to say Java is dead.

Will Java become Cobol, an antique enterprise platform too entrenched to get rid of, but no longer relevant? Will Oracle’s takeover of Java prove to be the final nail in the Java coffin? Does it still make sense to build new-generation Web applications on Java? The answer is yes, fortunately, due to the rise in popularity of polyglot programming and the innovations it brings to the Java platform.

Java, one of the long-dominant platforms for building enterprise solutions, has been steadily evolving since its first release in 1996, with a new major version coming every one to two years. Each of the six major releases brought language and platform innovations that continued to make Java better — Java 7 seemed like it would be no exception.

However, Java 7 has been stuck in a quagmire for four years, with the Java community struggling to refine the implementations of two of its sub-projects, Project Jigsaw and Project Lambda. Project Jigsaw aims to bring modularity to Java’s core while Project Lambda would bring lambda expressions (“closures”) to Java. In early December 2010, Oracle announced that the Java Specification Requests (JSRs) for Java 7 have finally been approved for release, but Projects Jigsaw and Lambda will be delayed until Java 8. This news has disappointed many in the community, as these two features were seen as the major draw of Java 7.

Community-Driven

Many users see Java continuing to languish. However, the innovation needed to keep Java relevant will come from the broader Java ecosystem, and not from Oracle or the Java Community Process (JCP) that governs changes to Java.

The Java ecosystem, driven by the open source community, has always compensated for Java’s inadequacies. Developers don’t learn to build Java Web applications using plain old Servlets, but by using the Struts open source platform. Struts provided a Model View Controller framework that made it easier to develop maintainable Web applications than using the Java Servlet Specification.

Struts is only one example of many open source platforms that rose to prominence because the Java Specification did not serve the community’s needs. Spring compensated for the complex Enterprise Java Beans spec, Log4j for the Java Logging API, JodaTime for the Java Date/Time API, Hibernate for JDBC, and so on.

But frameworks and APIs can only provide so much innovation. The community is starting to turn to new programming language paradigms. There has been a rise in popularity of dynamic programming languages like Ruby. Ruby, coupled with Rails, its Web application framework, provides a fluent programming platform that allows developers to become productive sooner and write code faster. Functional programming languages like Scala have also gained interest as the community looks for ways to improve performance in light of the death of Moore’s Law. It is uncertain whether the Java programming language will be able to innovate fast enough to keep the attention of developers seeking the next challenge.

Java as a Platform

Java is traditionally viewed as just a programming language, but it is more than that. Java consists of three parts: the programming language, the virtual machine and the class libraries. Java, the programming language, compiles down to bytecode, which is the machine code that the Java Virtual Machine (JVM) reads and executes at runtime. Java developers can take advantage of reusable libraries and APIs packaged with the JVM, also in bytecode.

The assumption that you have to use the Java programming language in order to produce Java bytecode is not correct. The community has long been porting existing languages and creating new languages that compile down to bytecode and run on the JVM. In fact there are over 200 programming languages that can be used to write code that runs on a Java Virtual Machine.

Polyglot Programming

The idea that you can write code in a variety of languages on the same platform, each with its own set of advantages and disadvantages, is known as “polyglot programming.” This concept has been around for years. While not terribly revolutionary, applying this concept to the JVM is helping to keep the Java platform in the forefront of innovation.

New programming languages designed to run on the Java Virtual Machine are making some noise as well. Languages like Scala and Groovy are designed to solve a particular problem and provide language innovation that Java has been unable to do thus far. Scala, for instance, is a object-oriented functional language designed to run on the JVM. Scala is designed with a concise syntax that aims at providing increased application scalability. Scala is an example of a statically-typed language similar to Java. Statically typed languages free the JVM from conducting type evaluations at runtime, providing better performance.

Groovy is another JVM language that is dynamically typed and provides huge advantages when it comes to developer productivity. While dynamically typed languages tend to be slower at runtime, they excel at writing test code, authoring domain specific languages (DSL) and scripting. Groovy has also evolved a productivity platform akin to Ruby on Rails, called “Groovy on Grails,” which is helping it gain popularity in the enterprise development community.

In addition to new programming languages, ports of popular languages like Ruby have also made their way to the JVM. JRuby, the Ruby JVM port, allows Ruby developers to write Ruby on Rails applications and deploy them on the JVM. Like Groovy, Ruby is another dynamic language attempts to improve developer productivity.

The beauty in using a programming language other than Java on the JVM is that most languages have interoperability with Java. This means you could take a new service being built in your system, write it in Scala, and still have it call an existing pure Java service or component. The inverse is also true, allowing you to write a component in Scala and then invoke this service through plain old Java.

The idea of using a specific programming language to achieve a particular task should not seem foreign to developers. Web application developers have to be fluent in at least five programming languages in order to build a modern Web application — HTML for the Web content, CSS for styling and the layout of this content, Javascript if you want a rich user interface, SQL if your application is to be data-driven and, lastly, the programming language and platform you have selected for the middle-tier business logic.

This model makes perfect sense. CSS is good at defining the look and feel of a Web page, but you wouldn’t write business logic with it. SQL is great for accessing and updating relational data, but it is not good at generating a user interface. So why shouldn’t this paradigm apply to the programming languages with which we choose to build our core logic? Shouldn’t we be choosing a language that solves the problem best and not trying to force the one we know into the solution?

Operational Simplicity

Another huge advantage of the polyglot JVM is that from an operational perspective, managing change in the infrastructure is simple. Operations teams already know how to manage and deal with a Java Virtual Machine in a production environment. A polyglot JVM would allow a Scala on Lift or a Ruby on Rails application to be applied to production. Operations recognizes this as just another Java Web application.

Operational tools used for deployment or monitoring don’t need to change since the deployment architecture of the production software is exactly the same as a Java application. Organizations can gain advantages from the new programming languages without incurring additional costs of infrastructure changes.

Poly-Paradigm Programming

Where polyglot programming gets interesting is when you begin to weave these various languages together to write a single application. By taking advantage of the characteristics of various JVM languages, you can target languages for various features or layers in your architecture.

For instance, you would want to utilize a statically typed and/or functional language for a component in your application that has high performance requirements, and potentially use a fluent Domain Specific Language (DSL) written in a dynamically typed language to glue these components together. Dean Wampler from Aspect Research Associates calls this architecture “polyglot and poly-paradigm programming.”

Poly-paradigm programming refers to utilizing multiple modularity paradigms, such as Object-Oriented, Aspect-Oriented and Functional Programming, inside your application. Wampler goes on to demonstrate how poly-paradigm programming has been utilized by numerous application architectures such as Emacs (C code with Lisp scripts) and Unix/Linux (kernal plus shells) and even Google Android [Linux + libraries(C) + Java].

The most common argument against using dynamic languages running in the JVM is that they are slow. Although this might be true, they are getting faster all the time, and a major performance gain is expected in Java 7 with the InvokeDynamic JSR. This JSR makes changes that will take advantage of the JVM to improve the performance of dynamic languages running on the JVM. Hopefully this makes dynamic languages like JRuby and Groovy much more attractive solutions for the JVM.

Not only should Java developers learn another programming language (especially if you want to follow the advice of the Pragmatic Programmers3), Java developers should learn to take advantage of the right language (or modularity paradigm). Future Java developers should not only be filling their tool belts with frameworks and APIs, but also programming languages and modularity paradigms.

Clearly, this approach is not without added complexity, and there are various recommended approaches in the industry on how to evolve your application architecture into a polyglot nature. The best advice is to try and use new JVM languages in non-production code, such as build scripts and automated testing. This is not to say that these components aren’t critical, but you will have an easier time selling the idea if the production application isn’t immediately affected.

Java remains the premiere platform for building enterprise applications based on not only its solid foundation, but its language innovations that will allow developers to build faster, scalable systems quickly. By taking advantage of the flexibility that Java has always provided (portability) and adding a polyglot and poly-paradigm approach to software development, development teams can innovate inside an existing infrastructure with little or no changes to their infrastructure, making the sales pitch to management all the easier.

Java has evolved, and will continue to evolve, with this changing landscape due to the flexible nature of the Java platform. This is the advantage that makes Java relevant now and will keep it relevant for years to come.