Friday, September 08, 2017

Open EE: My Thoughts on an Open Java EE Platform

About two years ago, thousands of Java developers attended the JavaOne 2015 conference and learned about specifications and features that would be part of the Java EE 8 platform.  These features included the MVC 1.0 specification, Java EE Security 1.0, Microservices, CDI and more.  Java EE 8 was shaping up to be a great follow-up to the excellent Java EE 7 release.

After JavaOne 2015, progress and news around Java EE went silent.  In early January 2016, I received an invite to a Slack group that was created by some members of the Java EE community.  On the Slack channel, there were discussions around the halt of Java EE, and what the community may be able to do in order to keep it moving forward.  I was humbled by the sense of community from the members of the channel and the devotion to the platform was very evident.  Not long after, the Java EE Guardians were formed, focusing on publicizing the stall of Java EE.  The group put forth effort pressuring Oracle to make a statement and continue moving Java EE forward.  Especially in this fast paced space, looming silence regarding the future of any technology can be taxing on those involved.  Others worked on the Java EE specifications as much as possible, making strides forward.

After almost a year of silence, we started to hear music around Java EE again, and at JavaOne 2016 Oracle unveiled the plan to continue moving Java EE 8 forward, albeit a bit differently than originally planned.  The newly envisioned Java EE centered around Microservices and dropped a few of the specifications that no longer fit into the puzzle.  MVC 1.0, JMS 2.1, and Management 2.0 were taken out of the picture, while the newly proposed Health Checking and Configuration APIs were added.  MVC was eventually handed over to the community, which I think was a great move.  The Health Checking and Configuration APIs, which were clearly aimed toward microservices support, were later taken out of the picture for Java EE 8 due to lack of time.  Java EE 8 had more community involvement than any previous Java EE release, and much of this is likely due to the hiatus.  Java EE 8 moves forward, albeit a bit more lean than originally planned, we are moving forward.

Now, nearing the JavaOne 2017 conference, we are on the heels of a Java EE 8 release.  This release includes much of the original core Java EE 8 plan, bringing the Java EE platform in-line with Java SE 8.  It also enhances CDI support throughout the specifications, brings forth Security 1.0, which is long overdue, and JSON-B, closing the JSON to Java conversion gap that was left after JSON-P was released.  Java EE 8 will be a solid release, and I am thankful to all who are involved in making it happen.  I am sorry to say that I will not be at the JavaOne conference this year when it will likely be released, but I know that my colleagues will keep me in-tune with the latest news coming from the conference!  If you are going, make sure you check out the many great Java EE talks that will be presented.

Almost like a professional sports superstar going out on a high note, Oracle recently announced that they are planning to open source Java EE.  I have to applaud Oracle for all of the great work they've done and the support that they've given to Java EE through the years.  I am hopeful that they will remain engaged even after Java EE is open sourced, as they are a very important player in this space.  In my mind, they chose a perfect time to announce the opening of Java EE, as the Java EE 8 release will mark a great milestone making Java EE even more productive and relevant as one of the top application development platforms in the industry.  The community around Java EE seems as though it has never been more engaged than it is now.  Over the years since the cumbersome J2EE morphed into the productive platform that we call Java EE today, the community has continued to grow by the thousands.  The Java EE Guardians have thousands of supporters, each of them hoping to help move Java EE forward for years to come.

I see a great future for an open Java EE.  However, many questions are left to be answered.  Will the JCP still be used to manage the changes that are proposed for the platform?  Perhaps this is one of the questions that has the potential to impact the platform the most.  If the JCP will still be used to manage the platform, can it be changed in such a way that it will be conducive to a faster moving platform?  Do we want Java EE to become a faster moving platform, much to the likes of other frameworks such as Spring?

One of the main strongholds of Java EE is standardization.  If the open Java EE were to become more dynamic, can it maintain its place as a standard in the industry?  I think so.  I think that ideally the JCP could still be used to move the specifications forward, with a bit of a modernizing on the approach.  I like the idea of having shorter Java EE release cycles with fewer changes in each release.  Such an approach can really help the platform to retain its relevancy in this fast moving space.

What are your thoughts on the opening of Java EE?  I welcome it and look forward to seeing what is to come for JavaOne 2018.

Wednesday, July 26, 2017

Java EE 8: Start Testing Today

Java EE 8 will be finalized and ready for public use soon.  There is no better time to get started testing the new features than now.  You can do so by grabbing a copy of my Java EE 8 Playground project and deploying to GlassFish 5.

I've just updated the project to repair bugs and include better formatted table data within the tables.  I've also added a couple of examples:

- JSON-B example: Allows one to fetch the JSON for customer objects.

- CDI 2.0 Async:  Add a new Job object to see async event output in server log

GitHub Project:

Saturday, June 10, 2017

Java 9 Recipes Published!

A bit ahead of schedule, my latest book entitled Java 9 Recipes: A Problem-Solution Approach, has just been published!

This book is the 3rd Edition in the Java Recipes series.  It covers all of the information that was in the previous editions, including the new content for Java 9.  Specifically, you will learn how to use new Java 9 features including:

  • Modularity
  • Private Method Implementations in Interfaces
  • Process API Enhancements
  • New Streams API Enhancements
  • HTTP/2 Client API

I'd like to thank Apress for providing me with the opportunity to help share my knowledge of the Java platform.

Wednesday, March 29, 2017

Testing the Java EE 8 Specifications

The Java EE 8 Platform has definitely been moving along within the past couple of months.  Specifications have been releasing early draft reviews, milestones, and even final releases.  As a matter of fact, JSR-372 has just gone final, as JSF 2.3 has been released.  For more information, please see Arjan's Post.  It had the privilege to be a part of the JSR-372 expert group, and I really appreciate the opportunity to work with these experts on a specification that I use every day.

I created a Github Project entitled the Java EE 8 Playground, and it includes a Java EE application that contains a number of the latest updates to those specifications that will be part of the Java EE 8 release.  I will make an effort to update this project often so that it includes current dependencies for the specifications.  I will also try to add demos for the specifications so that it will be easy to build upon the examples.  In the current project, some of the JSF 2.3 features are used.

It is important that as a community we test and provide feedback for the Java EE 8 specifications as they are being developed.  It is in these stages that you have a voice that can make a change to an upcoming specification.  Please test, read the latest specification documents, and provide feedback to the respective JSRs.

Java EE 8 Playground Project:

Java EE 8 JSRs:

JSR 365 (CDI 2.0):
JSR 366 (Java EE 8):
JSR 367 (JSON Binding):
JSR 369 (Servlet 4.0):
JSR 370 (JAX-RS 2.1):
JSR 372 (JSF 2.3 - FINAL):
JSR 374 (JSON  Processing 1.1):
JSR 375 (Java EE Security 1.0):
JSR 380 (Bean Validation 2.0):

JSR 371 (MVC - No longer officially part of Java EE 8):

Saturday, March 04, 2017

JSR 365 Update: Digging Into CDI 2.0

Contexts and Dependency Injection 2.0 (JSR 365), is an update to CDI 1.2, which is currently part of the Java EE 7 platform.  It is currently in Public Review stage.  For those of you who are not very familiar with CDI, it defines a powerful set of complimentary services that act as a gel that help to improve the coordination and structure of application code.  For more details, please visit the specification page.

CDI 2.0 expands the usability of the Contexts and Dependency Injection services to Java SE as well, as it will now target both the Java SE and Java EE platforms.  The CDI specification has been organized into 3 parts, Part I - Core CDI, Part II - CDI in Java SE, and Part III - CDI in Java EE.  The major changes for CDI 2.0 are as follows:

  • Better alignment with Java SE 8
  • API for booting CDI within a Java SE application
  • Ability to provide observer ordering
  • Ability to fire asynchronous events
  • New Configurators Interfaces for Service Provider Interface (SPI) elements
  • Ability to configure or veto an observer method in ProcessObserverEvent event
  • Support for inline instantiation of specific annotation types
  • Addition of the InterceptionFactory interface,  which allows to create a wrapper instance whose method invocations are intercepted by method interceptors and forwarded to a provided instance.
I encourage you to take a look at the CDI 2.0 Public Review Draft for more details on the specifics of each enhancement listed, as well as a complete listing of new features.  Read through the draft and provide feedback to the expert group.  All of the pertinent details for providing feedback can be found on the JSR 365 page.  To get started testing, create a new maven based Java EE application in your favorite IDE, and add the following dependencies:


In this post, we will dig into one of the new features to get you started working with the API.  Let's take a look at asynchronous events.  Until CDI 2.0,  events could only be fired in a synchronous manner.  They've been enhanced in this latest iteration for asynchronous processing.  Here's how it works:

Create an event of some type.  Next, fire the event in an asynchronous manner, and handle accordingly once the event is complete.  In this example, I have created a MovieEvent class, which will be utilized whenever a persist event occurs for a Movie object.  The MovieEvent class is as follows:

public class MovieEvent {
    private String message;
    private Movie movie;
    public MovieEvent(String message, Movie movie){
        this.message = message; = movie;
    public String getMessage(){
        return this.message;
    public void setMessage(String message){
        this.message = message;
    public Movie getMovie(){
    public void setMovie(Movie movie){ = movie;

In the following scenario, we are firing an event when a new Movie is persisted.  The following code resides within a MovieController CDI bean of an example JSF application:

public class MovieController implements Serializable {

    private com.mycompany.cditest.session.MovieFacade ejbFacade;
    private List items = null;
    private Movie selected;
    Event<MovieEvent> movieEvents;
. . .
   private void persist(PersistAction persistAction, String successMessage) {
        if (selected != null) {
            try {
                if (persistAction != PersistAction.DELETE) {
                    movieEvents.fireAsync(new MovieEvent("New Movie Released", selected))
                            .whenComplete((event, throwable) -> {
                                if(throwable != null){
                                    System.out.println("Error has occurred: " + throwable.getMessage());
                                } else {
                                    System.out.println("Successful Movie Processing...");
                } else {
            } catch (Exception ex) {
                Logger.getLogger(this.getClass().getName()).log(Level.SEVERE, null, ex);
                JsfUtil.addErrorMessage(ex, ResourceBundle.getBundle("/Bundle").getString("PersistenceErrorOccured"));
. . .

When the event is fired, it creates a new MovieEvent object, and if it successfully completes then a message is printed to indicate success.  In this example, a stream is used to process the "whenComplete" action.

Feel free to clone the repository located at and take CDI 2.0 test for a spin.  This example is just one simple test of CDI 2.0.  You can clone and utilize this test project as a starting point to work with other aspects of the specification.  Keep an eye on JSR 365, which is currently in the Public Review Ballot stages.