Eclipse Loves Java: Here’s How We Got Here

It’s no secret that the Eclipse Foundation has a bit of a love affair with Java, though it’s had its ups and downs. There are many projects at the Eclipse Foundation, large and small, that rely on Java and extend its usability, likely more than people realize. I’ll be covering a lot of those projects and the interesting work they’re up to in my EclipseCon talk, Eclipse Loves Java.

To understand how and why Java has become so important here, it helps to understand just how far back the history of Java at the Eclipse Foundation goes.

In the Beginning, There Was Java

It’s borderline ancient history now, but back in 2001, IBM made a splash by releasing its IDE, the IBM VisualAge for Java. This was a big deal. The norm 20 or so years ago was that developers had to pay for development tools if they were out on their own. The development tools that existed were basically closed source, so you could only access them if you worked there. 

But the release of the IBM VisualAge opened the door. Suddenly there was a new, open framework to work with. It formed the basis of the Eclipse IDE. 

The crucial thing about Java was that it was not only one of the biggest languages around at the time but one of the most open source friendly. That meant having a Java-based IDE made it possible for Java-trained developers to make improvements and contributions to the IDE, including by adding support for other programming languages. 

From Java Came Jakarta

Jakarta EE was the next big milestone in the Eclipse Foundation’s ongoing relationship with Java. When Java Enterprise Edition (Java EE) was under the purview of Oracle, everything that was happening in the Java world was in the Java Community Process (JCP). Some of this was open source, but not all, and the TCKs in the specifications were often closed source.

The problem for the community was that, legally, no specifications within the Java namespace could change. And normally that’s what you want for a specification standard — you don’t want to change the standard. But the specification should evolve and grow. 

So, the namespace change really started as a legal consideration. We’ve spent the better part of the last two years cleaning it up, and with the release of Jakarta EE 10, we’re now in a place where we can focus on adding new features. 

MicroProfile Produced a Focused Enterprise Java

It’s also important to discuss the MicroProfile project. This started outside the Eclipse Foundation as an effort to optimize Enterprise Java for the Microservices architecture. The desire was for a small but powerful API that could move faster than Java EE.

When MicroProfile came under the banner of the Eclipse Foundation, this changed the Java dynamic. In particular, many people were wondering whether we needed this project and Jakarta EE, which came to the Eclipse Foundation afterwards. 

I think it makes sense to have both. Jakarta EE provides the overall platform and the big picture of all the standards for creating big enterprise applications, whereas MicroProfile provides a much smaller, more narrowly focused toolbox built to provide an optimized baseline platform based on commonality, rather than standards, for microservices architecture. This makes MicroProfile more specialized, much leaner, and faster to change and adapt. 

Adoptium Working Group for Enterprise-Ready Java Runtimes

Any discussion of Java at the Eclipse Foundation would be remiss without talking about the Adoptium Working Group. 

This also started outside the Eclipse Foundation. The AdoptOpenJDK project was a community-driven effort to provide prebuilt OpenJDKs. It ended up getting so popular that it only made sense for it to become part of an open source foundation. Nowadays, the focus is on providing free, enterprise-ready, and vendor neutral runtimes for Java. This includes, crucially, tests and benchmarks for runtimes. 

Work, of course, also continues apace on enhancing the test suite, especially in the areas of security and reproducibility. And there’s always a push to make the runtimes available on as many platforms and systems as possible.

From One Language, Many Possibilities

Clearly there’s been a ton of work done to bring Java more fully into the open source space. But why? What’s so great about Java?

Well, this process potentially could’ve been done with another language, sure. But Java was very open source friendly. And that has made it possible for us to do all this work and build out all these functionalities. 

And there’s another advantage of picking a language and running with it, especially from the Eclipse Foundation’s point of view. Because support for so many other languages has been built into our Java-focused projects, there’s a consistent and extensible basis for a lot of the tools and specifications that emerge from them. That makes it vastly easier for people to pick up these new tools and use them if they have at least some familiarity with Java, which most developers do. And because we’ve done all this work to make Java more open and accessible to everyone, it’s easier than ever to gain familiarity with it. 

We’re all about code, community, and collaboration at the Eclipse Foundation: Java helps us get there. Coincidentally, that’s also the motto of EclipseCon, which is coming up. If you’d like to learn more about just how much Java is being put to use in different projects, come check out my talk at the conference.