A Quarter of a Century of Java

February 12th, 1996.  This is a significant date for me personally since it was the day I started work at Sun Microsystems as a Solaris Systems Engineer.  It was also two weeks and six days after the release of the Java Development Kit (JDK 1.0).

Of course, the origins of Java go further back than this; James Gosling and others started work on a new programming language in 1991, and it was the May 23rd 1995 when Java was officially announced to the world.

So here we are, twenty-five years after the official launch of Java.  I thought it would be interesting to share some of my memories of how Java has changed over that time.

Initially, when I first heard about Java, I was rather dismissive.  OK, I thought, a new programming language and this odd thing called HotJava, which was a browser written in Java.

Since I’d only been using the world-wide-web for a bit over a year, I was less than excited.  My focus (at that time) was on UNIX, writing low-level code for (if I remember rightly) a diskless version for Telco applications.  All done in C.

When I joined Sun, it was still to do things in the UNIX space, only now it was Solaris.

Then one day in early 1997, someone asked me to do something that changed not just my career but, really, the rest of my life.  They asked me if I could give a presentation on Java…

I still have the presentation I gave; it’s 64 slides long.  The first 42 slides deal with language syntax, then 18 on AWT and 4 to wrap things up.  I was amused that on one of my slides, I recommended using the Vector class for linked lists. Err, what?  I also, apparently, gave a demonstration of Java Workshop.

That really set my course for the next 23 years.  Having done a number of presentations and read a book on Java, I decided it would be useful to gain some real-world experience of its use.  Back in the late 90s it was easy to move around in Sun, so I joined a team developing internal business apps in Java and learnt a lot; both how to use Java well and how to use it incredibly badly.

After that, I joined the JavaSoft part of Sun as a performance engineer working with ISVs before making a move to the wonderfully named, Java Evangelism team at the beginning of 2001.  Since then, I’ve been lucky enough to present a pretty wide variety of Java-related topics in 58 countries covering six continents.

One of the most incredible things about the way Java has flourished as a development platform is through the community.  In particular, I’ve always been amazed by the passion shown by Java User Groups (JUGs), and I’ve been fortunate enough to visit many of these over the years.  Conferences like Devoxx, Jfokus, JavaZone, JavaLand and many more have all grown out of these groups and provide a wealth of information to help developers get the most from Java.

Of course, Java itself is a massively overloaded term and has referred to a quite mind-boggling array of technologies, features and APIs over the years.  Here are a few of the ones I either think were significant or I particularly liked:

• Java Enterprise Edition (Java EE). Realistically, this was what helped Java to become the platform of choice for most server applications.  I remember using an early version of Netdynamics app server to build a demonstration of Java EE; it took me over a week to beat it into submission just to get to the point where I could run a simple servlet and enterprise Java bean (EJB).  Servlets have survived the test of time well, Entity EJBs not so much.  The object-relational mapping has always been a tough nut to crack.Java EE survives but now as Jakarta EE under the Eclipse Foundation.  Issues of namespace aside, they are focusing on cloud-native development and microservices related specifications.
• Java Micro Edition (Java ME): In Java’s early days a typical desktop PC would have 8Mb of RAM, which was enough to run a full JVM (just). Early mobile and embedded devices had RAM that was measured in hundreds of Kb and not enough to run standard Java.  To address this, we got Java Micro Edition which was a stripped-down JVM and minimal class libraries.  It used Configurations like the Connected Limited Device Configuration (CLDC) and profiles, like the Mobile Information Device Profile (MIDP) to tailor the platform to the end device.Although most phone manufacturers put Java ME on lots of phones, some significant problems prevented its success.  Different handset vendors versions were mostly incompatible in terms of additional libraries (the core Java ME set was too small to do anything exciting) and getting an app onto your phone required far more technical skill than was reasonable.  What they needed was an app store…Moore’s law and, more importantly, the iPhone, effectively killed Java ME.  A few die-hards continued to use it for some embedded applications, but an attempt to revive it in the JCP recently was unsuccessful.
• Sun SPOTs: Hardware! The Sun SPOTs (Small Programmable Object Technology) were a research project, primarily to build the Internet of Things (IoT) before it was called that.  They were about the size of a large matchbox, had a rechargeable battery, ARM processor, basic sensors (accelerometer, light and temperature) and a row of LEDs.  They also used IEEE 802.15.4 for wireless communication, allowing personal area networks (PAN) to be created.  These were great little devices that ran Java ME, and I had immense fun building demos using them like a robot swarm.  The best demo, though, was the ball in a jar.  The accelerometer was used to control the LEDs so as you tipped the SPOT; the light would appear to move.  Then you could tip the light out of one SPOT into another by using the PAN!Sadly, the price per unit was prohibitively expensive (it needed to be more like a Raspberry Pi than a low-end laptop), and the project died out.  I still have a few left, as you can see:
  
• JavaFX: In 2007, Sun was planning the yearly JavaOne conference and needed something big for the keynote. JDK 6 had been released six months earlier with nothing to really excite developers.  Java ME had nothing to offer since MIDP 3 was far from ready, and Java EE 5 was already a year old.  A shiny new ball was required, but what could be used?  Chris Oliver, who came to Sun through the SeeBeyond acquisition had developed a scripting language that ran on top of the JVM called F3 (form follows function).  The syntax of this was very similar to JavaScript (with a few bits of SQL thrown in for good measure).  The decision was made to rebrand this as JavaFX (even though it wasn’t technically Java), build some demos and, behold! We had a keynote.This didn’t really get much adoption despite some valiant marketing efforts and in 2011 was re-written entirely as a set of Java APIs.  This was (and still is) much, much better and provides a more modern (and straightforward) way of developing user interface code in Java.  Supporting things like CSS and later 3D make this, in my opinion, a really great piece of technology.  I’ve written loads of JavaFX code and really love it.
• Real-time Java: The first-ever JSR.  Real-time Java was an attempt to provide a Java implementation that could be used in industrial automation applications.  Providing hard real-time is not easy (for starters, you need a real-time operating system underneath), and GC becomes a real issue.  The spec introduces some interesting concepts like immortal memory.This did provide some fun demos like Greg Bollella’s industrial robot at JavaOne and Audi using it to drive a TT up Pike’s Peak autonomously.
• Jini: Another fantastic piece of Sun technology that was way ahead of its time. The concept behind Jini was self-assembling networks with devices announcing themselves and using leases so other devices could detect it if they dropped off the network.  It was all very elegant, and I think it could have had a real place in microservice architectures, but it just wasn’t to be.
• Java TV: In the late 90s, Sun was trying to put Java in everything it could think of and one area that showed a lot of promise was set-top boxes. Cable companies wanted to deliver more than just channels and that would require applications and user interfaces.  I ended up working on this project as part of my ISV related job and developed some demos using Xlets (everything in Java has to be a -let of some kind).  I even got to show demos of Java TV off on the BBC stand at some TV trade shows.

There were lots of others that were great ideas but didn’t quite work out in the end: Personal Java, JavaOS and Java for the Advanced Intelligent Network (JAIN), to name but a few.

As a language, Java has evolved over the last 25 years in a way that has, with few exceptions, provided excellent backwards compatibility.  I was able to run some (although not all) of XXX

Let’s look at some of the highlights of changes to the core Java platform:

• JDK 1.1: inner classes, remote method invocation (RMI) and JDBC for database access.
• JDK 1.2: Swing and the strictfp modifier
• JDK 1.4: Assertions. One of the only places where backwards compatibility was impacted. Prior to this, you could use assert as a variable name, so any code that did this would have to be changed to make it compile on JDK 1.4.  Thankfully, a simple search and replace is all that’s called for.  (Technically, this also applies to strictfp in JDK 1.2, but I’m not sure how many people would have used that as a variable name).
• JDK 5: This was the most significant set of changes since the language was launched and introduced several notable new features
  • Generics
  • Annotations
  • Autoboxing/unboxing
  • Enumerations (another compatibility issue as enum became a reserved word)
  • Varargs
  • Enhanced for each loop
  • Static imports
• JDK 6: One of the least feature-rich releases of Java. No changes to the language and nothing inspiring in the APIs, either.
• JDK 7: This had a batch of small language changes grouped under project coin (small change in your pocket, get it?)
  • Strings in switch statements
  • try-with-resources
  • The diamond operator for generics
  • Multi-catch statements
  • Binary literals
  • Simplified varargs
  • Underscores in numeric literals.
• JDK 8: This contained probably the biggest changes to Java since its introduction in the form of Lambda expressions and the streams API, which add functional-style programming. This has proved to be a hugely popular feature and got many developers excited about using Java again.
• JDK 9: Project Jigsaw, the Java Platform Module System. A contentious development which involved delays to the release of JDK 9 after the JCP took the unprecedented step of voting against the public review of JSR 376.  This led to changes to the encapsulation of internal APIs and a reconsideration ballot.  Many users have stuck with JDK 8 because of the perceived complexity involved in moving to use modules.  I think breaking up the core class libraries into modules and adding the jlink command was essential.  The rest of the module system, I’m not so sure.
• JDK 10: The first release under the new six-month release cadence brought us local variable type inference; var comes to Java.
• JDK 11: This was more about removal than addition. We bid farewell to all of the APIs under the java.se.ee aggregator module (CORBA, JAX-B and JAX-WS) and the Oracle JDK lost the browser plugin (surely, the end of applets), Java Web Start and JavaFX.
• JDK 12: Switch expressions (the first preview feature, meaning it isn’t part of the Java SE specification in this release).
• JDK 13: Text blocks (also a preview feature)
• JDK 14: Another significant set of changes, adding records (finally!), pattern matching for instanceof (both preview features) and, my favourite, helpful NullPointerExceptions.

One thing I have to highlight is Java version numbering.

Initially, we had JDK 1.0, which was very logical.  Then we got JDK 1.1, which (to me anyway) was already a mistake.  With the introduction of things like inner classes, it should have been JDK 2.0. Next came (logically, based on 1.1) JDK 1.2 but unfortunately, marketing got involved, so it was decided to rebrand this as Java 2.  Except engineering didn’t get the memo, so we had Java SE 2 version 1.2 then Java SE 2 version 1.3.  Things got even more complicated because it was decided to introduce an extra digit, thus Java SE 2 versions 1.3.1, 1.4, 1.4.1 and 1.4.2.

Because the next version of Java introduced significant language changes, marketing got involved again.  Behold!  Java SE 2 version 5.0 (but java -version still shows 1.5).  Finally, it was determined that there never would be a Java 3 and we didn’t need the extra digit, so we got the new, streamlined Java SE 6.  That should be it, right?  No, sadly not.  The internal version still came back as 1.6 and even though we had Java SE 7, 8 and 9, we weren’t finished changing the version string yet.  Finally, in JDK 10 we have JDK 10.0.2 (although bizarrely, that second digit will only ever be zero).  Hopefully, that’s the end of it!

Of course, over the years, Java has not been without its controversy.

As Java started to take off, rising in popularity right alongside the dot com bubble, Microsoft decided it could ‘improve’ on Java.  This took the form of removing certain APIs from the core library java namespace and adding a few they felt were missing.  The net (if you’ll excuse the pun) result was two incompatible Javas.  Something Sun really didn’t like, since it broke the whole, “Write once, run anywhere” idea.  After much legal wrangling and the birth of C#, Microsoft paid Sun $1.9b in compensation.  It’s great to see that, for the last few years, Microsoft has become one of the most vocal proponents of Java and offers a fully supported build of OpenJDK (in the form of Zulu) on its Azure cloud.

Roughly at the same time, a lot of people started calling on Sun to make Java more open from a definition perspective.  Some people thought there was a need to let an independent standards body take over and define the platform.  Someone like ANSI (who published standards for C and C++) or ECMA (who did the same for C#).  Given the marketing value of Java, Sun was not keen to do this, and so in 1998, the Java Community Process (JCP) was created.  The role of this new organisation was to develop standards for all different aspects of the Java platform.  Rather than this just being done by Sun, any interested parties were invited to join.  This was a success, in that many companies like IBM, Nokia, SAP and even Google joined as well as some notable individuals like Doug Lea.  Different aspects of Java were assigned to Java Specification Requests, each of which had its own expert group (EG).  With Java SE 15, there are now 390 JSRs (along with 27 maintenance JSRs, a feature that is no longer used).  In theory, each JSR should result in three things:

1. A full specification of the specific Java technology.
2. A reference implementation (RI) that proves the specification can be implemented
3. A Technology Compatibility Kit (TCK) that proves the specification is unambiguous and can be used to verify implementations (including the RI) against the spec.

This certainly addressed the issues of an open specification and meant that other organisations were now in a position to be able to provide alternative implementations of Java technology.  The most notable of these was developed by IBM, who developed a clean-room implementation of the JVM, J9.

Early in the new century, there were increasing calls for Sun to make Java open source.  The popularity of Linux had shown this to be successful, and many people thought Java should be set free.  Working for Sun at the time I remember some people were keen on this idea and some were vehemently opposed.

In 2005, the Apache Harmony project was started that intended to develop an open-source, free Java implementation.  Although Sun provided the JDK freely, the license used included a field-of-use (FoU) restriction, which prohibited the use of Java in embedded applications.

In order for the Harmony project to be able to provide a real Java alternative, what they developed (which at the time was Java SE 5) would need to pass the TCK.  Sun refused to license the TCK to Apache without including the FoU restriction.  Apache found this unacceptable.

After some discussions that did not resolve the issue, in 2007, Apache wrote an open letter to Sun regarding their issues with acquiring the TCK.  Sun’s response was to announce their intention to release the source code for the Sun implementation of the JDK under the GPL.  Thus, was born the OpenJDK.

Unfortunately, this did not satisfy Apache, which led to a situation of stalemate that considerably hindered the development of the core Java platform.  JDK 7 was released on July 7th, 2010, 4 years, 6 months and 26 days after JDK 6; easily the longest time between Java releases.  This resulted from a combination of things: the dispute with Apache, Sun’s engineers being diverted to work on JavaFX and the acquisition of Sun by Oracle.  Having taken control, Oracle set about sorting things out.  They did this with clinical efficiency, convincing IBM to switch sides to the OpenJDK and making it clear that the TCK license was never going to change.  As a result, on December 9th, 2010, Apache resigned from the JCP; less than a year later, the Harmony project was retired.

Then there’s the whole Google and Android situation that I’m not even going to get started on…

Although nobody truly knows the exact number, I think it’s safe to say that there are millions of Java developers around the planet.  If you look at the surveys of which are the most popular programming languages, Java is always at or very near the top. Indeed, when I’ve been presenting at JUG events, there’s generally at least one recruitment agent there looking for people with Java experience.

With almost predictable regularity and practically ever since Java was a year old people have been predicting the death of Java.  I certainly don’t see it anytime soon.  The value of the JVM as a managed runtime environment is beyond question. Whether you use Java, Kotlin, Scala or any of a myriad of languages to write your code, they can all be compiled down to bytecodes.

We can’t, of course, forget about JavaOne, the annual (at least until 2017) conference for the latest and greatest in Java.  I didn’t start attending JavaOne until 2002 and missed a couple of others. Still, I certainly attended quite a few of these events, twice being awarded the status of JavaOne Rock Star.  I was also twice part of the keynote with James Gosling, first showing off my ‘wearable’ computing demo in 2004 and then my JavaFX screen projection demo in 2009.  One of the fun things about JavaOne was the show device, which I often got sucked into buying.  I finally got rid of my Sharp Zaurus only a couple of years ago.  I still have a Java Ring, and I’ll be keeping that.

No retrospective of Java would be complete without mentioning Duke.  Even he went through a couple of iterations.  Originally, he was going to be called The Software Agent (as he was supposed to be a helper built into the UI of the Star 7 PDA).  Joe Palrang, who drew the original character, called him Fang (because he looks a bit like a tooth, which is a common mistake non-Java people make when they see him).  Sun PR didn’t like this, so he became Duke, the mascot of Java.  He even stared in his own comic, “The Amazing Adventures of Duke” (which lasted for only one edition from Sun’s marketing department).

Many Duke T-shirts have been made, as well as a wide range of other swag.  Here’s my favourite, which I think I got from a Sun event in Japan.

I’ll finish by quoting James Gosling, the Father of Java from the foreword he wrote to “HELLO WORLD(S)!” From Code to Culture: A 10 Year Celebration of Java Technology”

“In the early 1990s, a small group of us from Sun Microsystems were given the opportunity to spend all of our time thinking of what ‘the next big thing in technology’ would be. What we created was a hardware-independent software platform unlike any other.  We thought it was pretty cool, and so did our developer friends.  But at that time, I don’t think any of us really had any idea of what we had done, not to mention how it would change the world.  I certainly know I didn’t.

And, of course, it wouldn’t have happened if it weren’t for the Java developer community.  Developers are the ones who really made Java technology a success over the years.  Their ingenuity, creativity and millions of hours of contributed help has made the Java platform what it is today.  We’re lucky to have millions of developers constantly driving it forward into the future.”

Even 15 years later, that’s as true as ever.

Happy birthday, Java!