The Java specification included Java SE and Java EE, but Java EE left the Oracle initiative and was donated to the Eclipse Foundation. Taking this opportunity, it became impossible to call the specification Java EE, and the specification name was changed to Jakarta EE. (There were twists and turns, but if you just break it down and just conclude, it looks like this)
--Jakarta EE site - https://jakarta.ee/
Since becoming Jakarta EE, there are Jakarta EE8, which has become almost a mirror of Java EE8, and Jakarta EE9, which was released this December.
--Jakarta EE 9 release page - https://jakarta.ee/release/9/
The Jakarta EE 9 page states that it has three characteristics.
lower entry barriers ――This is because there are some application servers (such as WebLogic and JBoss) that meet the Java EE specifications in the past, but they are fixed vendors and fixed products. In the past, a test case tool called TCK that checks the Java EE specifications was not open to the public. By becoming Jakarta EE, the concept is to lower the barrier to becoming a new application server by publishing this TCK as well.
foundation for innovation ――I dare to express the part that has a big influence like this, but it was transferred from Oracle to the Eclipse Foundation, but I did not allow modification or addition of the one in the javax package. ――In response to that, I decided to abandon javax and rename it to jakarta. ――There was a debate about whether to change the existing ones as they are, but it is not desirable to use them properly from the user's point of view, so we decided to send them to jakarta including the existing ones. ――Next, there was a debate about whether to bring it to jakarta step by step or to bring it all at once, and it was concluded that this should also be brought to Jakarta at once to avoid confusion. ――So, in this version, we have come up with this concept with the intention of moving from javax to the package name jakarta (called the Big Bang release).
easy migration ――As mentioned earlier, migrating to jakartaee 9 is difficult because you have to use the package name jakarta. ――At that time, there is also a concept that makes it easy to migrate. --Specifically, it is a specification that a tool for converting the above package name will be prepared. ――There is one demon gate for this, and it may be different depending on the application server whether it is a tool that is converted at compile time or a tool that is converted at deployment time. When diverting existing source code or OSS and putting it on a Jakarta EE9 based application server, if it includes libraries such as OSS, it is quite critical if it is not converted at deployment time.
The Jakarta EE homepage lists compatible application servers, but for now it's only GlassFish.
--Page that lists supported application servers - https://jakarta.ee/compatibility/#tab-9
And when I go to the GlassFish page (https://github.com/eclipse-ee4j/glassfish/releases), at the moment (2020/12/20), I can only download up to 6.0.0-RC3. Yes, even though Jakarta EE 9 has been released (specification released), the corresponding GlassFish has not been released as an official version. That wasn't the case with JavaEE. Let's understand that it's not that Glassfish's development speed has slowed down, but that the specification has been released faster (no longer concerned with simultaneous releases). .. ..
If you download this GlassFish 6.0.0-RC3 and unzip it, you can use it as an ordinary application server called GlassFish.
\$ java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment Corretto-8.275.01.1 (build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM Corretto-8.275.01.1 (build 25.275-b01, mixed mode)
\$ tree . | head -30
.
├── META-INF
│ ├── LICENSE.md
│ └── NOTICE.md
├── README.txt
├── bin
│ ├── asadmin
│ ├── asadmin.bat
│ ├── debug-asadmin
│ └── debug-asadmin.bat
├── glassfish
│ ├── bin
│ │ ├── appclient
│ │ ├── appclient.bat
│ │ ├── appclient.js
│ │ ├── asadmin
│ │ ├── asadmin.bat
│ │ ├── capture-schema
│ │ ├── capture-schema.1m
│ │ ├── capture-schema.bat
│ │ ├── jspc
│ │ ├── jspc.bat
│ │ ├── package-appclient
│ │ ├── package-appclient.bat
│ │ ├── schemagen
│ │ ├── schemagen.bat
│ │ ├── startserv
│ │ ├── startserv.bat
│ │ ├── stopserv
│ │ ├── stopserv.bat
//When starting
sh bin/asadmin start-domain
Note that this version only works with Java 8. The first version of JakartaEE 9 was not in time for Java 11. .. Therefore, Jakarta EE 9 needs to run on Java 8. We plan to support Java 11 with a minor version upgrade called Jakarta EE 9.1.
--Draft for JakartaEE 9.1 - https://www.agilejava.eu/2020/12/18/planning-for-jakarta-ee-9-1/
Set Jakarta EE9 in maven's pom.xml as follows
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.0.0</version>
<scope>provided</scope>
</dependency>
With this setting, you can develop based on Jakarta EE 9. As I explained earlier, Jakarta EE9 includes a Big Bang release from javax to the jakarta package, so javax cannot be used. .. ..
Therefore, you can compile by changing javax to jakartaee.
Now that the compilation is successful, you can confirm the operation by deploying to Glassfish.
By the way, what happens if you set the version to 8.0.0 on pom.xml, compile and build with the package name as javax, and deploy to Glassfish 6.0.0 RC3? The deployment itself does not cause an error, but the javax annotations are ignored. It's a little half-hearted movement, but does it mean that it has been made more flexible? .. Please see this video (https://www.youtube.com/watch?v=aSIQ6ONKJWs) for details on Glassfish6.0.
I thought that the official version of Glassfish 6.0.0 would be out around here, but it wasn't out yet. .. The West has already entered the Christmas holidays, so is it the beginning of the year? I would like to look forward to it.
--Source code used - https://github.com/omix222/jee9demo
Recommended Posts