Help

The Java EE 6 platform, along with Contexts and Dependency Injection, Bean Validation, EJB 3.1, JPA 2 and Servlet 3 have just been approved by the JCP EC. This completely changes the landscape for people developing web and enterprise applications in Java. There's just so much to digest here, and so many problems that are finally solved. EE 6 is something of a new start, and the beginning of a whole new ecosystem. Congratulations!

9 comments:
 
02. Dec 2009, 03:18 CET | Link

One might wonder what's SS/VMWare's contribution to JavaEE as they have exactly 0 votes in for all mentioned JSRs?

ReplyQuote
 
02. Dec 2009, 03:31 CET | Link
Evgeny Denisov

Gavin, what do you think about IBM's votes against 299 and 330 and can you explain in detail RedHat's comment to vote for JSR330?

 
02. Dec 2009, 04:02 CET | Link
Ales Justin wrote on Dec 01, 2009 21:18:
One might wonder what's SS/VMWare's contribution to JavaEE as they have exactly 0 votes in for all mentioned JSRs?

Well, they did vote for 330 ;-) They must, of course vote in the interest of the stockholders of VMWare...

 
02. Dec 2009, 05:18 CET | Link
They must, of course vote in the interest of the stockholders of VMWare...

Well, they didn't vote on any of the EE 6 JSRs, not even Servlet3 or Bean Validation. Surely at least some of those JSRs are in VMWare's business interest? I'm not sure if we can read too much into SS failure to vote, since they have made not voting on things a habit for a while now.

Remember when Rod was running around claiming to be on a mission to "open up" the JCP, whatever that meant? Well, AFAICT, that's pretty much the last we heard from them. Can anyone think of a JSR which they've made a significant contribution to? Even 330, which they were supposedly co-leading, was written almost completely by Bob, with little involvement from the Spring reps. Since they don't even seem to be able to fulfill their responsibility as an EC member to actually vote on important spec drafts, I think they should probably surrender their EC seat to someone who actually cares about the JCP and is eager to make a real contribution.

 
02. Dec 2009, 05:28 CET | Link

Wow, It's too good to be true! Congratulations to everyone, expecially to those that made a real contribution to approved JSRs!

 
02. Dec 2009, 05:44 CET | Link
Gavin King wrote on Dec 01, 2009 23:18:
Well, they didn't vote on any of the EE 6 JSRs, not even Servlet3 or Bean Validation. Surely at least some of those JSRs are in VMWare's business interest?

Voting for would indicate support. Now can just write stuff on top of them and sell them with We fixed this huuuuge hole in the specification with our framework

 
02. Dec 2009, 05:58 CET | Link
Evgeny Denisov wrote on Dec 01, 2009 21:31:
Gavin, what do you think about IBM's votes against 299 and 330 and can you explain in detail RedHat's comment to vote for JSR330?

Well, as I've mentioned before, 330 itself is a very problematic JSR, which in a perfect world would never have been allowed to go final in its current form. Unfortunately, javax.inject is deeply under-specified, and provides no real expectation of portability for application that use its APIs. We argue that, while this is certainly a problem, it is mitigated by the fact that you now have the choice to use a javax.inject implementation that also supports CDI, in which case you will get full application portability.

IBM thinks that, since so much in JSR-330 is open to interpretation, there is potential for future revisions of javax.inject and CDI to diverge and specify incompatible behaviors. To which we respond that this is a problem for the future.

IBM also believe that users will be confused into thinking that code they create using Guice or Spring should run without changes in Java EE. We don't think there is much potential for confusion, since it's not possible to create a working Guice or Spring application using javax.inject APIs alone. You also need com.google APIs or Spring XML. We don't think users will expect their Spring XML to work without Spring. Nevertheless, we certainly do need to emphasize to the community that javax.inject does not standardize all the bits of dependency injection, and does not provide application portability. If you are looking for application portability, and a truly standard dependency injection solution, with multiple compatible implementations, CDI is the only choice available today.

 
02. Dec 2009, 06:09 CET | Link

And if your follow-up question is why did we vote for 330 if we think it has so many problems - well, we decided to work with Google to align the specifications. The alternative course of action would have led to two competing, completely incompatible DI specifications in the Java platform. This would have been a much worse outcome. In the end, we have two specs that are well aligned, with 330 being a proper subset of 299. Yes, 330 is underspecified, but as long as you stick to using 299, you'll never notice, since 299 does specify all the things that 330 leaves out.

 
02. Dec 2009, 22:46 CET | Link
Mark Little | mlittle(AT)redhat.com

Congratulations Gavin and the team!!

Post Comment