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

Java EE 8 with Eclipse MicroProfile 2.1

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.

Eclipse GlassFish Release Plan

UPDATED!

Yesterday, the release plan for Eclipse GlassFish was announced on the EE4J mailing list. For convenience, I have repeated the plan here:

September 18
All code required for GF build contributed.

September 23
Eclipse GlassFish builds.

October 1
Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.

October 22 ⚡
CI/CD release pipelines completed.

October 22
Eclipse GlassFish 5.1-RC1 milestone release.

November 5 ⚡
Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.

November 30 ⚡
Release Review completed.

December 14 ⚡
Eclipse GlassFish 5.1 release. All CTS tests are passed.

There is a lot of work to do, so every contribution is appreciated, especially regarding setting up the CI/CD pipelines for all the EE4J projects. Take a look at our status sheet and sign up where you think you can contribute.

Running Eclipse MicroProfile on IBM Cloud

In this post, I am following up on the post series about Running Eclipse MicroProfile applications in Oracle Cloud by showing how to do it in IBM Cloud Foundry, which includes runtimes for Java, Node.js, ASP.NET Core, PHP, Python, Ruby, Swift and Go.

I am using the same simple application called CloudEE Duke as in the previous posts and will show how to deploy it in the Liberty for Java™ runtime. Since the liberty  profile is it is already configured to build using the Liberty Maven Plugin, the only thing you need to do is to activate this profile:

mvn clean package -Pliberty

See the complete pom.xml to see the complete configuration.

Since CloudEE Duke is an Eclipse MicroProfile application, you need to use the packaged server deployment option in order to activate the required features of Liberty. This is done by running the server package  command from the Liberty server directory produced by the Liberty Maven Plugin.

target/liberty/wlp/bin/server package defaultServer --include=usr

The server package  command produces a .zip file that can be pushed to IBM Cloud with the Cloud Foundry CLI as shown here:

cf push cloudee-duke -p target/liberty/wlp/usr/servers/defaultServer/defaultServer.zip

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

https://cloudee-duke.eu-gb.mybluemix.net/hello
Duke says Hello!

As ususal, you will also have the health and metrics endpoints provided by the MicroProfile implementation

https://cloudee-duke.eu-gb.mybluemix.net/health
{
outcome: “UP”,
checks: [ ]
}

https://cloudee-duke.eu-gb.mybluemix.net/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 10744
# TYPE base:gc_global_count counter

Run and Debug a WildFly Swarm application from NetBeans

Java EE developers using NetBeans are used to be able to run and debug their thin-war applications in their application server of choice directly from NetBeans. When developing microservices packaged as über-or hollow-jars, you expect the same effortless way of running and debugging. The good news is that you can. In this post, I show step-by-step how to run and debug the WildFly Swarm version of CloudEE Duke in NetBeans.

Run WildFly Swarm application

The easiest way of running CloudEE Duke in NetBeans is to edit the Run project action for the project. Right click on CloudEE Duke, select properties and Actions as shown below.

Configure the Execute Goals to package wildfly-swarm:run, remove all the default properties and your’re all set. Run Project (F6 ) will start the application using the WildFly Swarm Maven Plugin.

Debug WildFly Swarm Appliction

To enable debugging, you follow the same steps as described above, but in this case it is the Debug Project action you select.

Execute Goals is configured the same way as for Run, but in the Set Properties, you need to configure a debug port for WildFly Swarm. This is done by setting the swarm.debug.port property, e.g. to 9000.

Debug Project Ctrl-F5 will start the application in debug mode. Note that the execution will halt while waiting for the debugger to attach. See the screenshot below for how it will look in the log.

Select Debug->Attach Debugger from the menu in NetBeans. Change the value for Port to 9000 (or the value you chose in the previous step) and click OK.

To verify the setup, set a breakpoint at line 16 in the class HelloWorldEndpoint.

Then navigate to http://localhost:8080/hello. The execution will stop at the breakpoint at line 16 in HelloWorldEndpoint.

Running Eclipse MicroProfile on Microsoft Azure

In this post, I am following up on the post series about Running Eclipse MicroProfile applications in Oracle Cloud by showing how to do it in Microsoft Azure Web Apps for Containers.

I am using the same simple application called CloudEE Duke as in the previous posts. The only difference is that I now package the applications as Docker Images. In this example, I show how to use the fabric8 Maven Plugin to produce a docker image for WildFly Swarm.

<plugin>
    <groupId>io.fabric8</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>${version.docker-maven-plugin}</version>
    <configuration>
        <images>
            <image>
                <alias>${project.artifactid}</alias>
                <name>ivargrimstad/${project.artifactId}:swarm</name>
                <build>
                    <maintainer>Ivar Grimstad (ivar.grimstad@gmail.com)</maintainer>
                    <from>jboss/base-jdk:8</from>
                    <assembly>
                        <basedir>/</basedir>
                        <inline>
                            <files>
                                <file>
                                    <source>${project.build.directory}/${project.build.finalName}-hollow-swarm.jar</source>
                                    <outputDirectory>/opt</outputDirectory>
                                </file>
                                <file>
                                    <source>${project.build.directory}/${project.build.finalName}.war</source>
                                    <outputDirectory>/opt</outputDirectory>
                                </file>
                            </files>
                        </inline>                                   
                    </assembly>       
                    <entryPoint>
                        <arg>java</arg>
                        <arg>-Djava.net.preferIPv4Stack=true</arg>
                        <arg>-jar</arg>
                        <arg>/opt/${project.build.finalName}-hollow-swarm.jar</arg>  
                        <arg>/opt/${project.build.finalName}.war</arg>  
                    </entryPoint>
                </build>
            </image>
        </images>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The configuration is similar for the other Eclipse MicroProfile implementations. See the full pom.xml for examples. To produce the docker image for the WildFly Swarm implementation of CloudEE Duke, use the following command:

mvn clean package docker:build -Pswarm

Once the image is produced, you need to publish it to a container registry. In my case I simply push it to my public Docker Hub.

In order to deploy the CloudEE Duke application in Microsoft Azure, log in to your Azure Portal and create a new Web App for Containers as shown below.

Since WildFly Swarm runs on port 8080 by default (and I am using all defaults here), the port number for the application needs to be configured. This can be done either in the UI, or using Cloud Shell as shown here:

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

https://cloudee-duke-swarm.azurewebsites.net/hello
Duke says Hello!

https://cloudee-duke-swarm.azurewebsites.net/health
{
outcome: “UP”,
checks: [ ]
}

https://cloudee-duke-swarm.azurewebsites.net/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 13697.0

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.

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.

Flying High with Oracle Cloud

I recently joined the Oracle Developer Champion Program, and one of the benefits is that I get free credits to try out the various services offered by Oracle Cloud. As you see in the picture below, the credits just poured down on me yesterday 🙂

Will this hurt my reputation of being unbiased and vendor neutral when I talk about technologies?

Well, I certainly hope not! In that case, it should probably have gone long time ago since I already get free credits from other vendors, such as AWS, Microsoft Azure, Google, and more. The way I see it, is that it is an excellent opportunity to try out the different solutions and give them a fair comparison.

Stay tuned for more…

 

Promoting EE4J at Jfokus

During the opening keynote of Jfokus, I was invited up on the big stage to be interviewed about the future of Java EE and my role in the Java community.

The video from the Keynote will probably be available shortly, so I will not repeat everything here word-for-word (even if I could…).

The first topic was the Java Community Process Executive Committe and we talked about how the EC guides the evolution of Java™ technology in the Java Community Process.

The next topic was about the Eclipse Enterprise for Java Project Management Committee and how to get involved in participating in the development of Java EE technologies within EE4J. I will encourage everyone that is interested in following what is going on there to join the ee4j-community mailing list.

My vote goes to Jakarta EE !

I could probably write a long post about why my vote goes to Jakarta EE in the vote for new brand name to take over after Java EE, but it feels much more appropriate to refer to David Blevin‘s excellent description of the process in his blog post Java EE to Jakarta EE.

It has been tough on us keeping these discussions secret since we are all working for an open community and want to share everything. But the importance of securing a name that we as a community can trademark through the Eclipse Foundation makes it well worth the efforts.

A particular think I like about the Jakarta EE name is the significance of Apache Software Foundation and Eclipse Foundation working together for the best of the community.