Antonio Goncalves is a senior software architect living in Paris. Initially focused on Java development since the late 1990s, his career has taken him to different countries and companies where he works now as a Java EE consultant in software architecture. As a former BEA consultant he has a great expertise in application servers such as Weblogic, JBoss and, of course, GlassFish. He is particularly fond of Open Source and is a member of the OOSGTP (Open Source Get Together Paris). He is also the co-creator of the Paris Java User Group and talks on Les Cast Codeurs podcast. Antonio wrote a first book in French on Java EE 5 back in 2007. Since then he has join the JCP and is an Expert Member of various JSRs (Java EE 6, JPA 2.0 and EJB 3.1). He then published a second book for Apress: Beginning Java EE 6 Platform with GlassFish 3. For the last years Antonio has been talking at international conferences mainly about Java EE, including JavaOne, The Server Side Symposium, Devoxx, Jazoon… He has also written numerous technical papers and articles for IT Web sites (DevX, JaxEnter) or IT magazines (Programmez, Linux Magazine). Antonio is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Walking through the Java EE 6 implementation maze

06.25.2011
| 9329 views |
  • submit to reddit

I’ve been asked so many times “what are the implementations of such or such specification in Java EE 6 ?” or “what is the reference implementation of such a spec ?“. Because I always forget some (and to be honest, sometimes I don’t even know if a spec has several implementations of not), I’m writing this post to help me (and you) to remember.

So here is a non-exhaustive list of the several Java EE 6 implementations (please leave a comment to add anything to this list) :

Specification Version JSR Prunned Reference implementation Other implementations
Java EE 6.0 316   GlassFish V3 JEUS 7, Websphere 8, Geronimo 3*, Weblogic 12g
Web Profile 1.0 316   GlassFish V3 JBoss 6, JBoss 7*, Resin 4Geronimo 3*, Siwpass 1, Weblogic 12g, TomEE*
Managed Beans 1.0 316      
JAX-RPC 1.1 101 Yes    
JAX-WS 2.2 224   Metro Axis 2, CXF 2,
JAXB 2.2 2.2 222   Glassfish JAXB 2.2  
JAXM 1.0 67   Glassfish SAAJ 1.3  
StaX 1.0 173   Sjsxp 1 Woodstox 3Codehaus+
Web Services 1.2 109      
Web Services Metadata 1.1 181      
JAX-RS 1.1 311   Jersey 1.x Wink*, CXF 2, Resteasy 2, Restlet 2,
JAXR 1.1 93  Yes   Scout 1,
JSF 2.0 314   Mojara 2 MyFaces 2,
JSP 2.2 245   GlassFish JSP 2.2  
Debugging Support 1.0 45      
JSTL 1.2 52   Glassfish JSTL 1.2  
Servlet 3.0 315   GlassFish 3 Tomcat 7, Jetty 8,
Expression Language 2.2 245   GlassFish EL 2.2 JUEL 2,
EJB 3.1 318 Entity Beans CMP GlassFish 3 OpenEJB 3.1,
Interceptors 1.1 318      
JAF 1.1 925   GlassFish JAF 1  
JavaMail 1.4 919   Kenai Project+ GNU Java Mail, Geronimo JavaMail,
JCA 1.6 322      
JMS 1.1 914   Open MQ 4 ActiveMQ 5, SonicMQ, HornetQ 2, Websphere MQ, Joram,
JPA 2.0 317   EclipseLink 2 OpenJPA 2, Hibernate 3.5,
JTA 1.1 907     Atomikos, BTM, JBoss Transaction, SimpleJTA, JOTM,
JACC 1.1 115      
Bean Validation 1.0 303   Hibernate Validator 4 Apache Bean Validation*
CDI 1.0 299   Weld 1 OpenWebBeans 1, CanDI,
Dependency Injection 1.0 330   Guice 3+ OpenWebBeans 1Weld 1CanDI, Spring 3,
Common Annotations 1.1 250      
Application Deployment 1.2 88 Yes    
Management 1.1 77      
JASPIC 1.0 196      

(*) not final yet at the time of writing this article  (+) not sure about that

Yes, it’s a maze and sometimes it’s difficult to walk through it… but hey, that’s also the strengh of being standard, portable and avoiding vendor locking. I will never say that an application is 100% portable through implementations (if you hear someone telling you this, don’t trust him/her), but it can get close to 100% in many cases. That’s also the difference between standard and defacto-standard (check the definition of De Facto).

And because I get lost in this maze, please help me in finding my way out. If I’ve missed something and I’m mistaken, please use the comments to improve this maze and give me your suggestions.

 

From http://agoncal.wordpress.com/2011/06/24/walking-through-the-java-ee-6-implementation-maze/

Published at DZone with permission of Antonio Goncalves, author and DZone MVB.

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

Tags:

Comments

Michal Xorty replied on Sun, 2011/06/26 - 6:25am

Very nice list, bookmar added! :)

Jonathan Fisher replied on Sun, 2011/06/26 - 1:08pm

That's pretty awesome that you get that kinda of choice in JEE :) Granted, it's probably overwhelming for newcomers, but it's simply amazing that you really have the power to choose your entire stack, front to back.

Kenneth Mark replied on Sun, 2011/06/26 - 10:15pm

Very much appreciate your work for such as extensible list.

 

Niklas Schlimm replied on Mon, 2011/06/27 - 7:45am

Voted up for this :-) Very nice article!! Although, I find the comment in the end on "de facto" irritating. Of course, if you use an API that is only implemented by one vendor, then you're "locked" (sounds negative!). On the other hand, say with Spring, that has never been an issue in the past (downwards compatible, fast innovation). With JEE it has been an issue, cause you're were not locked with a vendor (that implements the API) but with those that may influence the JCP process, or with immature API specification (see EJB nightmare in the last decade). With open source frameworks you can go with one vendor and fork if you're not willing to follow anymore. Difficult discussion anyway ...

Cheers, Niklas

Reza Rahman replied on Mon, 2011/06/27 - 9:17am

Forking sounds good in theory, but the reality is that forking any open source project is like being handed down a very large legacy application with no one to help you navigate it - which is a big reason why most forks never wind up being a success. There is not even a comparison for the average development effort as to the comparative practicality of forking vis-a-vis simply switching implementations. It's also the case that open source and open standards are not a dichotomy -- they are meant to go together. In fact, the most major Java EE implementations are all open source -- like Resin.

The JCP is not perfect, but in many ways it is better than existing standards bodies. It is an excellent mechanism for developers (like Antonio), the community (like the London Java Community) and vendors (like Caucho, JBoss and Sun/Oracle) to collaborate together to standardize solid innovations in a sensible time-line. To see for yourself or even better, join in right now -- look here. The reality is that JCP expert groups highly prize any positive contributions from independents, so it is well worth your effort.

Blaise Doughan replied on Mon, 2011/06/27 - 12:22pm

Anton Arhipov replied on Mon, 2011/06/27 - 4:38pm

howcome, Managed Beans do not have a reference implementation?

Anton Arhipov replied on Mon, 2011/06/27 - 4:43pm

CDI is Weld and DI is Guice 3 - a bit cumbersome. Why couldn't it be just one

Hantsy Bai replied on Mon, 2011/06/27 - 8:20pm

OpenEJB 3.1 does not implement all features of the EJB 3.1 specification now.

Sirikant Noori replied on Sun, 2012/01/15 - 12:24pm

RichFaces, ICEFaces and so on do not implement JSF, they are component libraries (they bring you extra components, they rely on the spec, they do not implement the spec)

Comment viewing options

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