Eclipse Starter Fills a Longstanding Gap in Jakarta EE

Jakarta EE is a powerful, useful, and versatile tool that offers a comprehensive set of specifications. And the move to bring Jakarta EE over to the Eclipse Foundation and the world of open source was a difficult and monumental task. Well known technologies such as Spring, Quarkus, and Micronaut, to name a few, rely on a subset of Jakarta EE’s specifications. All certified products on Jakarta EE compatibility pages implement these specifications using either the full platform or a profile. 

Amid that Herculean effort, there were many priority tasks to be taken care of. One that’s expected to arrive by Q2 this year is a critical one: a way for newcomers to get started with Jakarta EE. Eclipse Starter for Jakarta EE project committer Reza Rahman sat down with us to explain why the starter is so important, and what’s next for the project.

Why is the starter so important?

There’s been a longstanding perception of Jakarta EE and Java EE that it’s kind of impenetrable and hard to get into. And that was true to a certain extent for some years. Java came out nearly thirty years ago, and some of the runtimes based on it are nearly as old. Many of the runtimes also had convoluted installation procedures, and it takes several steps to get them installed and running on a machine. That’s one of the consequences of being the first out of the gate with a new technology: you don’t have the example of others to look to and see how to optimize things. That said, many, if not all, of these issues are solved in more modern Jakarta EE runtimes, which offer: modularity, fast startup, easy launch right from Maven, quick installs, convenient packaging, and Docker support.

The starter project demonstrates the applications that users built can run on selected Jakarta EE certified runtimes. In its absence, there isn’t anything to help developers get started using Jakarta EE. If they had the necessary knowledge and were very motivated, they could figure it out. But it created a lot of unnecessary friction.

The project attempts to address these issues by basically allowing a newcomer to get started with Jakarta EE quickly and easily — with a runtime of their choice and painless on-boarding in mind. 

With this release, what status is the starter at now?

So, what we have now is a respectable, usable starter, on par with anything else out there. It has two key components: the archetype portion and the Web UI portion. 

The key thing about the archetype is that it lets you get started with a simple but complete project, a HelloWorld RESTful endpoint. And you can generate the project via Maven, through the IDE or command line. We also added support for Docker, because many people are using Docker even if they aren’t deploying in the cloud. 

We’ve also added a broad set of choices to the starter. First off, we added support for basically all the major open source runtimes — GlassFish, Payara, WildFly, TomEE, Open Liberty, etc. And we expanded version support — so Jakarta EE 8, EE 9, EE 9.1, EE 10, and all the LTS Java versions, so 8, 11, and 17. There is also support for the Core Profile, Web Profile, as well as the full Jakarta EE platform. 

The engine behind all of this is the archetype, but it is worth noting that there is a simple, web-based UI as well. If you’re not a command line person, or you’re not familiar with Maven, you can just head to the website, fill out a few options, and get started. 

Here’s a basic visual of how you can use it to generate a project: 

What’s next for the starter?

Because the Eclipse Starter for Jakarta EE isn’t the first starter out of the gate, we do have the advantage of hindsight, and can see what others have done. 

Right now, when you hit that project generator button, it’s just generating that RESTful endpoint. The next goal is to make it so it can also generate a CRUD application. That way, depending on whether your project is going to be minimal or more involved, you can generate either one as appropriate. 

As part of that, we’re also looking at adding the ability to test using JUnit. So, if you generate a CRUD application, you’ll have the ability to get started with testing right away. That hasn’t always been easy in Jakarta EE applications. 

We also want to break things up a little bit. Let’s say you want to generate a CRUD application, but you don’t want, say, a database behind it for some reason, or bean validation. We’ll be adding the ability to turn those off. You can similarly turn testing off too.

Finally, we want to help users take advantage of some of the lesser used capabilities in Jakarta EE, like email, batch, or messaging. The goal is to add a little checkbox or radio button that lets you generate examples of these too. 

Why is it such a big deal for the community to get involved in the starter project?

The thing about the project is that, in and of itself, it’s not the most interesting or challenging thing happening with Jakarta EE. But it’s the face of everything that exists downstream of it. 

Every single one of those projects relies on being able to bring new people in as existing community members move on, and the starter is how that happens. It’s sort of like trying to attract people to your hotel. It doesn’t matter how nice the interior is if you need a ladder to get inside. 

How can people and vendors help?

If you look at the issues in our GitHub, you’ll see that there are a good number of help-wanted tags there. Some of them are highlighted as first contributor issues too, so if you’re a new developer, those are a great place to get started. 

The important thing for us is to build a healthy community of contributors, committers, and vendors who are willing to support this project going forward. Because it’s only going to become more relevant in the Jakarta EE space as time goes on.