Joseph  Norton

Joseph Norton


Java EE vs J2EE vs Jakarta EE

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.

1. History

In the first version of Java, Java enterprise extensions were simply a part of the core JDK.

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).

2. In Transition

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.

*New name announced

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.

3. The Future

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.

3.1. The JCP and Now, the EFSP

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.

3.2. JSRs

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.

A good example of this was JSR-339 – or JAX-RS – which was originally proposed in 2011, approved by JCP in 2012 and finally released in 2013.

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.”

3.3. Glassfish

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.**

3.4. TCK

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.

4. Conclusion

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.


What is GEEK

Buddha Community

Java EE vs J2EE vs Jakarta EE
Tyrique  Littel

Tyrique Littel


How to Install OpenJDK 11 on CentOS 8

What is OpenJDK?

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

Samanta  Moore

Samanta Moore


Guide to Contributing to Jakarta EE 10

This high-level guide outlines some possibilities for Jakarta EE 10 as well as how you can contribute.

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.

Ways of Contributing

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.

  • You can simply follow a Jakarta EE technology that interests you. The easiest way to do that is by subscribing to its mailing list. All the Jakarta mailing lists are available here. We specifically link the mailing lists for some likely key Jakarta EE 10 technologies below. You should feel free to join discussions that interest you. Contributing your opinion as an end-user is one of the most valuable things you can do.
  • If you have a specific feature you would like to advocate for, you should do so on the mailing list to start with. It may be necessary to record an issue detailing the feature if it does not already exist. Each project has a GitHub repository where you can record issues. You should be able to find the issue tracker for projects from here. We specifically link the issue trackers for some likely key Jakarta EE 10 technologies below.
  • If you want to help implement a change in the technology, you should look through the issue trackers and ask to pick up an issue on the mailing list. You can contribute an API change, a TCK change, or a change in one of the technology implementations (such as GlassFishJerseyMojarraOpenMQ, or EclipseLink). Providing a proof-of-concept if you can is a great way to advocate for change (although this is clearly not an expectation from everyone).
  • If you are unsure where to start, just get on a mailing list, introduce yourself and say you want to help. There should be a Jakarta EE Ambassador present to engage you. You can also reach out through the Jakarta EE Ambassadors Google Group.

#java #java ee #jakarta ee #jakarta ee 10 #guide to contributing to jakarta ee 10

Samanta  Moore

Samanta Moore


Going Beyond Java 8: Local Variable Type Inference (var) - DZone Java

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

Samanta  Moore

Samanta Moore


Jakarta EE/MicroProfile Alignment Survey Results!

The results of the Jakarta EE/MicroProfile alignment survey are summarized here.

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

Ray  Patel

Ray Patel


Deploying Jakarta EE 9 applications to WildFly

WildFly 22.0.0.Alph1 provides a standalone preview distribution for Jakarta EE 9.


Make sure you have installed the following software.

  • Java 8 or Java 11
  • Apache Maven 3.6
  • WildFly 22.0.0.Alpha1 Jakarta EE 9 preview

Go to the WildFly Download page, and make sure you are downloading the Jakarta EE 9 preview version.

Get the source codes from my github.

#jboss #java-ee #java #jakarta-ee #wildfly #deploying jakarta ee 9 applications to wildfly