Javax to Jakarta

The point of this blog post is to answer one question: why did I have to change most, but not all, of my Java import statements in the Efile Proxy Server from import javax to import jakarta?

Unfortunately, the answer isn’t simple. To figure it out, we have to answer a few other questions, including:

• What even is Java?
• What is Java EE?
• What does the javax namespace have to do with Java EE?
• Who owns Java EE now?
• Why do we have to leave javax?
• Why is Java EE called Jakarta now?
• What do I actually need to do to transition?

Let’s start with the first question.

Java is a programming language, a platform, and an ecosystem

As with many things, knowing a thing’s history helps you understand it better.

Java was developed by James Gosling, Mike Sheridan, and Patrick Naughton at Sun Microsystems. Sun primarily made high end workstations, which didn’t have a large pool of application developers, as a consequence of being high-end. Java was created to be a portable language, so that programs written for less expensive computers would be able to run on Sun workstations too.

Java is actually 3 different things:

1. the language
2. the platform
3. the ecosystem: third-party libraries and build tools

I won’t dive into Java as a language too much here, but for the story it’s relevant to know that Java code is stored in a text file. Each text file has a package, like java.util, and a class that it contains, like List. You can use code from other developers by adding import java.util.List; to the top of your text file.

The “Java software platform” is everything else you get out of the box:

• the Java compiler turns your code into portable bytecode
• the Java Virtual Machine (JVM) runs that bytecode anywhere it can run. Even if I compile my Java program on Linux desktop, that same bytecode can run on your Windows laptop.
• a set of standard classes that you can use in your java program and expect to be there for anyone else who’s installed Java.

The Java platform is split up into the Java Development Kit (JDK) and the Java Runtime Environment (JRE). The JRE doesn’t include development tools like the compiler, and only has the JVM and related tools for running Java.

Java 1 released in 1995. It was free and the source code was publicly available, but you couldn’t redistribute or modify it ^{[footnote 1]}. By the end of the year, internet browsers like Netscape Navigator and Internet explorer had integrated Java, further increasing Java’s popularity. By 1997 Netscape had begun trying to rewrite parts of their browser in Java ^{[footnote 2]}.

The overall approach of Java was market share over profit, attempting to establish Java as a web standard. Giving away stuff for free on the internet seems commonplace nowadays with ad-supported web tech, but it turned heads and ran into skepticism back in 1995. Java also tried to push back against Microsoft’s dominance with it’s portability, which Microsoft seemed to take seriously as a threat. The approach did work pretty well^{[footnote 3]}; Java could run in most browsers until 2015. But Java on the web is a different story; what’s important is that it was successful in gaining market share.

Java released its next version in 1998, originally named Java 1.2, now generally called Java 2. With it came the first major development in our javax story: multiple platforms.

Java EE is business-y platform

Java 2 split the software platform into two ^{[footnote 4]} different releases:

• Java Standard Edition (SE) was made for running on desktop-PCs, essentially what Java had been.
• Java Enterprise Edition (Java EE, originally called J2EE), was an extension on Java SE made for enterprise software.

Enterprise is a vague and wishy-washy term, but Java’s use of the term at release focused on scalability and integration, i.e. faster, and less code to run servers and interoperate with things like XML. Java EE is just the specifications of all of the APIs, and not any one piece of code. Sun included a reference implementation with it’s release, but several other implementations popped up after that. We’re mainly interested in the reference implementation and the specifications themselves for our story.

Package names like javax mean very little

javax has it’s own history as “Java extensions”, things that weren’t in the official Java Runtime Environment (JRE). So if a package was initially introduced outside of the JRE, it would be in javax. javax additions were intended to be promoted to the java namespace. However, to do so, all of the existing code would have to be changed to use java instead of javax (this is foreshadowing). So things that were considered to be an official part of the language stayed in javax.

When Java SE and EE split, Java SE only came with a few javax packages. If you download original Java 2 release from the archives and look at the class files in rt.jar, it only had javax.swing.* (GUI classes) and javax.accessibility.* (screen reader related classes). J2EE had:

• javax.sql.*
• javax.rmi.*
• javax.servlet.*
• javax.naming.*

and more. By Java 5, some of those packages had moved to the Java SE platform, including parts of javax.sql.* (aka Java Database Connection, JDBC) and javax.rmi.*, but they kept the javax namespace. All new packages introduced in Java EE also were named javax. So like squares and rectangles, all Java EE packages are named javax, but not all javax packages are in Java EE.

The differences get more confusing, and at this point I’m kinda at a loss. javax.xml.stream is a part of Java SE, but javax.xml.bind is a part of Java EE. The packages names aren’t consistent enough to determine what’s Enterprise vs Standard edition. My best strategy for finding if something is Java EE or SE is to google the package name; if a Java SE 17 javadoc result comes up (as opposed to a Java 8 javadoc), then it’s SE. In hindsight, it’s not as complicated as I believed, but for the longest time I didn’t understand I needed to look for these things at all, and thought everything in javax was Java EE.

Oracle buys Sun, and owns Java

Continuing our history lesson, Java continued to grow. Sun open sourced Java in 2006 with the GPL. In 2010, it was bought by Oracle.

It’s worth taking a bit of time to understand Oracle.

Oracle is the 4th largest software company in the world, behind Microsoft, Google, and IBM, in front of Pay Pal and Salesforce.Their first product was Oracle Database, and have since focused on the enterprise software market, like ERPs and cloud servers, and have grown by acquiring a lot of other companies, like Sun.

Oracle is disliked in the open source world for a few different reasons. To best make the point, I will liberally quote from a presentation by Bryan Cantrill, former Sun and Oracle employee, about how Oracle killed OpenSolaris, another Sun project it acquired.

• Scott [McNealy] eulogized Sun very concisely: “Kicked butt, had fun, didn’t cheat, loved our customers, changed computing forever.” … This is not Oracle … [Oracle is] “Ship mediocrity, inflict misery, lie our asses off, screw our customers, and make a whole shit load of money”.

• You don’t need to be open minded about Oracle. You are wasting the openness of your mind. ^{[footnote 5]}

• Don’t fall into the trap of anthropomorphizing Larry Ellison. Think of Larry Ellison like you would think of your lawnmower… If you stick your hand in there, it’ll chop it off. You don’t think ‘the lawnmower hates me!’ The lawnmower can’t hate you.

Some additional reasons to dislike Oracle:

• Ellison intentionally ignored a curfew when flying his private jet into San Jose, and then sued the city over it.
• Ellison tried to have a database professor fired because the professor compared Oracle database’s performance against other popular databases at the time. When he failed to do that, he added a clause to the database license saying you couldn’t benchmark the database, a clause that many other companies have copied.
• The other major consequence of Oracle acquiring Sun was that they immediately sued Google for using Java APIs in Android, resulting in a decade long legal battle that could have upended software development as we know it.

Overall, I agree with Bryan that the best way to understand Oracle is that they want money. They get money from businesses and use their various acquisitions to do so. However, making money at the scale of Oracle is often at odds with a healthy open source community for those acquisitions. Oracle is willing to acquire open source projects, not govern them, and prevent others from governing them, as it did with OpenSolaris, Open Office, and almost with Java EE as we’ll see in a moment. This loses trust from individual developers, but that doesn’t matter because Oracle operates on enterprise trust. C-suites being sold products by Oracle aren’t usually invested (personally or monetarily) in open source projects that get bought up and starved of resources and alternatives.

Oracle owns Java trademarks

For Java EE, releases under Oracle stewardship continued as normal, until 2015, when there was a shift ^{[footnote 6]}.

At Oracle World 2015, Ellison’s keynote emphasized Oracle’s cloud products (which will make them money). Soon after, they let go off several Java evangelists, and Oracle sponsored contributions to Java EE came to a halt. The broader community noticed a few months later, resulting in this blog post by Josh Juneau. In August, Oracle said it was trying to work on Java EE 8, and slowly made progress. However, in August 2017, Oracles announced they’re looking into giving Java EE to another open source foundation to govern, essentially washing their hands of the matter ^{[footnote 7]}.

One month later, Oracle announced they’re giving Java EE to the Eclipse foundation which already has a sizable Java portfolio. One good thing! However, the gift came with a lot of caveats, most notably that Oracle was unwilling to let Eclipse use the Java trademark, and thus unwilling to let them use the javax or Java EE names. The new project would be called jakarta.

Future modification of the javax namespace will not be allowed… this [is] in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

So this is why we can’t use javax anymore; no one can touch javax except Oracle. Sun was unwilling to migrate namespaces from javax to java a decade earlier, yet Oracle simply thrusts a change from javax to jakarta upon the whole community.

Jakarta is a city on Java

The easiest question to answer is why we are switching to jakarta specifically. Jakarta, the capital and largest city in Indonesia, is also the largest city on Java, the island, and was chosen by the Java community in a poll.

You’ll need to change a bunch of import statements and Dependencies

In short, go read this blog post, which details the whole migration. At this point (early 2024), most packages should be on Jakarta 10, with Java 17 support, so hopefully the change is easier for you than it was for me, when I started looking into this mess in 2022.

Some lingering threads

What’s up with the Java EE / Jakarta version numbers?

Java EE 8 was released in 2017, but Java SE 8 was released in 2014. Why the big difference?

Until Java 8, Java wasn’t released regularly, but averaged out to every 2 to 3 years. Since Java 9, Java has consistently made a new release every 6 months. So, while there were 5 years between Java 5 and Java 6, now that same time period spanned Java 11 until Java 21.

Because the Oracle acquisition and the Java EE to Jakarta nonsense has taken a bit of time, Jakarta EE hasn’t been on the same release cadence. It only starting to supporting Java 11 in 2021, 3 years after Java 11 released. There’s not going to be a good rule of thumb for knowing what Java releases a given Jakarta release supports, so I continue to check this wikipedia table often.

How does Jakarta EE 8 differ from Java EE 8?

This question arose from a strange sentence in the Oracle post about the Jakarta transition:

By the way, the initial release of the APIs under the Jakarta group ID are Java EE 8 certified, not Jakarta EE 8 certified. For example, jakarta.faces:jakarta.faces-api:2.3.1 is identical to javax.faces:javax.faces-api:2.3 and both are Java EE 8 certified, but the first is built from github.com/eclipse-ee4j and the latter is from github.com/javaee.

It’s a good question, and I’m putting this here so maybe someone can explain it to me.