The story of an heroic survival: the Java Platform

Have you ever watched the (for some – “infamous”) TV show Lost? Well, this post is not about shows, but we want to tell an amazing story of resilience, comparable to that we can find on the TV show characters: the story of the Java platform.

I will briefly go through history and recall on the evolution of the Java platform since (approximately) year 2000. My intention is to think aloud about where the Java platform comes from, where it is going and why this technology has been able to adapt and pass through time without becoming obsolete, something more than common when it comes down to computer languages.

java

Java code on screen

© Nicolas Pavlidis Source: Flickr

I’m not going to focus this post only in the historical facts. You can find plenty of information regarding them in the wikipedia. The idea is just mention some of the facts to think about them and try to find out how they have enhanced (or jeopardised) the platform as a whole.

Telling the facts

Context in which Java was born

It was 1997. C (and later C++) has been around for a while and was a mainstream programming language. However developers used to find some pitfalls when developing enterprise systems with it: the tedious, error prone boilerplate code to manage memory, drawbacks with multiple inheritance, a somewhat weak object oriented use due to the low level features the language allow you to implement, the need to compile each program for the specific target platform where it was meant to be run … Maintenance, evolution and development of new systems came most of the time out of budget.

Along with this the growth of the internet was near explosive. Large amount of businesses seem to be more and more interested in getting online. An amazingly large demand for new software was there. The need for some more productive, portable and easy to use tools was obvious at this point.

Java started as Sun Microsystem internal project in 1990. The smart people working on it saw (I guess) a great opportunity to start a new trend. Java was portable (the motto “write once, run anywhere” was one of the most repeated ones in the forums), object oriented, and provided an automatic management of memory. The productivity and reliability of the software developed with Java seemed to be a promise of success.

And it was; it didn’t take long that Java became the most popular and demanded technology in enterprise systems. A new actor had arrived to the scenario, and it was there to stay long. But, is it possible to stay long in a field where 6 months can mean a whole lifecycle? How could the Java platform survive time? Of course the answer is evolution. The Java platform has been able to grow and keep on giving valid solutions to new problems through time. A huge developers community have created tons of reusable and tested code that can be shared with everyone else. At the same time, the new features and improved performance of each new version has helped to this epic survival. Let’s try in this article to dig a little bit more and get some perspective on where is Java moving towards to (based on how it moved in the past).

Java 2 as an starting point

Java 2 came to us in the very first years of the current century. I’m not going to get into prior versions because they didn’t really added as much relevant value as this. It was Java 2 (version 1.2) what really started to make Java a more interesting general purpose language.

Java 2 was launch on December 8, 1998. This version first separated the platform in three big branches: J2SE (Java 2 Platform, Standard Edition), J2EE (Java 2 Platform, Enterprise Edition) and J2ME (Java 2 Platform, Micro Edition). This version represents a major milestone in Java history. In my developer experience I think these are the most relevant improvements:

  • It tripled the size of the platform in term of number of classes. Significant additions have been the Swing API and the Collections framework. The latest is the foundations of traditional data structures implementation for the Java platform, and is nowadays used on a daily basis by every Java developer. The Swing API brought much more rich and powerful desktop programming support.
  • It enhanced performance significantly, including a JIT compiler for the first time and (about one year after the initial release) the HotSpot JVM. Garbage collection and general performance started to become competitive even when compared to C++ (given the benefits of automatic memory management and multi platform design).
  • The Java plugin was first included, allowing the execution of Java programs inside a web browser. The multi platform feature of Java fitted quite well with that, due to the fact that the web is accessed concurrently by all kinds of operative systems and hardware architectures (the same program can be run in all of the without any platform specific code).

For all those reasons we can consider Java 2 as a major milestone in the Java story. It can be considered the point from which the Java platform can be considered a matured and cutting edge technology.

Java 4 as a proper evolution

As time flies more experience, patterns and best practices in the object oriented programming paradigm become mainstream inside the developers community. This fact represents a major challenge for the Java platform, that has to adapt to those changes to stay on stage and avoid being replaced for a more sophisticated evolution. One of the reasons of the long term success (in terms of the number of real production projects developed for many years in a row) of the Java platform is that it has been able to adapt to upcoming changes and has evolved offering proper solutions to challenges that arise. Java 4 is an excellent example of such adaptation. These are the new features I think are worth mentioning:

  • It included the assert keyword. It can be seen as a minor and insignificant feature, but behind it relies a very significant philosophical change: the language now supports preconditions verification at syntax level. This let us see a TDD “frame of mind” in this version design.
  • Regular expressions support. This allow us to solve new problems with Java and start to play in the field of other languages (i.e. Perl).
  • Exception chaining, now allow us to implement the fault barrier pattern in our Java applications. Although before this point we could code the feature on our own, including it in the standard API made this best practice reusable, portable between different projects and best known by developers.
  • Builtin XML and XSLT processing. This allow us to use this ubiquitous items in our Java applications without any third party dependency, although the low level approach and not obvious use of the API made this intent fail in the end.

There are other relevant enhancements in this versions that I’m not going to mention here, due to the fact that I didn’t find them as relevant as the previous ones.

Java 5, or how the proper adaption goes on

If Java 4 represents a success point in the Java platform career, Java 5 definitely stablished the foundations of subsequent evolution changes. The Java team seems to be working hard to make Java survive the extremely tough demands of the growing IT market. The first release of this version takes place on September 30, 2004. This version includes, among drastic performance improvements (related mainly to reflection operations) some syntax enhancements on top of which a lot of new state of the art designs have been implemented:

  • Generics: The strong typing nature of Java has been very controversial. It’s a matter of taste and finding a good balance between flexibility and easy coding and more robust code and much more efficient refactoring process. Anyway generics represent a step ahead in the strong typing approach, allowing us to verify at compile time types that can belong to any class. This constraint only applies at compile time, being managed as an Object type at runtime.
  • Annotations. This feature represents a very major improvement that has lead to many state of the art architectural solutions. It allow us to define metadata within our code, that can be used both at compile run time to modify the behaviour of our system. Only time will tell how far annotations have carried us.
  • Autoboxing. Now all the boilerplate conversion between primitives and objects is automatically managed by the compiler. One of the arguments against having primitive types in Java (and making the language a not pure object oriented one) get significantly reduced by this feature. Conversion between primitives and wrapper objects is managed not only automagically but also efficiently, due to the improvements in garbage collection algorithms this version includes, that makes small the problem of large numbers of short living objects being created at runtime.
  • Enumerations. A not very clean workaround had been needed to implement some discrete lists of values. Now we have a language construct that allow us not just to implement this in a more concise and elegant way, but also to add behaviour to those discrete values in an object oriented fashion. No more int bit masks and int constant values will be needed in the future, allowing us to write a much more clean code implementation of those discrete values.
  • Varargs. Now we can simplify and take a more clean code approach when passing arguments to a constructors and methods. An elegant null enabled way of passing arbitrary number of arguments of the same type is enabled.
  • Static import. Now we can use static functions in an import module fashion, as i.e. we do in Python through the import keyword.
  • Enhanced for-each loop. One of the major syntactical improvements is the inclusion of a new for loop, much more straight forward than before. Clean code style keeps on being much better supported with this new feature. The syntax of the Java language starts to evolve towards a more concise and clear style.

There are some more API and memory management improvements, but not as important as the previous items what it comes to daily programmer work.

One important drawback of this highly improved version of the platform is that the byte code specification change, so code compiled for Java 5 cannot be executed in a Java 4 (or previous) JVM. Many APIs require Java 5 or later to work due to this fact, which represents a limitation to upgrade legacy systems based on previous versions of Java.

Java 6, trying to hide virtual machine work in performance

This version reach a much better general performance than before. There are no significant API or syntax changes, at least regarding everyday programmer work. Synchronised code now executes dramatically faster than it did in previous versions. Among this Java 6 includes some interesting API additions:

  • Scripting language support. Now we can integrate our Java programs with scripting languages through a new API.
  • Implementation of the JAX-RS specification. This can be seen as a major step towards getting Java into the rest APIs ecosystem. Once again, the strategic vision of the people in charge saves Java from dead evolving the platform to fulfil the arising market requirements.
  • Java compiler API. Now we can invoke a Java compiler programatically. This allow us to write code that generates Java code, compiles and execute it at runtime (splitting hairs, we could say).

Other less relevant (for a plain old Java developer) improvements have been included in this version. Please refer to Wikipedia for more information on those.

Java 7, or the beginning of a new age

I don’t want to be controversial, but since Oracle bought Sun and became responsible of the Java platform the path followed up from this point has become (in my opinion) less clear. Java 7 introduces some interesting new language evolution (i.e. minor syntactical enhancements like allowing the use of String in Switch statements, or more deep ones like the support of dynamic languages). However this can be seen as an evolution, not a revolution, and the final purpose of theses changes remains unclear for many of us. After the first release of this version a major bug in the Java compiler caused severe issues in some loop statements, so many people hesitated to migrate to Java 7. At this point a more clear strategy is needed to face the next needed evolution of the platform to succeed in upcoming technological challenges.

Java 8; what’s next?

Java 8 is expected on September 2013. Some of the features initially planned for version 7 have been postponed to this upcoming version. There are some quite interesting and promising features in it, some of those inspired by functional programming paradigm. At the time of this writing the Java 8 specification is merely a proposal, but after having a look at it we can assure that the Java platform is getting again into the proper evolution path that have made it a long term mainstream enterprise solution. Let’s review some of those interesting features:

  • Language level support for closures, also called lambda expressions. This has been a highly demanded feature for the Java language for years. Prior to Java 8 we could implement closures in several ways (see this post for further reference), but it’s in the end a workaround to circumvent the lack of a basic construct in the Java language.
  • New date and time API, and tight integration with JavaFX.
  • Higher-order functions, or methods that accept other method as a parameter. We can use this feature to perform function chaining (calling methods passing around other methods as parameters and then invoking methods on the returned object that can accept other methods as parameters as well).
  • Parallel collections. This is a built-in mechanism to perform heavy computations on data structures in multi-core processors in an efficient way.
  • Virtually extension methods: a way of getting some crosscutting, boilerplate code (like logging) out of our logic through somewhat friendly multiple inheritance mechanism.

Getting to some conclusions over the facts

It’s quite clear that Java has been able to evolve and adapt properly to a fast changing environment. That is one of the reason of it’s resilience despite the time passed. On the other hand, a huge and very active developers community had helped the process with tons of open source APIs to solve the arising needs of the market, allowing the language to survive as a very robust and productive platform and making easy to stay focused in the evolution of the platform itself (corner cases and very concrete needs are addressed by third party APIs most of the time).

The lack of a clear strategy in Java 7 after Oracle showing up looked somewhat threatening. Java 8 promises to get back the platform to the evolutionary approach. On top of that the growing number of other languages compiled to byte codes and executed in the JVM give us even more insight on what lies ahead. It seems that the Java platform has more road to run. The variety of tools, APIs, languages, among the extremely mature and ubiquitous presence of Java in the IT industry points out that we have now (inside a JVM) a much more complete set of resources to fulfil a large range of technical requirements. Even if Java comes to an end in its rapid and successful evolution (something that it’s not likely to happen), the surrounding new tools would come to cover the gap and to keep on giving the market real good solutions to its demands.

So, what do you think? Do you agree with this view? Do you think there’s more room for the Java Platform in near future or do you see other technology as a replacement that will lead Java to the graveyard of history? A second post on this topic is likely to elaborate more on those questions and possible answers; please help us with your comments in order to give you a better insight on this topic in near future.

Foto de mnavas

Mariano Navas es un desarrollador especializado en plataforma Java. Apasionado de la tecnología y activo practicante del TDD dedica parte de su tiempo a investigar nuevas herramientas, lenguajes y mejores formas de hacer las cosas. En activo como desarrollador desde el año 2000 trabaja actualmente en equipos bajo disciplina ágil basada en Scrum.

See all Mariano Navas activity

Escribe un comentario