The world of Java EE (formerly J2EE) seems frozen in time. The people who care about application servers tend to dwell in gray cubicle farms. They need WebSphere to stay up on their P6/P7 hardware, but aren't really thinking about the future too much.
The counterpoint to that legacy caricature is Apache TomEE -- and the recent announcement by PaaS provider Jelastic that it's adding support. TomEE is a Java EE version of Apache Tomcat that embraces several related Apache Java projects as well.
TomEE gives proof to a corollary to Conway's Law, in that it very much reflects the personality of its founder, David Blevins. A longtime Java EE and open source veteran, Blevins is a co-founder of OpenEJB (1999) and Apache Geronimo (2003). He has worked actively in the Java Community Process since EJB 3.0 and more broadly in Java EE since Java EE 6.
I asked Blevins what motivates him, and he cited "a somewhat stubborn nature and belief that while some things may get a bad reputation, such as Java EE, it's never as bad as is perceived. I'm not a fan of the polarization that happens around these types of debates and very much believe a middle ground can be achieved."
More about TomEE
Get JavaWorld's Enterprise Java newsletter delivered to your inbox.
A social experiment
During the height of both J2EE and anti-J2EE, David founded OpenEJB, an embedded EJB container project. Blevins prefers to counter "people [who] say X is impossible or sucks" not "by arguing with people, but by actually listening and changing what it is people don't like. It doesn't always mean people will come around, but I enjoy seeing how or if things change. In a lot of ways it's a social experiment."
His current project, TomEE, was taken up last week by the PaaS provider Jelastic as one of its many options. TomEE reflects Blevins' motivations:
With TomEE, we'd like to change the stale debate of what is or isn't Java EE, what you can and can't do with Tomcat, put and end to old arguments, and ultimately save people time and scratch an itch we don't think has ever been scratched. That is, "Do we use Tomcat or Java EE?"
TomEE is to a good degree an outgrowth of OpenEJB. In order to work on TomEE full time, Blevins recently left IBM, where he worked on Geronimo, the basis for IBM's WebSphereCE project. For the TomEE project, Blevins noted, "We have quite a large committer base due to the roots in OpenEJB which has been around for years. Of that there are about five or six active at any given time and who that is varies from month to month. It's largely volunteer-driven, so even with 20 or 30 committers it's a fairly focused number of people working to achieve something specific for periods of time." That's pretty good for a project of this type and a problem of that size.
TomEE is partly composed of Blevins' previous projects, as well as associated bits and pieces from existing open source projects. According to Blevins:
Aside from Tomcat itself, the main parts are MyFaces, OpenWebBeans, OpenJPA, OpenEJB, BeanVal, and TransactionManager. In TomEE+ we also have ActiveMQ and CXF. As for how much is unique code, I suspect the question is how much code did it take to tie them all together. The answer is not much, but it was incredibly difficult to cross the t's and dot the i's.
Blevins notes that besides freeing you from the work of "build your own app server," TomEE contains performance improvements:
The more things you drop into Tomcat the more third-party libraries you have scanning your Web app for annotated components: Tomcat scans for @WebServlet; MyFaces scans for @ManagedBean; OpenJPA scans for @Entity; CXF scans for @WebService and @Path; OpenEJB scans for @Stateless, etc. Scanning literally means opening each jar in the Web app and reading each class file, parsing it with something like ASM, and seeing if it has an annotation that is interesting. You really don't want to do this five times each startup. For just this reason alone we find some people reporting that their Tomcat apps start faster after moving them onto TomEE where those libraries are better integrated. We also do things like integrate JAX-WS security onto Tomcat Realms so everything is nicely ready to go out of the box.
Java EE has been both pushed forward and hobbled by the Java Community Process. I asked Blevins what he thought about the JCP post-Oracle. His reply:
Shortly after Apache and others left the JCP, Oracle, with significant help from others, put together a plan for reform. This is JSR-348, which is now implemented and mandated and really is just the beginning. If you haven't at least read the JSR description for 348 I strongly recommend it. It takes concrete action to ensure transparency and create openness for all JSRs, going to the level of requiring basic things like open mailing lists for every JSR, requiring public issue trackers, and even putting measures in for Spec Leads that may not be active enough.
What I find interesting is that the long trip of Java EE always comes back to Tomcat. This is more or less where it started and more or less where it is ending up, with multiple vendors providing Tomcat+ offerings. TomEE is both an argument for and against Java EE's programming model -- and its use as a spec for a big, fat monolithic app server like WebSphere or WebLogic. Blevins' pragmatic play will yield new remixes of not only Java EE, but Spring and probably some of the newer stuff like the Play framework.
This article, "Can TomEE save Java EE?," was originally published at InfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
This story, "Can TomEE save Java EE?" was originally published by InfoWorld.