Ever heard of Java EE? How about Java 2EE, J2EE, or now Jakarta EE? Actually, these are all different names for the same thing: a set of enterprise specifications that extend Java SE. In this short article, we’ll describe the evolution of Java EE.
Then, as part of Java 2 in 1999, these extensions were broken out of the standard binaries, and J2EE, or Java 2 Platform Enterprise Edition, was born. It would keep that name until 2006.
For **Java 5 **in 2006, **J2EE **was renamed to Java EE or Java Platform Enterprise Edition. That name would stick all the way to September 2017, when something major happened.
See, in September 2017, Oracle decided to give away the rights for Java EE to the Eclipse Foundation (the language is still owned by Oracle).
Actually, the Eclipse Foundation legally had to rename Java EE. That’s because Oracle has the rights over the “Java” brand.
So to choose the new name, the community voted and picked: **Jakarta EE. **In a certain way, it’s still JEE.
This is still an evolving story, though, and the dust hasn’t completely settled.
For example, while Oracle open-sourced the source code, they did not open-source all the documentation. There’s still a lot of discussion over this matter because of legal issues that make it tricky to open-source documentation related to, for example, JMS and EJB.
It’s not clear yet if new Eclipse Foundation documentation will be able to refer to the originals.
Also, curiously, the Eclipse Foundation can’t create any new Java packages using the javax namespace, but it can create new classes and subclasses under the existing ones.
The transition also means a new process for adding specifications to Jakarta EE. To understand it better, let’s take a look at what that process was like under Oracle and how it changes under the Eclipse Foundation.
Historically, in order for a feature to make it into “EE”, we needed three things: **a specification, a reference implementation, and tests. **These three things could be provided by anyone in the community, and an Executive Committee would decide when these were ready to add to the language.
To better understand the past process, let’s take a closer look at what JSRs, Glassfish, and the TCK are and how they embodied new EE features.
We’ll also get a glimpse of what to expect in the future.
In the past, the process by which a new EE feature was born was called the Java Community Process (JCP).
Java SE still uses the JCP today. But, since EE has changed its ownership, from Oracle to the Eclipse Foundation, we have a new and separate process for that. It’s the Eclipse Foundation Specification Process (EFSP) and it’s an extension of the Eclipse Development Process.
There are some important differences, though, mostly around “Transparency, Openness, Shared Burden and Vendor Neutrality”. The EFSP organizers, for example, envision collaborative working groups that are vendor-neutral, a certification process that is self-service, and an organization that operates and governs as a meritocracy.
In the JCP, the first step to adding a feature to EE was to create a JSR or Java Specification Request. The JSR was a bit like the interface for an EE feature. The JCP Executive Committee reviewed and approved a completed JSR, and then JSR contributors would code it up and make it available to the community.
And while the community could always weigh in while a specification was under discussion, time showed that an implementation-first approach – like in the case of JSR 310, java.time*, *and Joda Time – tended to create more widely-accepted features and APIs.
So, the EFSP reflects this code-first view in its stated goal: “EFSP will be based on hands-on experimenting and coding first, as a way to prove something is worthy of documenting in a specification.”
Then, as part of the JCP, a JSR needed a reference implementation. This is a bit like the class that implements the interface. A reference implementation helps developers of compatible libraries or other organizations that want to create their own implementation of the spec.
For Java EE features, the JCP used Glassfish for its reference implementations.
And while this centralization on Glassfish simplified the discovery process for implementers, that centralization also required more governance and had a tendency to favor one vendor over another.
Hence, the EFSP doesn’t require a reference implementation, but instead only a compatible implementation. Simply put, this subtle change makes so that implementations inside of a central architecture, like Glassfish, won’t be inadvertently preferred by the foundation.**
Finally, the JCP required that EE features be tested through the Technology Compatibility Kit, or TCK.
The TCK was a suite of tests to validate a specific EE JSR. Simply put, in order to comply with Java EE, an application server needs to implement all of its JSRs and pass all the tests on the designated TCK.
Not much changes here. Oracle open-sourced the TCK as well as the EE JSRs. Of course, all future documents and the TCK will be open-source.
Java EE has certainly evolved a lot during those years. It’s nice to see it continuing to change and improve.
There are many challenges ahead, so let’s hope for a smooth transition.
OpenJDk or Open Java Development Kit is a free, open-source framework of the Java Platform, Standard Edition (or Java SE). It contains the virtual machine, the Java Class Library, and the Java compiler. The difference between the Oracle OpenJDK and Oracle JDK is that OpenJDK is a source code reference point for the open-source model. Simultaneously, the Oracle JDK is a continuation or advanced model of the OpenJDK, which is not open source and requires a license to use.
In this article, we will be installing OpenJDK on Centos 8.
#tutorials #alternatives #centos #centos 8 #configuration #dnf #frameworks #java #java development kit #java ee #java environment variables #java framework #java jdk #java jre #java platform #java sdk #java se #jdk #jre #open java development kit #open source #openjdk #openjdk 11 #openjdk 8 #openjdk runtime environment
Java EE has been transferred to the Eclipse Foundation and Jakarta EE 9.1 is behind us. The next step in the journey is Jakarta EE 10. This write-up outlines some possibilities for Jakarta EE 10 as well as how you can contribute.
There are many ways of contributing to Jakarta EE 10, depending on what your time and interest allow. You can always start simple and get more engaged over time.
#java #java ee #jakarta ee #jakarta ee 10 #guide to contributing to jakarta ee 10
According to some surveys, such as JetBrains’s great survey, Java 8 is currently the most used version of Java, despite being a 2014 release.
What you are reading is one in a series of articles titled ‘Going beyond Java 8,’ inspired by the contents of my book, Java for Aliens. These articles will guide you step-by-step through the most important features introduced to the language, starting from version 9. The aim is to make you aware of how important it is to move forward from Java 8, explaining the enormous advantages that the latest versions of the language offer.
In this article, we will talk about the most important new feature introduced with Java 10. Officially called local variable type inference, this feature is better known as the **introduction of the word **
var. Despite the complicated name, it is actually quite a simple feature to use. However, some observations need to be made before we can see the impact that the introduction of the word
var has on other pre-existing characteristics.
#java #java 11 #java 10 #java 12 #var #java 14 #java 13 #java 15 #verbosity
As you are likely aware, Java EE has transitioned to Open Source governance in the Eclipse Foundation as Jakarta EE. MicroProfile has been moving forward as an independent initiative to optimize enterprise Java for microservices architectures. The Cloud Native for Java (CN4J) Alliance has recently been formed to promote better alignment between Jakarta EE and MicroProfile.
One of the key issues to sort out is how Jakarta EE can consume MicroProfile specifications (such as MicroProfile Configuration). There are several alternatives as to how this could be done. These alternatives were put into a survey for the community to weigh in. In addition to choosing the option respondents believe to be best, they were able to provide comments justifying their preferred alternative. The results of the survey are summarized here. The results have been shared with the CN4J community and key decision-makers.
#java #java ee #jakarta ee #microprofile #jakarta ee/microprofile alignment survey results! #microprofile alignment
Make sure you have installed the following software.
Get the source codes from my github.
#jboss #java-ee #java #jakarta-ee #wildfly #deploying jakarta ee 9 applications to wildfly