On November 8th, the Java EE EG posted a survey to gather broad community feedback on a number of critical open issues. For reference, you can find the original survey here. We kept the survey open for about three weeks until November 30th. To our delight, over 1100 developers took time out of their busy lives to let their voices be heard!
The results of the survey were sent to the EG on December 12th. The subsequent EG discussion is available here. The exact summary sent to the EG is available here.
We would like to take this opportunity to thank each and every one the individuals who took the survey. It is very appreciated, encouraging and worth it's weight in gold. In particular, I tried to capture just some of the high-quality, intelligent, thoughtful and professional comments in the summary to the EG. I highly encourage you to continue to stay involved, perhaps through the Adopt-a-JSR program. We would also like to sincerely thank java.net, JavaLobby, TSS and InfoQ for helping spread the word about the survey.
Below is a brief summary of the results...
APIs to Add to Java EE 7 Full/Web Profile
The first question asked which of the four new candidate APIs (WebSocket, JSON-P, JBatch and JCache) should be added to the Java EE 7 Full and Web profile respectively.
As the following graph shows, there was significant support for adding all the new APIs to the full profile:
Support is relatively the weakest for Batch 1.0, but still good. A lot of folks saw WebSocket 1.0 as a critical technology with comments such as this one:
"A modern web application needs Web Sockets as first class citizens"
While it is clearly seen as being important, a number of commenters expressed dissatisfaction with the lack of a higher-level JSON data binding API as illustrated by this comment:
"How come we don't have a Data Binding API for JSON"
JCache was also seen as being very important as expressed with comments like:
"JCache should really be that foundational technology on which other specs have no fear to depend on"
The results for the Web Profile is not surprising. While there is strong support for adding WebSocket 1.0 and JSON-P 1.0 to the Web Profile, support for adding JCache 1.0 and Batch 1.0 is relatively weak.
There was actually significant opposition to adding Batch 1. 0 (with 51.8% casting a 'No' vote).
Enabling CDI by Default
The second question asked was whether CDI should be enabled in Java EE environments by default.
A significant majority of 73.3% developers supported enabling CDI, only 13.8% opposed. Comments such as these two reflect a strong general support for CDI as well as a desire for better Java EE alignment with CDI:
"CDI makes Java EE quite valuable!"
"Would prefer to unify EJB, CDI and JSF lifecycles"
There is, however, a palpable concern around the performance impact of enabling CDI by default as exemplified by this comment:
"Java EE projects in most cases use CDI, hence it is sensible to enable CDI by default when creating a Java EE application. However, there are several issues if CDI is enabled by default: scanning can be slow - not all libs use CDI (hence, scanning is not needed)"
Another significant concern appears to be around backwards compatibility and conflict with other JSR 330 implementations like Spring:
"I am leaning towards yes, however can easily imagine situations where errors would be caused by automatically activating CDI, especially in cases of backward compatibility where another DI engine (such as Spring and the like) happens to use the same mechanics to inject dependencies and in that case there would be an overlap in injections and probably an uncertain outcome"
Some commenters such as this one attempt to suggest solutions to these potential issues:
"If you have Spring in use and use javax.inject.Inject then you might get some unexpected behavior that could be equally confusing. I guess there will be a way to switch CDI off. I'm tempted to say yes but am cautious for this reason"
Consistent Usage of @Inject
The third question was around using CDI/JSR 330 @Inject consistently vs. allowing JSRs to create their own injection annotations.
A slight majority of 53.3% developers supported using @Inject consistently across JSRs. 28.8% said using custom injection annotations is OK, while 18.0% were not sure. The vast majority of commenters were strongly supportive of CDI and general Java EE alignment with CDI as illistrated by these comments:
"Dependency Injection should be standard from now on in EE. It should use CDI as that is the DI mechanism in EE and is quite powerful. Having a new JSR specific DI mechanism to deal with just means more reflection, more proxies. JSRs should also be constructed to allow some of their objects Injectable. @Inject @TransactionalCache or @Inject @JMXBean etc...they should define the annotations and stereotypes to make their code less procedural. Dog food it. If there is a shortcoming in CDI for a JSR fix it and we will all be grateful"
"We're trying to make this a comprehensive platform, right? Injection should be a fundamental part of the platform; everything else should build on the same common infrastructure. Each-having-their-own is just a recipe for chaos and having to learn the same thing 10 different ways"
Expanding the Use of @Stereotype
The fourth question was about expanding CDI @Stereotype to cover annotations across Java EE beyond just CDI.
A significant majority of 62.3% developers supported expanding the use of @Stereotype, only 13.3% opposed. A majority of commenters supported the idea as well as the theme of general CDI/Java EE alignment as expressed in these examples:
"Just like defining new types for (compositions of) existing classes, stereotypes can help make software development easier"
"This is especially important if many EJB services are decoupled from the EJB component model and can be applied via individual annotations to Java EE components. @Stateless is a nicely compact annotation. Code will not improve if that will have to be applied in the future as @Transactional, @Pooled, @Secured, @Singlethreaded, @...."
Some, however, expressed concerns around increased complexity such as this commenter:
"Could be very convenient, but I'm afraid if it wouldn't make some important class annotations less visible"
Expanding Interceptor Use
The final set of questions was about expanding interceptors further across Java EE...
A very solid 96.3% of developers wanted to expand interceptor use to all Java EE components. 35.7% even wanted to expand interceptors to other Java EE managed classes. Most developers (54.9%) were not sure if there is any place that injection is supported that should not support interceptors. 32.8% thought any place that supports injection should also support interceptors. Only 12.2% were certain that there are places where injection should be supported but not interceptors.
The comments reflected the diversity of opinions, generally supportive of interceptors:
"I think interceptors are as fundamental as injection and should be available anywhere in the platform"
"The whole usage of interceptors still needs to take hold in Java programming, but it is a powerful technology that needs some time in the Sun. Basically it should become part of Java SE, maybe the next step after lambas?"
A distinct chain of thought separated interceptors from filters and listeners:
"I think that the Servlet API already provides a rich set of possibilities to hook yourself into different Servlet container events. I don't find a need to 'pollute' the Servlet model with the Interceptors API"
