Understanding Jakarta EE: “Recognizing the importance of Kubernetes likely means...

Jakarta EE: The story so far

Transfering Java EE technologies from Oracle to the Eclipse Foundation is no easy job. The Jakarta EE brand is evolving rapidly but we need to stop for a minute and acknowledge all the changes and plans which will include the platform’s evolution into cloud, containers, microservices, serverless, and reactive technologies.

The visionfor the technical future of Jakarta EE includes the following:

• Enhanced support for microservices architecture
• Move to Cloud Native Java, which includes better integrations with technologies like Docker and Kubernetes
• Increase the pace of innovation
• Build a vibrant developer community
• Provide production quality reference implementations

Update: The results of the Participant and Committer Member elections for representatives to the Jakarta EE Working Group Steering Committee, Specification Committee, and Marketing & Brand Committee have just been announced .

• Specification Committee – Participant: Alex Theedom (LJC)
• Specification Committee – Committer Member: Ivar Grimstad
• Marketing & Brand Committee – Participant: Simon Maple (LJC)
• Marketing & Brand Committee – Committer Member: Ivar Grimstad
• Steering Committee – Participant: Martijn Verburg (LJC)
• Steering Committee – Committer Member: Ivar Grimstad

If you want to learn more about the Jakarta EE Working Group governance and processes, have a look at the Jakarta EE Working Group Charter page.

Now back to our series!Keeping track of what’s in and what’s out is still a work in progress, but here’s what we know for certain. While there may be some other proposals that are still pending, theseare the projects that have been accepted. This list should help you keep track of Jakarta EE’s progress but we’ve only scratched the surface.

What are the current and future challenges of Jakarta EE? How is it forging a new path forwards for enterprise Java? Where is it headed? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java.

Now it’s time to welcome our next guest, Arjan Tijms, project lead for Eclipse Mojarra and tech lead at Payara. Let’s dive deeper into the Jakarta EE universe!

asap

JAXenter: Would it be a good idea to merge Eclipse MicroProfilewith Jakarta EE?

Arjan Tijms:  Absolutely. The MicroProfile APIs are already strongly built on an EE foundation and are mostly used by EE programmers using EE products (like Payara Server or Payara Micro, WildFly, Liberty, etc). MicroProfile APIs are also implemented by the very same organisations and people who also implement the EE APIs.

MicroProfile APIs fill gaps in the Jakarta EE APIs, gaps that would eventually have been addressed there anyway. For instance, MicroProfile specifies a JWT authentication mechanism. Basically, the exact same mechanism was planned for inclusion in the EE Security API as well (up to the point that even some prototypes for it were already developed). It wouldn’t make much sense to introduce another JWT authentication mechanism in EE that also does authentication based on JWT but in a different way.

An important aspect of being cloud-native is having self-sufficient application archives, as opposed to archives with unresolved dependencies, which would then have to be provided at deployment time by a “deployer”.

On the other hand, MicroProfile sometimes had to make some assumptions since functionality was required but the foundation for it wasn’t quite there. For instance, looking at JWT again – there’s no real security foundation in MicroProfile. It’s largely assumed there is something, but what that “something” is exactly, and how it works, isn’t specified. The MP-JWT spec, which should only have specified the authentication mechanism itself, had to pull a security foundation pretty much out of thin air by necessity. Merging MicroProfile with Jakarta EE means MP-JWT can let go of this assumption and use Jakarta EE’s mature and solid security foundation (in the Payara Platform, MP-JWT is already fully built on the EE Security API foundation).

JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?

Arjan Tijms:  I’m not really sure if “already been chosen” is the right terminology here. Jakarta EE’s (spec) process and work is largely still to start, as the transfer from Oracle’s Java EE to Eclipse’s Jakarta EE is still in progress.

That said, an important aspect of being cloud-native is having self-sufficient application archives, as opposed to archives with unresolved dependencies, which would then have to be provided at deployment time by a “deployer”. Such unresolved dependencies would be things like identity stores for security, datasources for database access etc. For on-premise deployments of software that needs to integrate with the intranet of an office environment, such unresolved dependencies are often exactly what you need, but for cloud deployments where you deploy a single application (which may internally consist of microservices), this is not always ideal.

Self-sufficient application archives doesn’t mean the archive is a black box, however. On the contrary, the resources it uses are still configurable and manageable using the runtime’s (cloud) console or CLI.

JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?

Arjan Tijms:  The ability for Jakarta EE applications to obtain their configuration from an external source if needed is an important thing. This seems to oppose the goal of being self-sufficient, but it’s not. In traditional Java EE applications, the unresolved dependencies must be resolved at deployment time, which is painful for cloud deployments. To make it more cloud-friendly, the resources are primarily specified within the archive, but their configuration comes from configuration sources, and these sources can be either internal (in the application archive) or external (in the runtime/server, on the filesystem, coming from a central config server, etc).

Furthermore, Jakarta EE can evolve by providing a number of cloud connectors, which are essentially plug-ins that allow applications to talk to their cloud environment. The JWT authentication mechanism mentioned above is one such connector.

SEE ALSO:  Java EE 8: the baseline of Jakarta EE

JAXenter: Let’s focus on the Jakarta EE  survey results . Over 60% of the respondents want better support for microservices. How would you implement that?

Arjan Tijms:  To start off with, different surveys have a somewhat different outcome here. For instance, in the OmniFaces Java EE survey , the wish for microservices seemed less clear.

It’s also important to realise that microservices are not a good fit for every problem out there, and should not be overdone. Splitting out a small application into, say a hundred microservices, is not likely going to make things easier. On the other hand, a single monolithic application of 1000.000+ lines of code where parts of that application do wildly different things, but where you still have to deploy the entire application for each of those separate things, is far from ideal either. Common sense plays an important role here.

Also, microservices are mostly about doing one coherent small (micro) task and having that task available as a (remote) service. It technically doesn’t say though that the runtime on which this small service runs should also be small or “micro”, although people typically do expect that. Here’s where we typically see a mismatch of perception. Java EE servers are thought of as huge servers (as in many gigabytes footprint on disk) and that they take ages to start up (as in many minutes to hours, or even days in the most extreme case). In reality, though, most servers are around 150mb on disk and start up between one and three seconds. See this example .

This mismatch in perception comes out in two ways;

1. People think runtimes for microservices should also be micro, but this is strictly speaking not the case, and
2. People think Java EE servers are absolutely huge, while this is not quite the case either.

That said, Jakarta EE servers can accommodate the desire for smaller runtimes by having the ability to statically disable and even remove parts of the server that won’t be used. A variety of servers already allow this to various degrees, but some standardisation of this and making it more a core aspect of Jakarta EE rather than a vendor feature that not everyone has heard about would certainly help.

Likewise, the uberjar or hollow jar option used by e.g. Payara Micro and WildFly Swarm (Thorntail) should probably be standardised in some way as well.

JAXenter: Speaking of the survey, the second most desired aspect is native integration with Kubernetes. Should this be a priority for the development of the project?

The Jakarta EE specs could make it easier to implement native Kubernetes integration as a vendor feature by defining some aspects of clustering.

Arjan Tijms:  This would be a rather interesting direction to explore for sure. Java EE and therefore, now Jakarta EE, has always been about containers and about clustering, even though the actual specs haven’t mentioned much about clustering really. The actual clustering technology was therefore always a vendor thing. For example, GlassFish and earlier versions of the Payara Platform used Shoal for their native clustering technologies, while newer versions of the Payara Platform use Hazelcast. JBoss/WildFly uses JGroups and Infinispan for this, etc.

Whether Kubernetes should be mentioned in the Jakarta EE specs or left as a vendor feature has yet to be decided. Java EE specs have always been trying to avoid binding itself to specific products and have largely favoured supporting standards instead. The Jakarta EE specs could make it easier though to implement native Kubernetes integration as a vendor feature by defining some aspects of clustering.

Furthermore, recognising the importance of Kubernetes (and containers like Docker), likely also means a further reduction in the importance of running multiple applications on a single Jakarta EE server. This ability was once an important feature, especially the larger Java EE servers (IBM’s WebSphere and BEA’s WebLogic at the time).

JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?

Arjan Tijms:  Faster releases is probably the way to go, with perhaps at certain moments a stable (LTS) release. While faster, of course, sounds better, we also must remind ourselves that a stable platform on which other libraries (such as PrimeFaces, OmniFaces, DeltaSpike, etc) and tools (such as Eclipse, NetBeans, etc) are built is worth a lot too. A constantly changing platform puts extra stress on these parties who would constantly need to be up to date with the latest version.

JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?

Arjan Tijms:  I’m directly involved with the security specs (EE Security, JACC and JASPIC), and some of the Web framework specs (JSF and Expression Language). I’m also a committer on various other spec and implementation projects, such as JAX-RS, Jersey, Mojarra, Soteria, etc.

On behalf of Payara Services, LTD I’ll be contributing new APIs designs for the API projects and implement those in the implementation projects. I’m also involved with implementing some of the MicroProfile specs, again on behalf of Payara.

SEE ALSO:  Jakarta EE: No turning back

JAXenter: How do you think the community should adapt to the changes that have taken place recently?

Arjan Tijms:  For end users of the Java EE products, there will not likely be a tremendous change to adapt to. For them the next major version of their server (JBoss, Liberty, the Payara Platform, etc) will support “Jakarta EE 9” instead of “Java EE 9”, but largely that would have been what “Java EE 9” would have been, otherwise. Meaning, new releases of all the Java EE specs people love to use, such as JPA, CDI, JAX-RS, JSF etc.

For contributors to the specs, APIs and implementations is in some way different, in others ways not so much. People can still create issues and bug reports, and very little has changed there. The main change is perhaps that there’s going to be fewer issues with specs and API projects needing to be “active” beforehand. In Java EE and with the JCP, one could, for instance, not have anything done during the Java EE 8 cycle for, say, the Concurrency spec. The problem was the Concurrency spec wasn’t active, even though there were people around that could and wanted to do work for it. The Concurrency spec could also not be made active since it wasn’t planned to be active. And it finally couldn’t be planned to be active since the planning had already happened (somewhere before Java EE 8 started).

Such problems should be far less or even non-existent with the Eclipse process. If a committer wants to make a change in an API project, this is always possible, only subject to the approval of other committers in that same project. There’s no higher power that periodically opens and closes the project depending on the cycle of some other project.

JAXenter: What’s next for Eclipse Mojarra ?

Arjan Tijms:  Eclipse Mojarra will be preparing for a major new release; 3.0.

The theme of that release will be to get rid of a large amount of cruft and legacy things. Last year, even before the transfer, we have been focusing on cleaning up the project itself and finally switching over to a normal Maven project structure. In the early days, the Mojarra project was based on ant and several custom scripts. A few years ago Manfred Riem started to migrate the project to Maven. In 2.2 it’s a kind of hybrid structure, in 2.3 Maven can be used independently, but all of the ant scripts are still there. Now finally for 3.0 all the old ant code and scripts have been removed and there’s only the maven project left.

As for the API we’re going to remove JSP support, which has been effectively deprecated for quite some time (since 2.0 which was released in 2009), and remove the native managed bean system (which has been officially deprecated in 2.3, but for which warnings of it eventually being deprecated were present in 2.0). Furthermore, we’re going to remove the last remaining bits of the ancient native EL support that still lingers around but has been deprecated since a very long time (since 1.2, which was released in 2006).

For end users of the Java EE products, there will not likely be a tremendous change to adapt to.

The result is that 3.0 will be binary incompatible, hence the change in major version number. The majority of applications should have little to no problems though, but very, very old applications should stay on 2.3 or earlier until migrated to work on 3.0.

Another plan is to rebase even more things on CDI. This work already started in 2.3, but we’d like to continue that path in 3.0.

JAXenter: Could you please describe what this project is all about?

Arjan Tijms:  JSF is an MVC-pull framework. It generates HTML on the server and sends that to a client (a web browser) that renders it. An important aspect of JSF is that its UI is component based, where these components can be created by developers themselves or delivered by third-party component libraries (such as PrimeFaces). JSF being a server-side MVC framework essentially competes with client-side MVC frameworks such as Angular. Angular is particularly interesting here as it seems to have taken some inspiration from JSF.

We believe that both server-side frameworks and client-side frameworks have their own advantages and disadvantages, and neither one is better than the other in all aspects. With JSF we’re trying to make it a very good alternative for those who are looking for a server-side MVC framework while recognising that client-side frameworks have also captured a big chunk of the overall MVC market.

Thank you!

Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!