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!
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
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:
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:
JCache was also seen as being very important as expressed with comments like:
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:
There is, however, a palpable concern around the performance impact of enabling CDI by default as exemplified by this comment:
Another significant concern appears to be around backwards compatibility and conflict with other JSR 330 implementations like Spring:
Some commenters such as this one attempt to suggest solutions to these potential issues:
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:
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:
Some, however, expressed concerns around increased complexity such as this commenter:
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:
A distinct chain of thought separated interceptors from filters and listeners: