The continuing Java story (Part 1)

Publish date:

I have been a Java programmer for almost my entire professional life. I started using the Java language back in 2000 and I am still using it today. Maybe not as frequent as I did back in 2000 but Java remains one of my “core businesses”. For as long as I have been using Java […]

I have been a Java programmer for almost my entire professional life. I started using the Java language back in 2000 and I am still using it today. Maybe not as frequent as I did back in 2000 but Java remains one of my “core businesses”.

For as long as I have been using Java I cannot remember similar times where the face of Java was changing so much as it is today. These are really interesting times. The acquisition of Sun by Oracle, VMWare SpringSource and Google partnership, IBM and Oracle joining forces on OpenJDK, Oracle suing Google over Java Pattents and Apple deprecating their JVM on OSX. Just a couple of announcements, which I believe, that show us Java is changing.

But when things are changing the question rises how is it changing? Where are we heading to? How should we interpret all these recent announcements? These questions are hard to answer, not to mention the question when will it happen. Nevertheless it is also fun to think about it so let me give it a try. Here is my view on the continuing Java story.

Java SE

When we talk about Java we always have to be careful about what we mean by “Java”. Java is sometimes referred to as just the language itself, sometimes a platform and sometimes even considered an entire industry or ecosystem. Different definitions that, given the context the term is used in, are often all valid too.

Java is indeed a programming language. It is very popular language used in many applications and is a powerful object oriented language.

On its own however, the Java language does not do very much. You need a compiler to compile your Java code to byte-code, a virtual machine to execute the byte-code and a couple of standard API’s to create applications. The specifications of how a Java compiler, the virtual machine and a whole bunch of standard API’s should work are bundled into the Java Standard Edition or Java SE specifications.

Java SE is the foundation for almost any desktop or server application written in Java. There are multiple implementations of the specifications provided by:
• Oracle with the former Sun JVM and former BEA JVM called JRockit
• IBM with their IBM JVM including ones for IBM’s Z/OS and AIX
• HP with their JVM for HP-UX
• And the open source community with Apache Harmony and OpenJDK.
Combined these implementations provide Java SE for multiple operating systems and architectures (Windows, Unix, Intel x86, SPARC, 32-bit, 64-bit, etc.).

Thanks to this approach of having one specification and multiple implementations, applications written in the Java language can be written once and run anywhere. While this approach has proven to be successful it also creates a field of tension. The approach has not been in the interest of major desktop operating system software vendors exemplified by a well-known company called Microsoft.

Microsoft chose to go a different path with their .NET framework. An approach based on writing applications in any language but on one operating system: Microsoft Windows. One of the reasons for this is of course easy to see: money. It is not in Microsoft’s best interest to provide customers a capability to pick up their applications and leave Microsoft’s money making Windows Operating System in favor of e.g. a Unix flavored Operating System.

Microsoft will do everything in its power to protect its Windows hegemony. However, this raises the question why vendors such as Oracle, IBM, HP and the open source community still develop and support Java SE implementations (paying expensive license fees to Oracle). The answer is simple: Java’s success is primarily in server applications. With so many investments in Java based server software especially the above mentioned vendors couldn’t afford to abandon ship. They have to protect their very profitable server hardware markets.

Apple deprecating Java for OSX

Given the above perspective it should not be hard to understand Apple’s recent announcement to deprecate their Java SE implementation on their desktop Operating System OSX. This announcement was of course disappointing and a clear sign that Apple sees Objective C as their core foundation for OSX and iPhone development (much like Microsoft with .NET).

However, it is important to realize that Java SE is by no means unsuccessful on the desktop. Thanks to initiatives such as the Eclipse Rich Client Project, improved versions of Swing and SWT some great Java SE based desktop applications do exist. How does Java SE deal with that?

Let’s go back into history: Microsoft did work on a Java SE implementation including a Microsoft Java Virtual Machine about ten years ago. But with the Java SE specification written with compatibility with multiple operating systems in mind Java applications could not leverage all the features Windows provided (only the common ones).

Microsoft decided to implement a lot of Windows specific features in their own implementation, which Sun (back then the owner of Java) did not like. Microsoft violated some license, IP and patent restrictions so Sun sued Microsoft and won the lawsuit. Microsoft stopped their Java implementation and Sun implemented Java SE for Windows themselves. For the success of Java SE Sun could not afford to lose support for Windows either.

It is very likely that a similar scenario will unfold with Apple. Especially because an important step took place between ten years ago and now: the Java SE implementation from Sun got open sourced in a project called the OpenJDK. I will not be surprised if this project will come up with a Java SE implementation for OSX. Reasons for it:
• OpenJDK already provides implementations for operating systems based on the same foundation as OSX. It should not be too hard to create an OSX version.
• It saves Apple money on developing and supporting their own implementation.
• Apple had a hard time keeping their implementation up-to-date with new versions of specifications. OpenJDK is by default up-to-date.
• IBM has joined forces with Oracle on OpenJDK making it well supported.

IBM and Oracle joining forces on OpenJDK

In a recent announcement made by Oracle and IBM both companies made it clear they will work together on the OpenJDK project. In my view this is one of the most important announcements in recent Java history.

Oracle has not provided complete Java SE support to the Apache Software Foundation. Therefore Apache Harmony is no longer a compliant Java SE implementation. Apache Harmony was backed by IBM. IBM has therefore decided to move their support to OpenJDK which was already backed by Oracle. IBM and Oracle decided to join forces.

While IBM and Oracle will remain fierce competitors on other parts of Java (which I will discuss later on) I believe this partnership on Java SE does secure corporate customer investments in Java on the one hand and IBM’s and Oracle’s own investments in Java on the other. And this might also be a reason for expecting an OSX JVM as well.

Oracle acquiring Sun Microsystems

The announcement that Oracle would buy Sun and the completion of the acquisition this year has been debated heavily. The most important consequence: Oracle basically now owns Java. Some see this as a thread and some consider it a benefit. The thread being Oracle making Java more and more proprietary and the benefit being that Oracle has much more resources to invest in moving Java more quickly forward. I tend to see it as a benefit.

What a lot of people don’t realize is that the past couple of years of Java have been years of stalemate, lack of innovation and lost opportunities. Turning that around has to be ‘job one’ if Oracle is going to see a return on its acquisition. Also the release cycle of new versions of Java SE (and also other editions) was to slow and unreliable. Oracle is much more capable of tackling this issue than Sun ever was.

Oracle suing Google over Java Patents

It is going to be very interesting where this lawsuit will be heading and what the consequences will be. First and above all this is about money. If Google is using code that violates patents that are owned by Oracle then Google is leveraging IP it has to pay for it or don’t use it at all.

If Google will be found guilty it is going to be interesting to see if they will stick with Java (which I think they will because just like IBM they have invested heavily in it) or make a shift to Google’s, 2 year old, new language called “Go” (which in my opinion would be a bad thing). If Google is not found guilty Google will continue to use and develop their implementation of Java, which would basically be a fork (which in my opinion is neither good or bad).

I will definitely follow this lawsuit in the next coming months and see what Google will be doing.

To sum things up

So in my opinion the future of Java SE as a foundation for server and desktop applications looks bright. Why? Simply put: there are too many companies and customers having a to large stake in Java SE for the future not to look bright.

The language Java still is and will remain very popular. The acquisition of Sun by Oracle has resulted in more focus and faster time to market of new features in the language (as shown by the new release schedule). However, it is going to be very interesting to see where the lawsuit with Google and Oracle is heading.

Next part: Java EE

As mentioned Java is a language but sometimes also referred to as a platform. On top of Java SE there is also Java EE. A popular set of specifications used for implementing Enterprise (Web) applications.

While the future for SE looks bright the future for EE looks diverse. The same companies mentioned above are in fierce battle in creating solutions on top of Java EE.

Bart Kooijman , Java architect, Security specialist

Related Posts


2022 Key Trends in Healthcare

Date icon January 21, 2022

Healthcare is on the move, transforming itself from a largely reactive, resource intensive...


Leveraging small tech and nanoservices to drive a frictionless supply chain

Jörg Junghanns
Date icon January 21, 2022

Leveraging macro-, micro-, and nanoservices drives frictionless, digital transformation of...