Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Apache Releases TomEE 7.1 with Support for Java 8 and MicroProfile 1.2

Apache Releases TomEE 7.1 with Support for Java 8 and MicroProfile 1.2

This item in japanese

The Apache TomEE community has released TomEE 7.1, a significant upgrade featuring support for Java 8 and MicroProfile 1.2.


In 2011, David Blevins, employed by IBM at the time, led a team of volunteers to create TomEE, a portmanteau blend of "Tomcat" and "JavaEE," which was introduced at JavaOne 2011. TomEE featured Apache components such as OpenWebBeans, OpenEJB and OpenJPA. The core values of TomEE was to be small; be Tomcat; and be certified. Blevins left IBM in 2012 to form Tomitribe, a company with a mission to:

Support the community and all things TomEE. We want to provide jobs for developers, provide support for customers, educate people on TomEE, open-source and JavaEE and contribute to the success of everyone in the community. We believe open-source is an ecosystem and everyone in that ecosystem has a role to play, from the people who produce it to the companies who use it.

Blevins currently serves as founder and CEO of Tomitribe.

TomEE 7.1

Tomitribe has provided a convenient way to upgrade to this latest version and more details on new features and upgrades can be found in the release notes.

Released just over a year ago, MicroProfile 1.2 introduced APIs JWT-Auth, Fault Tolerance, Health Check and Metrics. As part of Tomitribe's commitment to educating developers, Tomitribe provided and an introduction and tutorial on JWT-Auth and an introduction and tutorial on Fault Tolerance after the release of TomEE 7.1.

TomEE 8

With support for Java 8, TomEE 7.1 serves as a gateway for the GA release of TomEE 8 that will be compliant with Java EE 8/Jakarta EE and MicroProfile 1.3. The road to a GA release of TomEE 8 has accelerated with the availability of TomEE 8 M1.

Features in this milestone release include initial support for JSON-B (JSR-367) and Java EE Security (JSR-375). While not implemented in M1, the Java EE Security specification has been defined and will be implemented in a future milestone release. TomEE 8 M1 also includes updates to: CDI 2.0 (JSR-365); JAX-RS 2.1 (JSR-370); Servlet 4.0 (JSR-369); Bean Validation 2.0 (JSR-380); and JSF (JSR-372).

Other Projects

Tomitribe also offers a variety of other projects including a TomEE/JAX-RS starter project as an introduction to TomEE. This simple JAX-RS demo application models colors. After cloning the repository, simply execute the Maven command:

mvn clean install tomee:run

After the server has been started, the following can be executed on the command line or the browser:

While this demo application has been available for four years, it has been updated for TomEE 7.1.

Blevins spoke to InfoQ on this latest release.

InfoQ: What inspired you to create TomEE back in 2011?

David Blevins: TomEE is the union of so many motivations, it's hard to pick one. Largely, it was about changing the industry. Tomcat consisted of 50% of the market and the other 50% consisted of all the Java EE app servers together. Creating a Java EE implementation for the Tomcat community, who historically hated Java EE, was a deliberately targeted effort to unite the industry.

Another aspect was to redefine the enterprise as "small," i.e., a hundred times "small." It was clear the industry was moving away from "big" and there needed to be someone in Java EE pushing that direction with an implementation that focused on perfecting "small."

Finally, there was an incredible passion in the OpenEJB community that became a relentless drive to succeed and change the most stubborn of minds in the face of years of EJB bashing. For the two years prior to TomEE, we met in various places around the world to hack a week here and a week there. Each time we met, our dreams got bigger until TomEE was ultimately born.

InfoQ: What makes TomEE unique over the other middleware application servers?

Blevins: We aren't traditionally fans of "app servers." We like public-static-void-main. If it doesn't run in your IDE in a plain unit test within a second or so of overhead, we have no patience for it. That's the line.

TomEE can run as a traditional app server, but I and others personally most often run it embedded with no IDE plugins and no separate processes. The TomEE JAX-RS starter project shows a simple JUnit/Arquillian test that uses TomEE Embedded and runs in 3-5 seconds. Run mvn tomee:exec and you'll get an uber-jar version of your app.

The industry investment in Tomcat is a unique and major advantage to TomEE users. All Java related tools and cloud platforms have some form of Tomcat support. TomEE is just another version of Tomcat and it usually works out-of-the-box.

TomEE is a small 30-40MB download, boots in 2-5 seconds, takes less than 50MB of RAM, and is certified on Amazon AWS t3.micro instances, It was hands down the lightest Java EE 6 app server by wide margins in 2011. According to Antonio Goncalves' tests on Java EE 7 servers in 2016, TomEE was still leading. We'll see who grabs that title for Java EE 8. Everyone is catching up, which is really great.

InfoQ: When do you anticipate the release of TomEE 8?

Blevins: Giving timelines is a no-no for Apache open-source projects, so consider my answer as informal. I imagine the Java 11 compatibility work will last for a few weeks longer and the release of another TomEE 8 milestone when that completes. After that, there is a discussion on which version of TomEE we want to start running the newly open-sourced and not-yet-released Jakarta EE 8 TCK. Odds are, we will release TomEE 8 final in the January timeframe and then target Jakarta EE 8 compliance for TomEE 8.1.

InfoQ: Do you have any concerns over the recent announcement of IBM purchasing Red Hat and how that could potentially affect TomEE, Thorntail, OpenLiberty, Payara, and MicroProfile?

Blevins: Our potential for impact on the industry with regards to open-source colossally outweighs that of the vendors, such that if we want these projects to be fine, they will be. The hard part is self awareness.

I have a lot of friends in the Apache Struts community who were beyond frustrated last year when Equifax got hacked, lost 140 million social security numbers, $4.2 billion dollars off their market cap, and then blamed Struts. The attack is not material. The struggling open-source project who had already fixed the vulnerability is not material. The story is us as an industry and how we repeatedly cause our own failure because we don't understand we own the open-source we use and it is our responsibility.

If you use open-source and own a budget in your company, but do not direct some of that budget to the open-source you use, then all issues you face are self-inflicted. You made an executive call to underfund something critical to you. It's a risky choice and any and all financial loss your company suffers is on your head.

Be smart. Pull out your calculator and run up the numbers on how much it would cost you in time and effort to migrate away. Direct a percentage of that every year to the open-source you use and you will be absolutely fine.

How fine? We'll let's look at Struts again. Twelve months after the Equifax hack, showed companies had posted 1,721 job openings calling for Struts experience, which at a conservative $80K per head is roughly $137 million in planned spend on top of Struts. If that industry directed 5% of that into Struts itself, that'd be $6.85 million. So for a mere $3,980 from each Struts-seeking job-poster put into the project itself, they'd be getting the equivalent of 85.6 FTEs back in code. Which is better - one FTE at $80K or 85 FTEs for $4K?

We're not just bad at open-source, we're bad at math. We have an abundance of open-source developers. We need more open-source executives.

If you're worried about OpenLiberty or Thorntail, you've got about three years to start spending before any consolidation might happen. Your actions will decide what happens there, so don't complain in the future if you don't "vote." If you think the industry needs more "Red Hats," shift even a small amount of business towards Payara and Tomitribe and I guarantee you'll be amazed at the industry-level impact in two years.

InfoQ: What's on the horizon for TomEE especially, in terms of support for MicroProfile 2.0?

Blevins: I think there's a high chance MicroProfile 2.0 work will complete early in TomEE 8. MicroProfile 1.4 and 2.0 are functionally the same and TomEE is already just shy of 1.4 compliance. Right now, there is just one dedicated TomEE distribution that contains MicroProfile technology. It is not in TomEE Plus or Plume.

I expect there is a good chance those might be added to Plus and Plume or we might see another distribution of TomEE that contains all the Java EE and MicroProfile support we have in one box. It would only be about 4MB bigger than TomEE Plus is now. I would love to see a Jakarta EE 8 certified TomEE on the new Amazon AWS t3.nano instances.

People should expect a very significant increase in overall activity. The TomEE community has added more committers in the last 12 months than the previous six years combined which is a major reason for the new releases and activity. With MicroProfile flourishing and Jakarta EE emerging, finally all aspects of our industry are starting to look strong again, TomEE included.

Now is the time to be excited. Now is the time to commit. What's on the horizon for the TomEE community is a long-earned sunrise.


Rate this Article