DZone/Java EE Guardians Survey Results: HTTP 2/Servlet 4

As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I've already done a high level summary of the results. In this entry I'll dig specifically into the responses for HTTP/2 and Servlet 4 support in Java EE 8.

Here is how the survey phrased the question:

"The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations.

Servlet 4 is the primary vehicle to bring HTTP/2 to server-side Java. Beyond Servlet 4, higher level server-side Java web frameworks like JSF can also take advantage of HTTP/2 to significantly improve performance.

How important is it to bring HTTP/2 support to Java EE?".

The following graphic shows how the community responded. Clearly developers think HTTP/2 support and Servlet 4 is important for Java EE 8. 65% said it is very important while 25% said it is very important. A mere 1% said it is not important. If you want to learn a bit more about HTTP/2 and Servlet 4, please do feel free to check out my slide deck or screencast on the topic. While it is possible for server implementations to provide some level of HTTP/2 support without Servlet 4, things like server push can only be provided in a manner that developers and framework writers can rely on through Servlet 4. In addition, the Servlet 4 TCK is the only third party verification mechanism that a server actually implements HTTP/2 correctly.

Unsurprisingly, the results for Oracle's own Java EE 8/9 survey basically mirrors what the DZone/Java EE Guardians survey indicates. The graphic below shows the results of the Oracle survey. Just as in our survey, Servlet 4 is one the APIs that has the strongest support amongst all Java EE 8/9 features.

Here are some representative comments from participants in the order that people filled in the survey: "Servlet 4 and HTTP/2 are probably the most important parts of Java EE 8", "Very important as there are a lot of improvements in HTTP/2, it is the future", "I cannot imagine the next iteration of any serious web-based standard or framework not to take (full) advantage of this advance in the underlying technology", "HTTP/2 is a big step towards faster communications and applications", "HTTP/2 is the future of the web", "I develop web applications with JSF, so yes this is very important", "Clearly more than very important".

Oracle has recommitted to delivering Servlet 4 by the end of this year or sooner. Although the Oracle specification leads have clearly re-engaged in Servlet 4, progress still lags behind some other Java EE 8 JSRs. That said work on Servlet 4 is visibly spinning up as I am writing this.

Please do stay tuned as I further analyze specific topics in the survey. In addition to my analysis, I would encourage you to look at these survey results yourself and get involved in Java EE 8. You can certainly do so by becoming a part of the Java EE Guardians.

JSF 2.3 Public Review Starts Now!

JSF 2.3 has just posted a public review (this is the last step before the proposed final specification). Like JSF 2.2, this is slated to be mostly a minor update with various incremental features that the community has requested. Indeed the community has driven JSF 2.3 very heavily, directly committing many of the features into the Mojarra code base. Here is a summary of the features slated for JSF 2.3:

• Alignment with the Java SE 8 Date/Time API
• Improved CDI support
• Formally deprecating the JSF specific bean sub-system in favor of CDI
• WebSocket integration
• AJAX method invocation
• Multi-field validation

Besides the above, there are many more smaller grained changes. For details, you should check out the specification document itself (linked below). There is a nice change list at the very start of the document. The community had already been doing a nice job blogging about JSF 2.3 features - particularly folks like Arjan Tijms and Anghel Leonard. Simply Googling JSF 2.3 should go a long way to get a more detailed overview.

You can download and take a look at the draft specification from the JCP site. If you are a JSF user you should do your part by engaging actively. Here are the many ways you can engage (most of this comes directly from the Adopt-a-JSR page I drafted while still at Oracle):

• You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
• You can have your JUG officially support the standard through Adopt-a-JSR.
• You can simply join the discussion without any ceremony by subscribing to the JSF specification user alias.
• You can share ideas and feedback, possibly by entering issues in the public issue tracker.
• You can read the public review specification now.
• You can try out the reference implementation now.
• You can write or speak about JSF 2.3 now.
• You can encourage others to participate.

The next step is up to you. You can be a real part of Java's ongoing success yourself instead of simply being a passive consumer. If you have any questions I am happy to try to help - just drop me a note any time.

DZone/Java EE Guardians Survey Results: A Summary

As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more.

The Motivation and Context
Shortly before JavaOne 2016, after months of silent inactivity, Oracle announced that it was committed to delivering Java EE 8. While this was undoubtedly good news, the problem was that Oracle appeared to also wish to significantly shift the focus of Java EE 8 - basically unilaterally. Oracle's rationale was that so much time had passed since initial launch that the focus of Java EE 8 needed to be shifted. We thought the best way to ensure that was a wise thing to do is by asking the community directly through an open survey - the very same way the initial scope of Java EE 8 was formulated.

As it turns out now, the core objectives of having the survey was accomplished in more than one way. During the JavaOne time-frame, Oracle announced it's own open survey not just to determine the scope of Java EE 8, but also the scope of Java EE 9. More recently Oracle announced the results of that survey and finalized the focus of Java EE 8. Although the surveys were clearly different, the results of the Oracle survey was very similar to what the folks that took the DZone/Java EE Guardians survey indicated. Indeed the ultimate good news is that the final focus of Java EE 8 is basically aligned with the results of the Java EE Guardians/DZone survey. Perhaps that isn't mere coincidence. At JavaOne 2016 the Java EE specification leads promised to take a very close look at the DZone/Java EE Guardians survey results. If they did indeed do that the community should be humbly relieved and grateful.

The Results
The survey did well considering the short time frame that it had been open and the relatively modest resources that we had. In the end we had 800+ input points. While smaller than the Oracle survey this is enough to draw reasonable conclusions on what the community thinks about Java EE 8 scope (for context US professional surveys collect about 1000 random input points for a population size of 300 million+). The quality of the input is quite good including many thoughtful comments. For those that don't want to read through all the survey results, I'll provide a short summary:

• The survey completion rate is 100% which shows how serious the folks that participated are.
• Almost 70% said they were OK with follow up questions, which shows how engaged the folks that participated are.
• There was relatively strong support for Servlet 4, Java SE 8 alignment throughout all Java EE APIs, more robust JSON support and a security API overhaul.  
• There was reasonable support for dynamic configuration and JCache.
• There was relatively weak support for eliminating EJB in favor of CDI, MVC, NoSQL, more reactive programming and microservices.
• Most people want Java EE to take a relatively conservative approach to standardization and avoid hype.
• The majority of people would like to see the Java EE release frequency accelerated.

In the coming weeks I will analyze each of these results in much greater detail. I will also put the results in the context of the Oracle survey results, Oracle's actions so far as well as other important public data such as the latest ZeroTurnaround developer productivity survey.

What Oracle is Doing
As you may be aware, Oracle promised to deliver Java EE 8 by the end of this year with an altered scope. They have also promised to deliver Java EE 9 by next year. So far things for Java EE 8 look good and it may even be that Java EE 8 will be delivered around the JavaOne 2017 time frame. The following is a summary of what Oracle is doing with Java EE 8 so far:

• They are moving forward with Servlet 4, JSON-P 1.1, JSON-B 1.0, Java EE Security, JAX-RS 2.1 and JSF 2.3. In addition CDI 2 and Bean Validation 2 is moving forward under Red Hat's leadership.
• Oracle is dropping Java EE Management, JMS 2.1 and MVC. However Oracle is transferring full ownership of MVC to the community. The community will move MVC forward on it's own.
• Oracle has not stated a clear position on aligning Java EE 8 with Java SE 8. It seems most of this work will be done including changes to JAX-RS, JSF, JPA and JSON-P. I am following up on this topic in the Java EE 8 expert group.
• Oracle had initially indicated that they would include a new configuration JSR in Java EE 8. It is a bit disappointing that Oracle is now not pursuing this JSR for Java EE 8. However, Oracle has acknowledged that this JSR is important but it is being deferred for now to deliver Java EE 8 on an accelerated schedule.
• Oracle has not been clear about what it intends to do with JCache. However, it is already possible to use JCache in Java EE applications.

In addition to my more detailed analysis in the next few weeks I would encourage you to look at these survey results yourself and get involved in Java EE 8. You can certainly do so by becoming a part of the Java EE Guardians.

Lastly, this entry would not be complete without mentioning the MicroProfile initiative. The initiative is forging ahead with a 1.1 release. It is targeting many of the features that Oracle is interested in for Java EE 9, including dynamic configuration. The idea is to make collaboration-based microservices centric products from Java EE vendors available essentially before Java EE 8 is released. We can hope that the MicroProfile efforts will converge with Java EE 9 sooner rather than later.

JSON-P 1.1 Public Review Starts Now!

The JSON-P 1.1 (Java API for JSON Processing) specification has just posted a public review (this is the last step before the proposed final specification). For those unaware, JSON-P is a lower level JSON processing API introduced as part of Java EE 7. JSON-P 1.1 is a relatively more minor but important update that will be included in Java EE 8. Java EE 8 will also include a higher level declarative JSON binding API named JSON-B. While JSON binding is clearly important, there are many cases where a simple processing API is more appropriate. JSON-B also depends on JSON-P under the hood.

These two APIs together are extremely important in making JSON a first class citizen of the standard Java platform, just like JAXP (Java API for XML Processing) and JAXB (Java API for XML Binding) did many years ago for XML. With these two APIs in place Java developers can simply think of JSON as yet another Java serialization format. No more third party libraries and no more configuration - things will simply work out of the box when it comes to processing JSON. In my view these APIs are so critical they should indeed be moved to a modular Java SE release, much like JAXB and JAXP are already a part of Java SE.

The changes introduced in JSON-P 1.1 mostly includes staying up-to-date with JSON open standards like JSON Pointer and JSON Patch. There is also some Java SE 8 alignment work included in JSON-P 1.1. A very good resource for an introduction is a slide deck from specification lead Dmitry Kornilov as well as Werner Keil from the community presented at Java2Days 2016 (click here if you can't see the embedded slide deck).

JSON Support in Java EE 8 from Dmitry Kornilov

You can download and take a look at the draft specification from the JCP site. You should do your part demonstrating first hand that JSON-P 1.1 is a critical standard for Java - by engaging actively. Here are the many ways you can engage (most of this comes directly from the Adopt-a-JSR page I drafted while still at Oracle):

• You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
• You can have your JUG officially support the standard through Adopt-a-JSR.
• You can simply join the discussion without any ceremony by subscribing to the JSON-P 1.1 specification user alias.
• You can share ideas and feedback, possibly by entering issues in the public issue tracker.
• You can read the public review specification now.
• You can try out the reference implementation now.
• You can write or speak about JSON-P 1.1 now.
• You can encourage others to participate.

The next step is up to you. You can be a real part of Java's ongoing success yourself instead of simply being a passive consumer. If you have any questions I am happy to try to help - just drop me a note any time.

Java EE 7 in Production at Eko Electricity

One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time including at JavaOne. A number of these stories are curated at Zeef. Sayo Oladeji recently agreed to share a very cool such adoption story on a mission critical system for Eko Electricity - one of Lagos' largest utilities providers. Sayo had a number of insightful things to say about Java EE worth paying attention to. I have highlighted specific passages that really stand out.

Can you kindly introduce yourself?
I am Sayo Oladeji, a software engineer at Crown Interactive and co-founder at Hextremelabs. I started programming only 10 years ago and over the years I’ve had opportunities to work on Java SE, ME and EE; other JVM languages like Groovy and Kotlin as well as non-Java technologies like C# and Javascript.

I manage a lot of integrations with third-party system like lotto engines, payment gateways, business support systems and so forth.

Can you describe the application that uses Java EE? What does your company do?
Crown Interactive is a major technology provider in the utilities space in Nigeria. We currently provide the end-to-end revenue cycle management (RCM) technology for Eko Electricity Distribution PLC (EKEDP) which serves half of Lagos. To put it in perspective, Lagos has a population of 21 million (2016) and growing at about 85 persons per hour! Besides utilities we also have a lottery system, on-demand media service and a few other applications.

Why did you choose Java EE?
When we started building out the systems we had a lot of Java EE experience on board. Our consultant was also a JBoss partner. Java EE is a proven standard and JBoss EAP provides us with many things out of the box. These include support for web services, clustering, transactions, concurrency, caching, messaging as well as a rich ecosystem of tools; most being open source. It wasn’t a very hard decision to make.

How does the application use Java EE?
We started building the system in a multi-tenant, service-oriented manner from day one. We are now breaking some of the modules down into microservices as needs arise.

• We use JAX-WS quite heavily due to the kind of integrations we do. JAX-WS + NetBeans makes SOAP integrations a pleasant experience, probably even more pleasant and definitely quicker than REST due to SOAP’s self-documenting nature (WSDL). Handler chains allow us to perform cross-cutting concerns like reading incoming SOAP envelopes and extracting metadata like authentication and tenant information.
• We use JPA across board for data access.
• We use JMS for reliable loosely coupled communication between services with ActiveMQ as a message broker and a resource adapter installed for WildFly so that WildFly manages the connections to the broker.
• We use JAX-RS for the REST APIs which back our AngularJS web front-end.
• We use EJB for handling our core business logic and also for communication between our microservices. For example, our unified collections gateway (UCG) is a module made up of 8 microservices. One of these publishes an EJB that coordinates the interactions between the remaining. The hierarchical relationship between these modules are also neatly represented in the source code as a Maven multi-module project.
• Above all, we use CDI heavily. For example, our configurations are centrally managed in a database. We read this into an Infinispan cache (ships with WildFly) on startup and from there CDI producers inject them into beans using qualifiers. This is done in a type-safe manner. The C in CDI is the coolest thing. Bean members are injected based on the context, very important for a multi-tenant system. A JAX-RS filter or JAX-WS handler chain sets up contextual information before execution reaches our beans and the producers being context-aware inject context-specific configuration. We don’t want to bill the wrong partner or load the wrong message template for example.

How was your general experience with Java EE? Would you use it again?
My general experience with Java EE has been very good. Java EE + Maven + NetBeans + IntelliJ IDEA is a really good combination. There are appropriate plugins to configure our server and handle our deployments, generate API docs from REST endpoints, generate JPA entities from database schema and so forth. It’s very quick and easy to get a working project up and running with Java EE 7. Almost everything is POJO and annotation-driven and the generated WAR files are tiny. EE 7 is indeed lightweight.

Prior to using a full Java EE server, I have used Java-based platforms like AppEngine and Tomcat but I’ve generally found full EE servers like WildFly to be far more productive. In fact, with the WildFly Maven plugin + Docker plugin, it is very easy to make a fully functional and cloud-ready environment all from the pom.xml file. We try to have as many of our deployment tasks (such as downloading and installing JDBC drivers, configuring datasources, logging, cache containers, etc) as possible in the project’s pom.xml file so that our CI (BitBucket Pipelines) build file simply runs mvn clean install –P prod. This is also great for the purpose of documentation. Simply looking at the sources, you can confidently tell how the application is going to run.

I have had a great time developing with Java EE 7 and I will make new projects with it.

How can people contact you if they have questions?
I am available on Twitter as @oluwasayo_ and I can also be reached via email at oladejioluwasayo at gmail dot com.

If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do reach out.

Java SE 8 and 9 at the Philly JUG

The Philly JUG continues to march forward under new leadership and I was honored to deliver the September talk(s!?) myself. As ironic as it may seem, the Philly JUG had not had a dedicated talk on Java SE 8 and it was definitely time to close that gap. Fortunately I have just such as talk handy titled "JavaSE.Next – Java SE 8, Java SE 9 and Beyond".

The talk covers the big ticket features of Java SE 8 including lambdas, streams, the date/time API and completable futures. I also briefly cover what's coming in Java SE 9. The slides for the talk is on SlideShare (click here if you can't see the embedded slides).

JavaSE.Next – Java SE 8, Java SE 9 and Beyond from Reza Rahman

We tried something in September the Philly JUG has never tried in it's long existence - we held meetings in both the Western suburbs as well as center city Philadelphia (our talks have historically been held in the Western suburbs). The suburban meeting was held on September 13 while the center city meeting was held on September 14. Combined, the two meetings had one of the highest RSVPs and attendance numbers the JUG has had for a little bit. The meetings were very well-received and I think the twin meeting locations is something to pursue again when possible in the future. My company CapTech was very gracious to sponsor the food for both meetings.

The Philly JUG's next meeting on January 17 should be a great follow-up to my talk. Jason Young (also part of the Philly JUG leadership team) is covering Java SE 9 in detail. I highly recommend folks attend the talk and get engaged with Java SE 9 early!

See you at a Philly JUG meeting in the next few months? In the meanwhile, if you have ideas to improve the JUG, feel free to reach out to the leadership team any time - including myself.