Talking TomEE with David Blevins - Part 2
JAX: I remember seeing on the original 1.0 release, TomEE boasted that it was 300% faster. How was that achieved?
A lot of that was done through reduced scanning. So, Confluence is about 200MB and 199 JARs. When we boosted the performance, we didn't get it tuning things using the approach where we magically know what to skip. That would be unfair. When someone in the wild throws a 200MB file at you, you don't have the luxury of knowing which parts of the Web app are important, which ones aren't and being able to tune accordingly. We just really really revamped all the scanning code. We got the scan time alone down from about 8 seconds to 2 seconds which really cuts down on the overall deploy time. And then there was another round of further tuning. It was just a lot of cranking on the bolts and tightening of screws to get it into production shape for a final release.
JAX: You passed the Oracle TCK test, which is quite the feat. How long did that take for a start?
Yeah. We started in about February 2011 with our first full run of the TCK. We were probably about 20% compliant then.
JAX: Not a bad starting point there then?
We had a good head start with a lot of the parts there already like EJB, JPA, JSF and obviously Servlets, JSP. But CDI was in constant flux and in general there are a lot of things you discover are missing features and hold you back from completing large sections of the TCK. It's all about filling in those gaps as quickly as possible. From there, we were able to reach full compliance by October. But it was close, we got our first pass at the end of September. Maybe a week and a half before JavaOne. We cut it so close.
JAX: Perfect timing though right?
We had our minds made up to make the JavaOne date. It was an incredibly challenging goal for the community and we really came together and made it happen.
JAX: I can imagine there were some late nights around that period.
Many of us had really late nights and really early mornings. I know myself, I was sleeping four hours a night for several weeks. It didn't stop until after JavaOne because once you pass the test, you have file your paperwork, you've got to make an announcement and get a release out the door and do it while preparing for JavaOne. That particular year, I spoke at six different talks, so I had a lot of material to produce. I don't think I really saw anybody at JavaOne (laughs). After that, I collapsed.
JAX: Moving on to Java EE - what are your thoughts about recent developments? Is it heading the right way?
Absolutely. I think that when Java EE 7 started out, it was assumed we would want to do some cloud-based things.
JAX: Because of the move toward standardisation...
Initially it was an obvious goal. But as we developed and went further down that path, it became clear that we weren't ready to do that yet. The fact that there was enough self-awareness shows it's an astonishing victory for standards because we all know what happens when things are standardised too prematurely with a non-proven API.
We end up having an API that is a false start and we have to figure how to bury it and supersede it with something. It's not a good position to be in and it's not what's standards are supposed to do. The fact that we could perceive that this was something that wasn't ready to be standardised, I think is exactly the kind of things that standard bodies should be doing. I really compliment the group for doing that.
That said, there are a number of really cool things being done in the various Expert Groups and being talked about in Java EE 7. JMS 2.0 is going to be a really great part of Java EE 7 as is JAX-RS 2.0. Then there are things coming from the TomEE side as well. I had hoped that TomEE would be an important contributor to the specifications in the same way OpenEJB was to the EJB specifications. It's looking like we're going to be able to add some neat things, or at least inspire some changes.
We have a proposal for revamping the Connector Architecture and MDB relationship to handle modern APIs. Something like JAX-RS could have been done via the Connector Architecture with the right tweaks to that model. It sounds a little bit boring on the surface, but imagine being able to create an expressive API modelled like JAX-RS but for consuming email or exposing an SSH interface or accepting Thrift requests and dropping that into any certified Java EE server and having the components that accept those requests just as integrated into the platform as Servlets, EJBs or CDI beans are.
Another one of them is this concept of 'meta-annotations' we introduced it at JAX London 2011. It's a concept of broadening annotation reuse consistently to the entire Java EE platform. These concepts started popping up in various Java EE 6 specifications. Bean Validation which allows for reuse of validation annotations on other validation annotations. So say you add @NotNull on a bean validation annotation, the new annotation implies @NotNull plus the additional constraints it adds.
With CDI, there's a similar concept called Stereotypes. If say @Red is an annotation annotated with @Stereotype, @Named and @RequestScoped or any other CDI aspect. Anywhere you use @Red it implies that component is @RequestScoped and @Named. Now instead of using all those annotations, you just use @Red.
This concept exists, but someone inconsistently in various specifications and there is currently no ability to reuse annotations that are standard annotations such as any of the annotations from the Servlet, JPA, EJB, JSF, JAX-WS or any similar APIs. The value of such reuse is only as powerful as the number of annotations that allow reuse. Currently, that's almost none.
JAX: Is that more a matter of time before we see annotation reuse concepts occurring throughout Java EE or does it need a push?
No, I think the push has been made now. Aside from JAX London, I've presented afterwards at JavaOne 2011 and 2012. I'll be presenting it again along with the Connector revamp at W-JAX and Devoxx. I've also been working with various people from other app servers on what would be the performance impact of having this annotation reuse enabled all the time. We've already had this implemented in TomEE back in 2011 and we found it to not have a significant performance impact. As we've been working with more people, they've found the same thing. So now it's a question of how we want to do this.
The current proposals on the table is that @Stereotype would be what we proposed as @Metatype and would be the annotation that would drive this annotation reuse. Then we would go through and we would change all these Java EE annotations so they could be applied to @Steretype and other annotations.
JAX: Good to hear. There was a TomEE 1.5 release recently – was that a case of listening to the community and fixing a few things?
We received a flood of feedback from 1.0. So much feedback it was difficult to close the lid and say no more fixes. By the time we did close the lid, we had major new features such as the JAX-RS certification, several of the new tools. The textual description of the 1.5 release notes appears to be very short but if you look at the actual change list, it's difficult to summarise it all. I would say usability, migration issues and rounding off of sharp corners are all very strong aspects of the 1.5.
JAX: What are the plans for TomEE moving forward then, if you're allowed to divulge in them?
I can speculate of course, but the community sets the direction.
JAX: As any good project should.
Exactly. I'd personally like to see more of the same things we've been doing. We need to continue to address migration issues. We need to do more along the lines of helping people find the right information to the problems they might encounter. Very basic things like that. There is already a lot of functionality within TomEE which we need to make more accessible and known.
Continuing to do that is great. In terms of next major things, obviously Java EE 7 is right around the corner. That's going to be Tomcat 8, Java 7 and will contain a lot of new technologies. That will be an all consuming focus of the project a year from now. Between now and then it's about focusing on basics. I know from experience that you only have very short windows between major spec revisions to really focus on the fundamentals before you have to go back into a very major implementation/integration phase. We need to keep driving down the path we're on, filling out TomEE in terms of monitoring and other types of production concepts and focusing on the fundamentals of the server.
This interview first appeared in JAX Magazine: JavaFX Revisited. Download that and other issues here.
- The Components of TomEE
- Certification and the next steps.