Liberated from Oracle, Eclipse Jetty Enters the Cloud Native Era with Jakarta Transition – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Liberated from Oracle, Eclipse Jetty Enters the Cloud Native Era with Jakarta Transition – InApps in today’s post !
Read more about Liberated from Oracle, Eclipse Jetty Enters the Cloud Native Era with Jakarta Transition – InApps at Wikipedia
Eclipse Jetty, the webserver and servlet container project, has released Jetty 11, and with it not only became certified as fully compatible with the Jakarta EE 9 Servlet specifications but also moved into the
jakarta.* namespace, which Eclipse Foundation executive direction Mike Milinkovich sees as a good sign for the ecosystem as a whole.
“Jetty is one of the preeminent, very often used runtimes for Java applications and the fact that they have now adopted the Jakarta namespace really helps reinforce the message that the ecosystem is moving with us, that we are moving from the
Javax.* namespace to
Jakarta.*,” said Milinkovich in an interview. “It’s ultimately a key supporting fact that the ecosystem is following the lead that we’re taking with Jakarta, moving to the Jakarta namespace, and helping us enable hopefully a lot of new innovation, and particularly cloud native innovation, moving forward.”
The Eclipse Foundation completed the transition of the Java Enterprise Edition (EE) specification from Oracle over to Jakarta with the release of the Jakarta EE 8 specification in September 2019. Shortly thereafter, Jakarta EE 9 introduced the “Big Bang” approach, wherein all specification APIs changed namespaces to
jakarta.* instead of
javax.*, in order to fully complete the separation from Oracle. Milinkovich explained this move as one that goes far beyond naming, to one actually allowing innovation where it was previously stifled by rules put in place by Oracle.
“The main reason for bringing Java EE to the Eclipse Foundation and moving into Jakarta E is not just about keeping stability, it’s about increasing the pace of innovation. One of the sticking points we had with negotiating this transfer with Oracle was the use of the
Javax.* namespace. In the end, the decision was made that we were going to have to come up with a new namespace. We have to take all of these specs and move them from the Java.x namespace into the Jakarta namespace,” said Milinkovich. “Once we’ve done that, we now have the flexibility to start really altering those APIs and really start innovating. As long as we’re operating the
Javax.* namespace, we have a set of constraints imposed on us by the Java Community Process that is basically an insolvable set of constraints.”
Even though Jetty reached this place of prominence in its usage, Milinkovich points out that it was never able to become certified under the Java EE servlet specifications because “the rules at the JCP were perceived as too onerous” and “they would have had to have entered into a licensing agreement with Oracle that would have had certain constraints.” Under Jakarta EE, however, the Technology Compatibility Kit that checks for compliance has been open sourced and, alongside what Milinkovich says is basically a “zero cost licensing program,” the foundation is seeing renewed engagement.
“That was part of the original success of Java in the beginning, right? The ‘write once, run anywhere’ strong compatibility between vendors, these are all parts of the original Java value proposition. We’re seeing that reinvigorated by the new licensing model around the TCKs and the compatibility program that we implemented as part of Jakarta. We’ve significantly reduced the barriers to entry there and we’re really thrilled to see the Eclipse Jetty project fully certified for the first time in its history,” said Milinkovich.
Beyond Jetty’s own certification, the project’s leaders are engaged in the Jakarta servlet specification process itself, and Milinkovich says that he sees them focusing on enhancing the specification moving forward.
“This goes back to that ‘cloud native innovation’ that I was talking about,” said Milinkovich. “What we’re really hoping to see is new additions to the capability of the servlet spec itself to make it even stronger and more relevant in the cloud native era.”
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.