Java EE @ DevNexus 2017

DevNexus 2017 was held in historic Atlanta on February 22-24. For those of you not familiar with it, DevNexus is the most significant Java centric conference in the South Eastern US and now perhaps even at a national level. It was started by JBoss Java Champion Burr Sutter and organized by the Atlanta JUG (currently lead by Vincent Mayers, Gunnar Hillert, Pratik Patel, et al). I guess at this point I am somewhat of a DevNexus veteran myself. As usual DevNexus attracted a bevy of world class speakers including Ed Burns, David Blevins, Ivar Grimstad, Simon Ritter, Heather VanCura, Stephen Chin, Simon Maple, Geertjan Wielenga, Victor Orozco, Edson Yanaga and Enrique Zamudio. This was another solid year for DevNexus. Java EE had a strong showing at the conference as usual, including my own sessions.

I am very proud to say my company CapTech sponsored DevNexus for the very first time. We had a fully manned booth that saw very good traffic and we also sponsored a well attended happy hour.

I started the conference late afternoon on the first day with my talk titled “Java EE 8 and Java EE 9 – What You Need to Know!”. I discuss continued Java EE adoption, the importance of Java EE to the ecosystem, the contents of the upcoming Java EE 8 release as well as the tentative Java EE 9 plans that Oracle shared at JavaOne 2016. I also talk about the key MicroProfile initiative that aims to bring a collaborative, fast-paced, vendor-neutral approach to microservices in the Java EE ecosystem. The heart of the talk covers the key features of Java EE 8 such as HTTP/2, a complete security API overhaul, even stronger JSON support, support for HTML 5 Server-Sent Events (SSE), CDI 2, Bean Validation 2 and Java SE 8 alignment. The current slides for the talk are here (click here if you can’t see the embedded slide deck):

Later in the afternoon my former colleague Ed Burns did a deeper dive on three specific Java EE 8 APIs – Servlet 4, JAX-RS 2.1 and JSF 2.3. For those unaware, Ed is the specification lead for both Servlet 4 and JSF 2.3.

Early in the evening I delivered my talk on Cargo Tracker/Java EE + DDD titled “Applied Domain-Driven Design Blue Prints for Java EE”. This talk overviews DDD and describes how DDD maps elegantly to Java EE using code examples/demos from the Cargo Tracker Java EE Blue Prints project. Below is the slide deck for the talk (click here if you can’t see the embedded slides):

A screencast of my talk can be found here. Concurrent to my talk, my friend Kito Mann delivered his very cool talk on JSF and HTML 5 Web Components.

The second day of the conference in the late afternoon Ivar delivered a deep dive into the MicroProfile initiative. Concurrent to his talk Heather delivered a talk on JCP and Adopt-a-JSR. Later in the afternoon Ivar delivered a talk on the upcoming MVC specification. For those unaware, MVC was originally slated for Java EE 8 and is now a separate, community led JSR.

Overall this was another great year at DevNexus and I hope to be part of the conference next year.

DZone/Java EE Guardians Survey Results: Security

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. I’ve also done a deeper dive into the responses for HTTP/2 and Servlet 4 as well as Java SE 8 alignment. In this entry I’ll take a look at the responses for revamping Java EE security.

Here is how the survey phrased the question:

“Java EE security is one of the last areas left to be revamped in the way most other APIs such as EJB 3 have been changed radically. As a result Java EE security is very highly dependent on things like vendor-specific GUI console wizards, vendor-specific configuration or command-line administrative tools. Pluggability, extensibility and customization is also currently challenging when the security features that already come with the application server are not sufficient.

This situation is the primary driver for the proliferation of third-party security frameworks in server-side Java such as Shiro and Keycloak. The Java EE Security API has been slated to solve these issues in Java EE 8. As an example securing a Java EE application could be as simple as writing the following annotation:

@DataBaseIdentityStore(
    lookup=”java:app/MyDB”, 
    userQuery=”SELECT password FROM principals WHERE username=?”, 
    rolesQuery=”SELECT role FROM roles where username=?”, …)

How important is it to revamp the Java EE security API?”.

The following graphic shows how the community responded. Support for revamping Java EE security is clearly fairly strong. 47% said it is very important while another 30% said it is important. Only about 5% said it is not important. It is the case though that support is not as strong as it is for example for Servlet 4 and Java SE 8 alignment. I think this generally makes sense. While there are decent options for Java EE security, HTTP/2 support and being able to effectively use Java SE 8 is far more foundational. If you are interested to learn a bit more about the Java EE Security API, a great place to start is the actual working specification draft.

Here are some representative comments from participants in the order that people filled in the survey: “One of the areas where no real standardization is done yet because you always need to have application server specific configuration”, “The currently available security features in Java EE don’t comprise a full end-to-end solution, to really secure an application one has to rely on vendor specific features”, “I always found it quite challenging to work with JAAS and the vendor specific configuration required to get it to work in different containers. I am really looking forward to simpler and better integrated solutions”, “Would be nice to get this into the app and out of the app’s XXXX.xml and container configuration. It would seem to be a step in the right direction to making apps more fully portable”.

It is important to note that in the original survey that helped launch Java EE 8, security related questions rank extremely high. Somewhat surprisingly Oracle’s own Java EE 8/9 survey did not directly include any questions on Java EE security. It did pose questions on OAuth/OpenID support which ranked extremely high. Judging by Oracle’s actions taken to move Java EE 8 forward, it seems they basically took for granted that Java EE security was important and the OAuth/OpenID question may have been more geared towards Java EE 9 (there are many such questions on the Oracle survey). The Java EE Security API is now moving ahead strongly to a completion date of around summer. It is sticking largely to the original scope defined for Java EE 8 while deferring OAuth/OpenID support to maintain delivery schedule (Oracle did in fact consider pulling in OAuth/OpenID support based on survey feedback).

Please do stay tuned as I further analyze specific topics in the survey. In addition to my write-up, 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.

Java EE Adoption Story from Armen Arzumanyan

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 here. Armen Arzumanyan recently agreed to share his Java EE adoption story. He has developed a number of mission critical Java EE applications in his native Armenia and beyond. One of his applications – Taxpayer3 – was so impactful that it won an international award. Armen 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?
My name is Armen, I am a Java developer and architect. I have about ten years of experience in Java development. I was introduced to Java while working at Lycos Europe. At Lycos we used J2EE on JBoss to develop applications in the early days of Java.

Can you describe the applications that use Java EE?
The very first application I developed from scratch in Java EE was actually a social network! I was tasked with researching the technologies to implement the front-end as well as the back-end.

The requirements dictated that the front-end and back-end should run on different servers as well as provide a rich front-end.

I tried as much as possible to utilize Java web technologies.

Back in 2008, I was pleasantly surprised with JBoss 4.2.2 – it was possible to develop a @Stateless EJB 3 based back-end without any configuration! Meanwhile, for the front-end I chose JSF 1.2. JSF allowed directly connecting web form components from a web page to Java Beans. JSF is also based on component controls which saves development time. The important part of the page layout is covered well by Facelets.

Back then, EJB 3 POJO remote interfaces made me very happy. I was able to send/receive DTOs completely transparently (no JSON, no XML).

I prepared a short demonstration to my team with the front-end running on JSF/Tomcat and back-end running on EJB 3/JBoss 4.2.2. The demo was a success and was approved.

The second significant Java EE project I helped develop from scratch was Taxpayer3. Taxpayer3 was one of the biggest Java EE applications ever developed in the former USSR. In fact the project won a top international award due to it’s innovation and impact. Java EE covered all of our architectural requirements well – stable, stateless, productive and easy to upgrade.

Last but certainly not least two interesting Java EE projects I develop and support are an e-procurement system and ID-card printing system. In addition I support a very popular PKI Certificate Authority software used in lots of countries. The software is available at https://www.ejbca.org.

Why did you choose Java EE?
As a Java developer my introduction to enterprise Java started with the official Java EE tutorial. I think all Java developers should learn Java EE. Java EE gives you the fundamental skills for developing business-oriented applications.

Using Java EE and using application servers allow you to grow from a developer to an architect.

When people ask me “How did you become a senior Java developer?”, my answer is very short:

“I know Java EE”

It puzzles me that in some companies Java developers don’t know Java EE and create applications using just Tomcat that are very similar to what you can do easily with what Java EE already offers out of the box. People create a lot of service layers in their applications and every component can be injected into another, no matter where is it located. But with EJB 3 you get a lot of additional power because you can make fully interchangeable local and remote interfaces which speaks to the ability to really hide your implementation behind a façade.

For me Java EE applications have always been a success: you have real statelessness, you have components, you have REST, you have remote calls, you can easily upgrade from version to version, you never need much configuration, you are focused only on development and on business logic.

Another powerful capability is Message Driven Beans which allow you to easily enable asynchronous messaging.

One interesting fact I am finding out is that I have never really developed monolithic applications! In the least my back-end has always been isolated and interacts with the front-end via DTOs. With Java EE you are not limited to just REST and JSON, which some enterprises still don’t accept as a format. For example you could easily use SOAP or EJB remoting instead!

Once in an interview I got asked “Which version of JBoss have you used?”. I answered “JBoss 4.2.2, 4.2.3, 5.1 and 7.1″. The interviewer replied “You are hired”.

Nowadays with the microservices trend, WildFly Swarm looks very interesting. The framework enables you to develop microservices with JSF/PrimeFaces/Java EE.

How do the applications use Java EE?
In production I use a JBoss/EJB 3/JMS + MySQL-PostgreSQL-Oracle DB combination. Pure front-end parts with JSF run under Tomcat or JBoss.

How was your general experience with Java EE? Would you use it again?
I am using different technologies in different projects. Java developers should always explore a wide variety of solutions. But not understanding Java EE is like losing half of Java for no good reason.

Trying to compare technologies with each other is unwise. Instead we should compare technologies with project requirements, but you won’t find a future that doesn’t include the Java EE technology stack.

How can people contact you if they have questions?
My email is armen dot arzumanyan at gmail dot com and you can follow me on GitHub at https://github.com/armdev.

New Java Community Process (JCP) Membership Types and What They Mean

Last year the Java Community Process (JCP) introduced a couple of pretty important new membership types. Ever since Java EE 5 the community has played a larger and larger role certainly in shaping Java EE standards and these new membership types are important enablers in the same direction. In this post I’ll explain the new membership types and what they actually mean. I’ll also explain how I and the Philly JUG have used these new membership types.

The Existing Membership Types
Before getting into the new membership types I think it helps to explain what the existing membership types were. Before last year there was really two ways of joining the JCP – either as a company or as an individual. Company membership types are the original kind of JCP membership type. As scary as it is, this is basically the most common membership type for most standards bodies out there (yikes). Thankfully this has been the least common type of JCP membership for a long time.

However, even if you did want to join the JCP as an individual, you needed official permission from your company. This is a real hurdle for many people and I personally know of cases where people could not join the JCP exactly for this reason. As a long-time self-employed independent consultant this was a non-issue for me (I simply had to give myself permission to join :-)). This is how I served as an expert on the EJB 3.1, Java EE 6, JMS 2, Java EE 7 and EJB 3.2 expert groups. I believe I have been one of the most active members of those expert groups.

Either as an individual or a company, you are basically considered a “full member”. That means you can do pretty much anything in the JCP – including submitting your own JSR, becoming a specification lead, becoming an expert or running for a spot on the executive committee. In case you are wondering this also includes legally recognized non-profits like Apache.

Associate Member
The new Associate membership type is basically the same as the individual membership I’ve used for such a long time with one big exception. In order to join as an Associate member, you don’t actually need permission from your company. This does come with some limitations that I don’t think matter that much. You can’t become a specification lead. You can’t run for the JCP executive committee. Indeed you don’t get to be an “expert” on a JSR either. You can however become a “contributor” to a JSR.

In practice the difference between a “contributor” and an “expert” on a JSR is pretty meaningless for most people. As a mere “contributor” you basically can’t write specification text or contribute code to the compatibility tests (TCK) or the reference implementation (RI). You can do everything else like review specification work and participate in discussions. The truth of the matter is that I am one of the most active contributors in most of the Java EE JSRs I have been on and this is basically all I did anyway. As a result, I’ve actually chosen to join the JCP as an Associate member instead of  a full member for this reason. I am now a “contributor” to Servlet 4, Java EE 8 and Java EE Security. I still get to do exactly what I’ve done for years and get credit for it in the specification document.

To be honest, it would have been easy enough for me to get permission from my company to join as a full member. The reason I chose not to do that is because there wasn’t a need and I also wanted to encourage others to do exactly what I did. This is particularly important for JUGs and Adopt-a-JSR. I’ll explain more in the next few sections why this is.

Partner Member
Besides joining as a fully legally recognized entity, non-profits can now also join as Partner members. Very simply put, this is basically intended for Java user groups. Many of the larger Java user groups are actually legally recognized non-profits. For these JUGs, joining as full members is perfectly fine. Most JUGs in the world are not legally recognized entities. These JUGs can now join the JCP as Partner members. Partner members do have limitations. They can’t become specification leads. They can’t even join a JSR as an expert or a contributor. They can however do one very important thing – run for a seat in the JCP executive committee.

At the Philly JUG, we did not opt to become a legal entity yet. It’s just too much hassle with not enough of a benefit for us. As a result, the Philly JUG has joined the JCP as a Partner member. We are not running for the JCP executive committee yet, but we might.

Adopt-a-JSR
It’s important to understand how all of this relates to Adopt-a-JSR. The first thing to understand is that you can participate in Adopt-a-JSR without even being a member of the JCP. The issue is that you really don’t get recognized in the specification itself as either a contributor or an expert (but the lead still can make a special mention if they want). Your JUG does get listed on the Adopt-a-JSR JUGs page.

A much better way to go is to adopt a JSR, get your JUG registered as a JCP Partner member and get JUG members to become official contributors to the JSRs you are adopting as JCP Associates. This can all be done without any company being involved. This is exactly what the Philly JUG has done. The Philly JUG is now an adopter of Java SE 9, Servlet 4, Java EE 8 as well as Java EE Security.

I hope this writeup inspires you to join the JCP using the new membership types. In the many years that I’ve worked in the JCP, the oddest part has been the tiny number of exceptional people that actually participate actively. This really needs to change if Java is to remain successful. You need to be a part of that change.

If you have any questions on any of this, don’t hesitate to reach out. I’ll try to help as much as I can. One resource that might help is the JCP page on membership types.

DZone/Java EE Guardians Survey Results: Java SE 8 Alignment

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. I’ve also done a deeper dive into the responses for HTTP/2 and Servlet 4 support in Java EE 8. In this entry I’ll take a look at the responses for Java SE 8 alignment in Java EE 8.

Here is how the survey phrased the question:

“Java SE 8 brings a bounty of improvements – lambda expressions, the new date/time API, completable futures, streams and the fork/join common pool. Many of these features can be used with Java EE 7, but there remains many important missing pieces.

In particular Java EE APIs like JPA, JMS, JSF and JAX-RS need to be adapted to make full use of repeatable annotations, the date/time API and completable futures. In addition the fork/join common pool and streams currently cannot be safely used in Java EE environments.

How important is it to fully align Java EE with Java SE 8?”.

The following graphic shows how the community responded. Clearly developers think aligning Java EE 8 with Java SE 8 is extremely important. 66% said it is very important while 25% said it is very important. A mere 2% said it is not important. If you want to learn a bit more about Java SE 8 and Java EE, please do feel free to check out my slide deck on the topic. The deck is focused on how Java SE 8 can already be utilized in Java EE but also highlights clear gaps that can only be addressed through changes in Java EE 8.

The fact that developers feel so strongly about Java SE 8 is no surprise at all. Every reliable survey shows strong support for Java SE 8, including DZone’s. The most recent RebelLabs survey shows 62% adoption for Java SE 8 – far stronger and faster than any other recent prior version of Java.

Here are some representative comments from participants in the order that people filled in the survey: “Java SE 8 APIs are great”, “I’ve always believed that keeping EE on track with the corresponding SE release should be a very important element of every version”, “The changes in SE 8 are a huge improvement for the language. EE 8 users should also benefit from these improvements”, “EE should always be aligned with SE”, “Java SE 8 brought the next level of language features to Java and everyone must take advantage of it”, “This is the most important thing EE 8 needs to do.”.

The initial Java EE 8 charter clearly mentions Java SE 8 alignment as a major theme. Historically Java EE has always played a key part in bringing Java SE features into the enterprise. A particularly salient example was groundbreaking annotations support in Java EE 5 and EJB 3/JPA. Java EE 5 was the very first mainstream technology to clearly demonstrate how annotations can be used highly effectively as framework meta-data.

Somewhat surprisingly Oracle’s own Java EE 8/9 survey did not directly include any questions on Java SE 8 alignment and they have not specifically addressed the issue either. In practice at least some of the most obvious Java SE 8 alignment work seems to be moving forward for Java EE platform level common annotations, CDI, Bean Validation, JPA, JAX-RS and JSF. I have already asked for a more coordinated plan and will follow-up soon. If this is an important issue for you, please chime into the linked thread – it’s very easy to do.

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.

Morocco’s First Open Source ERP Uses Java EE 7!

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 (Zeef is also written with Java EE). Mohammed Bounaga recently agreed to share a very cool such adoption story on deftERP – Morocco’s first open source ERP. Mohammed 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’m Mohammed Bounaga and I’m from Ifrane, Morocco. I’m a software engineer and I have been working with Java EE for 3 years. I’m the creator and project lead of deftERP. This project is now powered by xHub, a Moroccan startup that supports and believes in open source projects, founded by Badr El Houari – Devoxx Morocco chair, Morocco JUG lead and Java Champion. We are now a small team of talented developers who are working in collaboration with the Java EE community to boost the development of this project and empower the open source ecosystem in Morocco and Africa.

Can you describe the product that uses Java EE?
After graduating from university, I decided to work full time at home on an interesting and challenging project while sharpening my software development skills. At that time, I had different project ideas including desktop and mobile applications; yet my final choice was to develop an ERP web application since I believe that enterprise applications require complex business processes and they are open for innovation and creativity and this is exactly what I was looking for. The first version of this product was a result of 18 months of hard work with ups and downs that required patience and self-motivation. DeftERP is an open source and smart ERP built with full Java EE 7 (JPA 2.1, EJB 3.2, JSF 2.2, CDI, Beans Validation, JAX-RS, JSON-P, WebSocket…). The product is currently dedicated to small businesses to help them embrace and take advantage of technology to automate their daily working process, reducing working time and energy, having a smart dashboard and some predictions to help them anticipate the future while of course increasing profit. The product currently includes 4 modules:  sales, purchases, inventory, and accounting and it’s cloud ready!

Why did you choose Java EE?
I had fallen in love with Java during my university years and it has always been my first choice, which is the case with deftERP. The only issue I had when I decided to start this project was which Java web framework to adopt. I spent a couple of weeks doing some research reading blog reviews from the Java community comparing different Java web frameworks including JSF, Spring MVC, and Struts. I was really impressed by the idea behind component based frameworks and how JSF is appropriate for rapid development while still giving you flexibility and room for creativity. What is also awesome about JSF is the availability of third party libraries such as PrimeFaces and OmniFaces that empowers developers with a great set of UI components that every application needs, and finally let’s not forget the fact that Java EE is not heavy anymore!

How does the product use Java EE?
The product is developed with Java EE 7. We are using JSF for the web layer with PrimeFaces as a components library. EJB for the business layer. JPA with the EclipseLink implementation for the persistence layer, WebSocket for real time notification, CDI is of course the glue that binds our application layers together with dependency injection, and we are using BeanValidation to validate our entities against predefined or custom rules (we have built a metadata programming model).

    How was your general experience with Java EE? Would you use it again?
    Of course yes, we were happy to know about the plans to move forward Java EE 8 during last JavaOne. We are even planning after releasing the new version to see how we can help in the Adopt-A-JSR program under the umbrella of Morocco JUG. We are also keeping an eye open on the MicroProfile initiative since we are looking forward to revamp and optimize the architecture of deftERP for a microservices architecture. At this stage we aim to include the voice of our community!

    How can people contact you if they have questions?
    Questions and contributions are always welcome!

    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.

    RebelLabs Survey Shows Java EE Still Dominant, Solid Java EE 7 Adoption

    The RebelLabs Developer Productivity survey is one of the most important ones in the Java ecosystem. It is widely circulated and generally tends to have the most data points. The survey has always asked about Java EE as well as Java SE adoption. The results in the 2016 survey look encouraging for Java EE generally and Java EE 7 specifically, particularly given the seemingly perpetual nay-saying around Java and Java EE in predicable corners of our ever “colorful” industry.

    The RebelLabs survey is a bit different from the similar DZone survey in that it asks participants to make mutually exclusive adoption choices. You can either be a Java EE user or a Java SE user. You are only allowed to choose one specific version of Java EE. While this may not be entirely reflective of more complex scenarios in real life, it does make the results a bit more interesting from an analytical perspective. The 2016 results for Java EE adoption are shown in the graphic below. A clear majority of developers – 58% – identified themselves as Java EE users. This is truly remarkable for a mature open standard like Java EE with a number of non-standard product vendors aggressively positioning themselves as competitors to Java EE for many years now. Even more encouragingly developers seem to be solidly behind Java EE 7 – far more so than previous versions including Java EE 6. It is especially good to see the number of J2EE users at a low percentage.

    It’s remarkable how similar these results are to other surveys from reliable, neutral sources (the DZone survey results are in the graphic below). There has been another survey from the Vaadin team that also shows Java EE ahead of other alternatives amongst Java developers. I’ll highlight those results as well soon.

    While all of this is good news, the Java EE community can ill afford to rest on it’s laurels even for a moment. A number of us in the Java EE Guardian community were very worried what the RebelLabs survey was going to show in 2016. This is because the survey was taken when Oracle’s commitment behind Java EE 8 still remained very uncertain. In fact RebelLabs correctly noted this may be a reason for lower participant support for Java EE compared to other years and the Java EE community has hard work ahead of it.

    This is wise advice for the Java EE community and a reason to continue to try our best to advance Java EE. All that being said, it is important to remember that none of these are scientific surveys in any real sense so it is always a good idea to only make high level observations around them. Scientific surveys are truly random, have representative sample sets and clearly identify participants. Most of the surveys we have are unfortunately always self-selection based and at least partially anonymous/online.

    On behalf of the Java EE Guardian community it is only correct to thank everyone that indicate their support for Java EE and Java EE 7 in such surveys. Our volunteer driven work is intended to benefit you first and foremost – it is good to see that intent does not get lost in the muddle.

    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.