Walking through the Java EE 6 implementation maze
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 4, Geronimo 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 3, Codehaus+ | |
| 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 1, Weld 1, CanDI, 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/
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Michal Xorty replied on Sun, 2011/06/26 - 6:25am
Jonathan Fisher replied on Sun, 2011/06/26 - 1:08pm
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
EclipseLink MOXy (http://www.eclipse.org/eclipselink/moxy.php) is a JAXB 2.1/2.2 (JSR-222) implementation, that is currently missing from your list. MOXy offers extensions for:
XPath Based Mapping
External Mapping File
Mapping JPA Entities
Anton Arhipov replied on Mon, 2011/06/27 - 4:38pm
Anton Arhipov replied on Mon, 2011/06/27 - 4:43pm
Hantsy Bai replied on Mon, 2011/06/27 - 8:20pm
Sirikant Noori replied on Sun, 2012/01/15 - 12:24pm