Java EE 7 Community Survey Results!

Markus Eisele
3
Work on Java EE 7 presses on under JSR 342. Things are shaping up nicely and Java EE 7 is now in the Early Draft Review stage. In beginning of November Oracle posted a little community survey about upcoming Java EE 7 features. Yesterday the results were published.
Over 1,100 developers participated in the survey and there was a large number of thoughtful comments to almost every question asked. Compare the prepared PDF attached to the EG mailing-list discussion.

New APIs for the Java EE 7 Profiles
We have a couple of new and upcoming APIs which needs to be incorporated into either the Full or the Web Profile. Namely this are WebSocket 1.0, JSON-P 1.0, Batch 1.0 and JCache 1.0. The community was asked in which profile those should end up. The results about which of them should be in the Full Profile:

Add to Full Profile?

As the graph depicts, support is relatively the weakest for Batch 1.0, but still good. A lot of folks saw JSON-P and WebSocket 1.0 as a critical technology.
The same for both with regards to the Web Profile. Support for adding JCache 1.0 and Batch 1.0 is relatively weak. Batch got 51.8% 'No' votes.
Add to Web Profile?

Enabling CDI by Default
The majority (73.3%) of developers support enabling CDI by default. Also the detailed comments reflect a strong general support for CDI as well as a desire for better Java EE alignment with CDI.

Consistent Usage of @Inject
A light majority (53.3%) of developers support using @Inject consistently across all Java EE JSRs. 28.8% still believe using custom injection annotations is ok. The remaining 18.0% were not sure about the right way to go. The vast majority of commenters were strongly supportive of CDI and general Java EE alignment with CDI.

Expanding the Use of @Stereotype
62.3% of the attending developers support expanding the use of @Stereotype across Java EE. A majority of the comments express ideas about general CDI/Java EE alignment.

Expanding Interceptor Use
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. The remaining 12.2% were certain that there are places where injection should be supported but not interceptors.

Thanks for taking the time answering the survey. This gives a solid decision base for moving on with Java EE 7. Keep the feedback coming and subscribe to the users@javaee-spec.java.net alias (see archives online)!

Post a Comment

3Comments

  1. For reference, the original survey is posted here: https://blogs.oracle.com/reza/resource/Java_EE_7_Survey.pdf. I too would like to thank each and every one of the 1100+ develpers that took time out of their busy lives to meticulously fill out 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 stay involved, perhaps through the Adopt-a-JSR program: https://blogs.oracle.com/theaquarium/entry/adopt_a_java_ee_7.

    ReplyDelete
  2. Reza, thanks for giving the community the opportunity to be involved. I'm sure this is appreciate by many!

    ReplyDelete
  3. This was not in the survey, but EJB interoperability between different vendors would be my top of the list. It should be specified that and how e.g. an EJB running in JBoss could call an EJB in Glassfish or Weblogic. And a Java client should be able to call any EJB of any vendor without code changes and without having vendors' client jars, it should suffice to just change a server URL.
    Currently one often has to use Webservices or go back to EJB2.1 and Corba to have interoperability, but an EJB call would be much simpler and faster.

    ReplyDelete
Post a Comment