A First Look at Oracle Functions

I am super happy to have gotten the opportunity to test out Oracle Functions through the Cloud Native Limited Availability Program. When I last tried out running serverless functions in Oracle Cloud during the Oracle Groundbreaker APAC Tour last year, there were two options available. Either run my own Fn server in a virtual machine or set it up in a managed Kubernetes cluster. Now, a third option is available!

Oracle Functions is built on Oracle Cloud Infrastructure (OCI) and offer a managed environment for the Fn project. This means that you don’t have to manually manage an Fn cluster yourself. It also means that any function that runs on Oracle Functions will also run on any Fn server, something that offers you full flexibility.

The Fn project supports functions written in Go, Java, Node.js, Python or Ruby. The fn-duke function that I am using in this test is, of course, written in Java.

package eu.agilejava.fn;

public class HelloFunction {

    public String handleRequest(String input) {
        String configuredName = System.getenv("name");
        String name = (input == null || input.isEmpty()) ? configuredName  : input;
        return "Hello, " + name + "\n";
    }
}

package eu.agilejava.fn;

public class HelloFunction {

public String handleRequest(String input) {

String configuredName = System.getenv("name");

String name = (input == null || input.isEmpty()) ? configuredName : input;

return "Hello, " + name + "\n";

}

Deployment is done by pointing to the Function Application you want your function to be part of.

fn deploy --app FunctionDuke

1	fn deploy --app FunctionDuke

The function can be configured through the func.yaml file or using the fn CLI tool as shown here:

fn config function FunctionDuke fn-duke name World

1	fn config function FunctionDuke fn-duke name World

The configured property will then be shown in the detail view in your Oracle Cloud Function Dashboard.

Invoking the function can be done by using the Fn CLI Tool

fn invoke FunctionDuke fn-duke

1	fn invoke FunctionDuke fn-duke

Or by sending a signed request using a convenience script called oci-curl provided by Oracle.

oci-curl "x3vzdahhy3a.us-phoenix-1.functions.oci.oraclecloud.com" get "/t/fn-duke-trigger" -d 'Duke'

1	oci-curl "x3vzdahhy3a.us-phoenix-1.functions.oci.oraclecloud.com" get "/t/fn-duke-trigger" -d 'Duke'

Conclusion

Oracle has made a good choice when investing in the Fn project and use it as a basis for the Oracle Functions platform. It integrates extremely well with Fn and no extra tooling is needed to get started.

November 26, 2018November 26, 2018

Oracle Groundbreaker APAC Tour 2018

This year, I was so lucky to get the chance to be part of the Oracle Groundbreaker APAC Tour 2018. The cities that I joined the tour was Perth and Melbourne in Australia as well as Wellington in New Zealand.

Perth, Australia

In Perth, I did a talk called Serverless with Java. I demoed various FaaS options available, including running Fn Project on Oracle Cloud. Between the sessions, I also managed to slip outside for a swim in the ocean.

Melbourne, Australia

In Melbourne, I had two sessions scheduled. The first was an informal Q&A with the local Java User Group. We had great discussions regarding the 6 months release cadence of Java, we discussed Jakarta EE and Eclipse MicroProfile and talked about Java development and Java user groups in general.

Later that afternoon, I did my Serverless with Java talk for a small, but an enthusastic crowd.

Wellington, New Zealand

The last stop on the journey was Wellington, New Zealand. Even here, it was the Serverless with Java talk that was put on the schedule.

To spice things up a little, I did a last minute try to get fn up and running on a managed Kubernetes cluster in Oracle Cloud Infrastructure.

I was close, so the next time I do this talk this will be part of the demos…

Wrap up

This was a fantastic trip, even considering the busy travel schedule and probably spending more time in the air or at airports than on the ground. The trip home from Wellington took ~36 hours door-to-door with short layovers in Auckland, Perth, and Singapore.

Source Code

The Function Duke project on GitHub contains all the source code for my serverless talks.

November 14, 2018November 14, 2018

While Waiting for Jakarta EE

It is more than a year since Oracle announced the transfer of Java™ EE to Eclipse Foundation at JavaOne 2017. Since then, a lot has happened:

Java™ EE 8 API and implementation projects have been set up under EE4J.
The Eclipse GlassFish 5.1 release is approaching.
A brand new Jakarta EE specification process is right around the corner.
Community shows involvement regarding the technical direction of Jakarta EE.
The Jakarta EE NoSQL specification project proposal has been created.

This is all very good, excellent actually! When you think about the size of it all, it is actually quite an achievement. We are talking about 7.7 million lines of code! More than 60.000 files and a total of 38 new projects that have been set up at the Eclipse Foundation.

But, as everyone knows, developers are impatient and eager to try out everything new, so there are still a couple of questions that I always get when talking about Jakarta EE:

When can I start developing Jakarta EE applications?
How does Eclipse MicroProfile fit in this picture?

The answer to the first question is: “not yet”. Until the Jakarta EE specification process is finalized, the technologies are still Java™ EE.

The answer to the second question differs a little depending on who you ask, but usually is something in the lines of “I am pretty sure that some of the MicroProfile specs will be integrated into Jakarta EE when they have proven to be useful”.

So, what should an eager developer do in the meantime? Switch to Spring Boot…ouch…or…JavaScript…squeal…?

NO, here is what you should do: Use the power of Java™ EE 8 and combine it with Eclipse MicroProfile.

Many of the application server vendors have added MicroProfile features to their Java™ EE 8 compliant or certified application servers. Examples are Open Liberty, WildFly, Payara and Apache TomEE. See the respective vendor’s documentation for which versions they have included.

I have put together a simple application called Jakarta EE Duke to demonstrate how to do this. The application uses the @ConfigProperty annotation from MicroProfile Config to configure a message as well as the new @Email annotation from Bean Validation 2.0, which came with Java™ EE 8 to validate input.

While this example is extremely simple, it does indicate how you can combine the full power of Java™ EE 8 with the lightweight APIs of MicroProfile to implement cloud-native microservices using Java™ technology.

One last tip: Make sure to join the Jakarta EE Community Mailing list to always stay up-to-date on the latest development of Jakarta EE.

April 24, 2018

Setting sails for Jakarta EE!

The future of Cloud Native Java with Jakarta EE is here! The Jakarta EE website was launched today with lots of information, news and resources, including the new results of the 2018 Developer Survey.I even got my blog posts about the relationship between Jakarta EE, EE4J and Java EE listed in FAQ section. The website even features the new Jakarta EE logo.

I should be honest and say that it wasn’t my first choice when I voted, but when I see it in use with different colors and backgrounds, I must admit that it looks pretty good.

The initial strategic and participating members of the Jakarta EE working group are also listed on the website.

It is pretty awesome to see this list of companies participating and supporting Jakarta EE! And the list is likely to expand as more companies join. The future of Cloud Native Java is Jakarta EE, and the future looks bright. Let’s set the sails and sail towards the future (finally got the logo, I think…).

https://jakarta.ee

March 22, 2018March 22, 2018

KumuluzEE on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Kumuluz EE über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Kumuluz EE version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -Dkumuluzee.server.http.port=$PORT -jar cloudee-duke.jar",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Kumuluz EE"
}

{

"runtime": {

"majorVersion": "8"

"command": "java -Dkumuluzee.server.http.port=$PORT -jar cloudee-duke.jar",

"release": {

"version": "1.0",

"build": "1",

"commit": "123"

"notes": "Dukes says hello from Kumuluz EE"

}

You need to specify the port for Kumuluz EE in the startup command. This is done by using the $PORT environment variable.

The über-jar is produced by using the Kumuluz Maven Plugin:

<plugin>
    <groupId>com.kumuluz.ee</groupId>
    <artifactId>kumuluzee-maven-plugin</artifactId>
    <version>${version.kumuluz}</version>
    <executions>
        <execution>
            <id>package</id>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<groupId>com.kumuluz.ee</groupId>

<artifactId>kumuluzee-maven-plugin</artifactId>

<version>${version.kumuluz}</version>

<id>package</id>

<goals>

<goal>repackage</goal>

</goals>

</execution>

</executions>

</plugin>

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package assembly:single -Pkumuluz

1	mvn clean package assembly:single -Pkumuluz

This will produce a file called cloudee-duke-oracle-kumuluz.zip in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE base:gc_ps_mark_sweep_count counter
# HELP base:gc_ps_mark_sweep_count Displays the total number of collections that have occurred. This attribute lists -1 if the collection count is undefined for this collector.
base:gc_ps_mark_sweep_count{serviceVersion=”1.0.0″,environment=”dev”,instanceId=”110cd814-3d12-4198-80eb-694196f58993″,serviceName=”UNKNOWN”} 2
# TYPE base:classloader_total_loaded_class_count counter

March 22, 2018March 22, 2018

Liberty on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Liberty über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Liberty version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -jar cloudee-duke.jar",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Liberty"
}

{

"runtime": {

"majorVersion": "8"

"command": "java -jar cloudee-duke.jar",

"release": {

"version": "1.0",

"build": "1",

"commit": "123"

"notes": "Dukes says hello from Liberty"

}

You need to specify the port for Liberty to use. This cam be done by configuring it in the server.xml using the environment variable ${env.PORT} as shown here:

<server description="Sample Liberty server">
    <featureManager>
        <feature>microprofile-1.2</feature>
    </featureManager>

    <httpEndpoint  httpPort="${env.PORT}" 
                   httpsPort="9443"
                   id="defaultHttpEndpoint" 
                   host="*" />

    <quickStartSecurity userName="duke" userPassword="duke"/>

    <keyStore id="defaultKeyStore" password="Liberty"/>
</server>

<feature>microprofile-1.2</feature>

</featureManager>

<httpEndpoint httpPort="${env.PORT}"

httpsPort="9443"

id="defaultHttpEndpoint"

host="*" />

</server>

The über-jar is produced by using a combination of the Maven Resources Plugin as well as the Liberty Maven Plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <version>3.0.2</version>
    <executions>
        <execution>
            <id>copy-app</id>
            <phase>package</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/liberty/wlp/usr/servers/defaultServer/dropins</outputDirectory>
                <resources>
                    <resource>
                        <directory>${project.build.directory}</directory>
                        <includes>
                            <include>${project.build.finalName}.war</include>
                        </includes>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>net.wasdev.wlp.maven.plugins</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>2.2</version>
    <extensions>true</extensions>
    <configuration>
        <install>
            <type>webProfile7</type>
            <version>2018.+</version>
        </install>
        <configFile>${basedir}/src/main/liberty/config/server.xml</configFile>
        <serverEnv>${basedir}/src/main/liberty/config/server.env</serverEnv>
        <jvmOptionsFile>${basedir}/src/main/liberty/config/jvm.options</jvmOptionsFile>
        <packageFile>${project.build.directory}/${project.build.finalName}.jar</packageFile>
        <include>runnable</include>
    </configuration>     
    <executions>
        <execution>
            <id>install-liberty</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>install-server</goal>
            </goals>
        </execution>
        <execution>
            <id>package-app</id>
            <phase>package</phase>
            <goals>
                <goal>package-server</goal>
            </goals>
        </execution>
    </executions>               
</plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-resources-plugin</artifactId>

<phase>package</phase>

<goals>

<goal>copy-resources</goal>

</goals>

<outputDirectory>${project.build.directory}/liberty/wlp/usr/servers/defaultServer/dropins</outputDirectory>

<directory>${project.build.directory}</directory>

<include>${project.build.finalName}.war</include>

</includes>

</resource>

</resources>

</configuration>

</execution>

</executions>

</plugin>

<groupId>net.wasdev.wlp.maven.plugins</groupId>

<artifactId>liberty-maven-plugin</artifactId>

<type>webProfile7</type>

</install>

<configFile>${basedir}/src/main/liberty/config/server.xml</configFile>

<serverEnv>${basedir}/src/main/liberty/config/server.env</serverEnv>

<jvmOptionsFile>${basedir}/src/main/liberty/config/jvm.options</jvmOptionsFile>

<packageFile>${project.build.directory}/${project.build.finalName}.jar</packageFile>

<include>runnable</include>

</configuration>

<id>install-liberty</id>

<phase>prepare-package</phase>

<goals>

<goal>install-server</goal>

</goals>

</execution>

<id>package-app</id>

<phase>package</phase>

<goals>

<goal>package-server</goal>

</goals>

</execution>

</executions>

</plugin>

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package assembly:single -Pliberty

1	mvn clean package assembly:single -Pliberty

This will produce a file called cloudee-duke-oracle-liberty.zip in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE base:classloader_total_loaded_class_count counter
# HELP base:classloader_total_loaded_class_count Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
base:classloader_total_loaded_class_count 9430
# TYPE base:cpu_system_load_average gauge
…

March 22, 2018

Payara Micro on Oracle Application Container Cloud

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a Payara Micro über-jar to Oracle Application Container Cloud.

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The Payara Micro version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -jar cloudee-duke-microbundle.jar --port $PORT",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Payara"
}

{

"runtime": {

"majorVersion": "8"

"command": "java -jar cloudee-duke-microbundle.jar --port $PORT",

"release": {

"version": "1.0",

"build": "1",

"commit": "123"

"notes": "Dukes says hello from Payara"

}

You need to specify the port for Payara Micro in the startup command. This is done by using the $PORT environment variable.

The über-jar is produced by using the Payara Micro Maven Plugin:

<plugin>
    <groupId>fish.payara.maven.plugins</groupId>
    <artifactId>payara-micro-maven-plugin</artifactId>
    <version>1.0.1-SNAPSHOT</version>
    <executions>
        <execution>
            <goals>
                <goal>bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <payaraVersion>${version.payara.micro}</payaraVersion>
        <autoDeployEmptyContextRoot>true</autoDeployEmptyContextRoot>
    </configuration>
</plugin>

<groupId>fish.payara.maven.plugins</groupId>

<artifactId>payara-micro-maven-plugin</artifactId>

<version>1.0.1-SNAPSHOT</version>

<goals>

<goal>bundle</goal>

</goals>

</execution>

</executions>

<payaraVersion>${version.payara.micro}</payaraVersion>

</configuration>

</plugin>

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package payara-micro:bundle assembly:single -Ppayara

1	mvn clean package payara-micro:bundle assembly:single -Ppayara

This will produce a file called cloudee-duke-oracle-payara.zip in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# TYPE vendor:system_cpu_load gauge
# HELP vendor:system_cpu_load Display the “recent cpu usage” for the whole system. This value is a double in the [0.0,1.0] interval. A value of 0.0 means that all CPUs were idle during the recent period of time observed, while a value of 1.0 means that all CPUs were actively running 100% of the time during the recent period being observed. All values betweens 0.0 and 1.0 are possible depending of the activities going on in the system. If the system recent cpu usage is not available, the method returns a negative value.
vendor:system_cpu_load 0.005405405405405406
…

March 22, 2018April 3, 2018

WildFly Swarm on Oracle Application Container Cloud

UPDATED!

In this blog post, I will describe how to deploy the CloudEE Duke application packaged in a WildFly Swarm über-jar to Oracle Application Container Cloud.

Über-jar approach

The deployment artifact required for deployment in Oracle Application Container Cloud is a ZIP archive containing the application über-jar and a manifest file (manifest.json). The WildFly Swarm version of the manifest.json for CloudEE Duke is listed below.

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -Dswarm.http.port=$PORT -Dswarm.bind.address=$HOSTNAME -jar cloudee-duke-swarm.jar",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Swarm"
}

{

"runtime": {

"majorVersion": "8"

"command": "java -Dswarm.http.port=$PORT -Dswarm.bind.address=$HOSTNAME -jar cloudee-duke-swarm.jar",

"release": {

"version": "1.0",

"build": "1",

"commit": "123"

"notes": "Dukes says hello from Swarm"

}

You need to specify the port and host for WildFly Swarm in the startup command. This is done by using the $PORT and $HOSTNAME environment variables.

The über-jar is produced by using the WildFly Swarm Maven Plugin:

<plugin>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-plugin</artifactId>
    <version>${version.wildfly.swarm}</version>
    <executions>
        <execution>
            <goals>
                <goal>package</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<groupId>org.wildfly.swarm</groupId>

<artifactId>wildfly-swarm-plugin</artifactId>

<version>${version.wildfly.swarm}</version>

<goals>

<goal>package</goal>

</goals>

</execution>

</executions>

</plugin>

Hollow-jar approach

It is also possible to package the CloudEE Duke application as a hollow-jar using the WildFly Swarm Maven Plugin:

<plugin>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-plugin</artifactId>
    <version>${version.wildfly.swarm}</version>
    <executions>
        <execution>
            <goals>
                <goal>package</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <hollow>true</hollow> <!-- Tells the plugin to produce a hollow-jar rather than a über-jar -->
    </configuration>
</plugin>

<groupId>org.wildfly.swarm</groupId>

<artifactId>wildfly-swarm-plugin</artifactId>

<version>${version.wildfly.swarm}</version>

<goals>

<goal>package</goal>

</goals>

</execution>

</executions>

</configuration>

</plugin>

The command configuration in the manifest.json needs to be updated accordingly:

{
    "runtime": {
        "majorVersion": "8"
    },
    "command": "java -Dswarm.http.port=$PORT -Dswarm.bind.address=$HOSTNAME -jar cloudee-duke-hollow-swarm.jar cloudee-duke.war",
    "release": {
        "version": "1.0",
        "build": "1",
        "commit": "123"
    },
    "notes": "Dukes says hello from Swarm"
}

{

"runtime": {

"majorVersion": "8"

"command": "java -Dswarm.http.port=$PORT -Dswarm.bind.address=$HOSTNAME -jar cloudee-duke-hollow-swarm.jar cloudee-duke.war",

"release": {

"version": "1.0",

"build": "1",

"commit": "123"

"notes": "Dukes says hello from Swarm"

}

When using the hollow-jar approach, you will need to package both the hollow-jar and the application-war in the zip file together with the manifest.json file.

See the complete pom.xml for an example on how to produce the deployable ZIP archive with the maven command:

mvn clean package assembly:single -Pswarm

1	mvn clean package assembly:single -Pswarm

This will produce a file called cloudee-duke-oracle-swarm.zip in the target folder. This is the ZIP archive you will deploy to Oracle Application Container Cloud as shown in the screenshot below.

When your application is deployed, you should be able to access the hello endpoint

https://<dependsonyouraccount>.oraclecloud.com/hello
Duke says Hello!

You will also have the health and metrics endpoints provided by the MicroProfile implementation

https://<dependsonyouraccount>.oraclecloud.com/health
{
outcome: “UP”,
checks: [ ]
}

https://<dependsonyouraccount>.oraclecloud.com/metrics
# HELP base:classloader_total_loaded_class_count Displays the total number of classes that have been loaded since the Java virtual machine has started execution.
# TYPE base:classloader_total_loaded_class_count counter
base:classloader_total_loaded_class_count 14170.0
…

March 22, 2018March 22, 2018

Running Eclipse MicroProfile on Oracle Cloud

Since I joined the Oracle Developer Champions, I have played around with running MicroProfile applications on Oracle Cloud. Specifically the Oracle Application Container Cloud which allows you to run applications on platforms such as Java™ SE, Java™ EE, Node.js, PHP, Python, Ruby, .NET Core or Go.

MicroProfile is based on Java EE technologies, so the core functionality of the service will run fine on the Java™ EE platform offered. But since WebLogic does not implement the MicroProfile APIs, such as Config, Health Check, Metrics, etc., running on the Java™ SE platform is a much better option.

I have created a simple application called CloudEE Duke to show the differences in configuration required for the various MicroProfile implementations in order to run them on Oracle Application Container Cloud. So far I have covered WildFly Swarm, Payara Micro, Liberty and Kumuluz EE. More may follow. I plan to describe each of them in a series of blog posts following this one. I will update the list below with links to the posts as soon as they are written.

WildFly Swarm on Oracle Application Container Cloud
Payara Micro on Oracle Application Container Cloud
Liberty on Oracle Application Container Cloud
Kumuluz EE on Oracle Application Container Cloud

My plan is to create similar blog series for the other cloud providers as well.

March 22, 2018

The Relationship Between Jakarta EE, EE4J and Java EE

The Jakarta EE name has been out for about a month, and even if Mike Milinkovich explained the names and concepts pretty well in his blog post And the Name Is…, there still is a bit confusion about how it all relates and I get questions around it whenever the topic comes up. I have tried to sum up some of it here. Hope it helps!

Java EE

Java EE, or Java™ Platform, Enterprise Edition, is the name of the current platform governed by the Java Community Process (JCP). The latest version is Java EE 8, which was released in September 2017.

Jakarta EE

Jakarta EE is the name of the platform governed by the Jakarta EE Working Group. The first version will be Jakarta EE 8 which will be based on the Java EE 8 technologies transferred from Oracle to the Eclipse Foundation.

EE4J

Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.

Summing Up

Jakarta EE does not replace Java EE! It is the name for the platform evolving with Java EE 8 as a starting point. Java EE 8 will still exist, but there will not be any new versions of the platform.

Jakarta EE does not replace EE4J! It is the name of the platform based on the EE4J projects with Java EE 8 as a starting point.

agilejava.eu

by Ivar Grimstad

Oracle

A First Look at Oracle Functions

Conclusion

Setting sails for Jakarta EE!

https://jakarta.ee

The Relationship Between Jakarta EE, EE4J and Java EE

Java EE

Jakarta EE

EE4J

Summing Up