Reza Rahman is a former independent consultant, now Java EE/GlassFish evangelist at Oracle. He is the author of the popular book EJB 3 in Action. Reza is a frequent speaker at Java User Groups and conferences worldwide. Reza has been a member of the Java EE, EJB and JMS expert groups. He implemented the EJB container for the Resin open source Java EE application server. All views voiced are my own, not necessarily Oracle's. Reza is a DZone MVB and is not an employee of DZone and has posted 184 posts at DZone. You can read more from them at their website. View Full User Profile

JMS 2, Bean Validation 1.1, JBatch, JSON-P Go Final!

  • submit to reddit
Java EE 7 is almost to the finish line! The first slew of Java EE 7 JSRs have successfully passed their Final Approval Ballots and are now final. JMS 2 (JSR 343), Bean Validation 1.1 (JSR 349), JBatch (JSR 352), and JSON-P (JSR 353) all passed with near unanimous support from the JCP Executive Committee. Please join me in congratulating spec leads Nigel Deakin of Oracle, Emmanuel Bernard of Red Hat, Chris Vignola of IBM, and Jitendra Kotamraju of Oracle on the fruition of all their hard, often thankless work.

We expect more Java EE 7 JSRs to follow suit shortly, so stay tuned. This is a great time to read the final specs and start experimenting with them in the GlassFish 4 builds.

Published at DZone with permission of Reza Rahman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Hussachai Purip... replied on Thu, 2013/04/11 - 3:38am

Congrat!Thank you Nigel Deakin, Emmanuel Bernard, Chris Vignola, 
and Jitendra Kotamraju for your hard work.At least, I made this time wasn't thankless work for them. :D

Henk De Boer replied on Wed, 2013/04/17 - 9:08am

Thanks a lot to the JMS EG group for finally allowing us to define JMS destinations from our applications! :D

No more weeks of negotiating with some unwilling ops guys to let him create a simple JMS queue that's 100% internal to the application.

Not so much thanks to IBM though who led the Java EE concurrency spec and felt that in 2013 developers should still be considered idiots who aren't allowed to create a thread-pool from within their apps (all Java EE concurrency artifacts have to be created by ops personnel at the AS side, as-if it was 2004 all over again).

Reza Rahman replied on Wed, 2013/04/17 - 2:42pm

I'll pass on the feedback, it's a good point. Too late for this time around unfortunately.

Henk De Boer replied on Thu, 2013/04/18 - 5:08pm in response to: Reza Rahman

Thanks a lot! Please do.

I'm not saying btw that the ability to let ops personnel define it at the AS side is always wrong. There are situations where it's really a good idea to have an AS wide thread pool (and executor services, etc), but it just doesn't cover the entire spectrum. For some situations administered objects are better, and for some application defined ones are better.

Java EE should support both cases and be able to scale both up and down.

I strongly feel IBM tried to enforce what from their perspective is a best practice, but as said it isn't valid for all use cases out there.

Besides this thorny issue I think they did a great job, so not all is bad ;)

Reza Rahman replied on Thu, 2013/04/18 - 6:07pm in response to: Henk De Boer

Your feedback fits perfectly with the PaaS requirements we are very likely to try to address with Java EE 8.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.