Cool Stuff

Javaforum Malmø – May 2025

The second event of Javaforum Malmø took place this Monday. We were fortunate enough to have Artur Skowroński visit us and talk about JVM in the Age of AI. Those present experienced a fast-paced presentation that gave a complete overview of all the different projects and initiatives going on to make Java the number one choice for anything related to AI. If you missed it, check out the recording when it is made available by Foo Café.

Join our mailing list and follow us on Bluesky to stay up-to-date about what’s going on in the Java community in Malmö. This is also where information about our events is published.

Follow to stay informed about what's going on in the Malmö Java User Group. And make sure to join our mailing listgroups.google.com/g/javaforum-…#Javaforum #MalmoJUG #Communiyt #Java

— Malmö JUG (@javaforum.bsky.social) 2025-05-07T10:48:10.537Z

Jakarta EE 11 is Shaping Up!

This article was first published in the August 2023 Eclipse Foundation Newsletter.

The work on defining the next major update of Jakarta EE has been going on for a while. Back in January 2023, the Jakarta EE Working Group Steering Committee defined the high-level guidelines for Jakarta EE 11. One of the items in these guidelines was to target Java 21. To accommodate this, the runtimes implementing Jakarta EE 11 will be tested on Java 21.

The Steering Committee is looking to establish a regular cadence of Jakarta EE releases approximately six months after a Java LTS release. With Java 21 scheduled for release in September 2023, the target date for Jakarta EE 11 is H1 2024.

The overall theme for Jakarta EE 11 is Performance and Developer Productivity. Some specifications will need to make API changes to support language features introduced between Java 11 and Java 21, specifically: Virtual Threads and Records. With this release, Jakarta EE will continue becoming more CDI-centric and more streamlined.

Specification Updates

The following specifications will all have updated versions for Jakarta EE 11. Each of them is described in more detail below.

  • Jakarta Annotations 3.0
  • Jakarta Authentication 3.1
  • Jakarta Authorization 3.0
  • Jakarta Bean Validation 3.1
  • Jakarta Concurrency 3.1
  • Jakarta Contexts and Dependency Injection 4.1
  • Jakarta Expression Language 6.0
  • Jakarta Faces 5.0
  • Jakarta Interceptors 2.2
  • Jakarta Pages 4.0
  • Jakarta Persistence 3.2
  • Jakarta RESTful Web Services 4.0
  • Jakarta Security 4.0
  • Jakarta Servlet 6.1
  • Jakarta WebSocket 2.2


Three additional specifications are candidates for inclusion in Jakarta EE 11. At the time of writing, the inclusion of the following specifications is being discussed in the Jakarta EE Platform project:

  • Jakarta Data 1.0
  • Jakarta MVC 3.0
  • Jakarta NoSQL 1.0

Out of these, Jakarta Data is most likely to be included in Jakarta EE 11. Jakarta MVC and Jakarta NoSQL will then continue as independent specifications outside of the Platform.

The figure below shows an overview of how Jakarta EE 11 will look if these predictions fall through.

As you can see in the figure, about half of the specifications of the Jakarta EE Platform will be updated in Jakarta EE 11. Let’s look at the changes planned for each of the specifications.

Jakarta Annotations 3.0

The purpose of Jakarta Annotations 3.0 is to fully remove the deprecated @ManagedBeans annotation.

More details at: https://jakarta.ee/specifications/annotations/3.0/

Jakarta Authentication 3.1

Jakarta Authentication 3.1 will contain minor updates to support the overall goals of Jakarta Security. The changes include clarifications around state and concurrency as well as the removal of all references to the SecurityManager.

More details at: https://jakarta.ee/specifications/authentication/3.1/

Jakarta Authorization 3.0

The primary goal of Jakarta Authorization 3.0 is to future-proof the specification and make it more suitable for cloud deployments. This will be achieved by adding an API for programmatically registering policy providers, creating a replacement for java.security.Policy, and removing all references to the SecurityManager.

More details at: https://jakarta.ee/specifications/authorization/3.0/ 

Jakarta Bean Validation 3.1 

Jakarta Bean Validation 3.1 will add support for Java Records. Records are classes that act as transparent carriers for immutable data and were introduced by JEP 395 in Java 16.  Jakarta Bean Validation is also currently in the process of being renamed to Jakarta Validation.

More details at: https://jakarta.ee/specifications/bean-validation/3.1/ 

Jakarta Concurrency 3.1

The most significant feature of Jakarta Concurrency 3.1 is adding integration to Virtual Threads. Virtual Threads are lightweight threads and were introduced by JEP 444 in Java 21. Other changes in this release of Jakarta Concurrency are taking further steps toward being more CDI-centric.

More details at: https://jakarta.ee/specifications/concurrency/3.1/ 

Jakarta Contexts and Dependency Injection 4.1

The main objective of Jakarta Contexts and Dependency Injection 4.1 is to address several minor issues in the Specification, APIs, and TCK.

More details at: https://jakarta.ee/specifications/cdi/4.1/

Jakarta Expression Language 6.0

Jakarta Expression Language 6.0 makes the dependency on the java.desktop module optional. It also removes the references to the SecurityManager, as well as a small number of enhancements.

More details at: https://jakarta.ee/specifications/expression-language/6.0/

Jakarta Faces 5.0

Jakarta Faces 5.0 removes references to the SecurityManager and continues the alignment with CDI. This release also splits out the API into its own project.

More details at: https://jakarta.ee/specifications/faces/5.0/

Jakarta Interceptors 2.2

Jakarta Interceptors 2.2 is a minor update that adds a standard accessor to interceptor bindings. 

More details at: https://jakarta.ee/specifications/interceptors/2.2/

Jakarta Pages 4.0

Jakarta Pages 4.0 removes functionality that was deprecated in previous releases, as well as updates to align with Jakarta Servlet 6.1 and Jakarta Expression Language 6.0.

More details at: https://jakarta.ee/specifications/pages/4.0/

Jakarta Persistence 3.2

The Jakarta Persistence 3.2 release comes with a lot of goodies for developers, including: 

  • Java Records will be usable as an embeddable type
  • Added support for subqueries
  • Programmatic schema management
  • Stateless SecurityManager
  • A wide range of additional functions and operators

This version also deprecates support for java.util.Calendar, java.util.Date, java.SQL.Time, and java.SQL.Timestamp.

More details at: https://jakarta.ee/specifications/persistence/3.2/

Jakarta RESTful Web Services 4.0

The goal of Jakarta RESTful Web Services 4.0 is to provide better alignment with Jakarta Contexts and Dependency Injection (CDI). Better integration with Jakarta Concurrency will also be explored. The support for @Context injection and related artifacts will be dropped.

More details at: https://jakarta.ee/specifications/restful-ws/4.0/

Jakarta Security 4.0

Jakarta Security 4.0 focuses on evolving the API in various ways. It will also provide APIs for the authorization theme, including interceptors and an abstraction for the permission store. This release will also remove all references to the SecurityManager.

More details at: https://jakarta.ee/specifications/security/4.0/

Jakarta Servlet 6.1

Jakarta Servlet 6.1 will provide small enhancements and adjustments to the specification and remove all references to the SecurityManager.

More details at: https://jakarta.ee/specifications/servlet/6.1/

Jakarta WebSocket 2.2

The focus of Jakarta WebSocket 2.2 is to remove all references to the SecurityManager. In addition to this, the release also contains minor updates and adjustments.

More details at: https://jakarta.ee/specifications/websocket/2.2/

Candidates for Inclusion

The following three specifications are candidates for inclusion in Jakarta EE 11. The discussion is still ongoing. 

Jakarta Data 1.0

Jakarta Data will provide an API for easier data access by letting the developer split the persistence from the model with the repository interface, thus increasing the productivity of performing common database operations. This release will provide the CrudRepository feature and allow pagination on a repository with PageableRepository. 

More details at: https://jakarta.ee/specifications/data/1.0/

Jakarta MVC 3.0

This is the third major release of Jakarta MVC. It will ensure alignment with Jakarta RESTful Web Services 4.0 and remove the requirement to support the Facelets view engine. Other features in this release are adding an accessor for FORM method overwrite field name and switching the CSRF default to implicit.

More details at: https://jakarta.ee/specifications/mvc/3.0/

Jakarta NoSQL 1.0

Jakarta NoSQL is a framework for streamlining the integration of Jakarta EE applications with NoSQL databases. This release defines mapping annotations for Entity, Id, and Column, as well as the DocumentTemplate, ColumnTemplate, and KeyValueTemplate specializations.

More details at: https://jakarta.ee/specifications/nosql/1.0/

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

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"
}

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>

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

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

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"
}

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>

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>

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

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
…

 

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"
}

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>

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

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
…

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"
}

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>

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>

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"
}

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

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
…

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.