Adam Bien's Weblog

The Only One Dependency You Need In Java EE 7

Java EE 7 projects need only one single dependency in pom.xml:


This javaee-api dependency contains all Java EE 7 APIs (from EJB, JTA, JCA over CDI to JPA), is 1.8 MB big and because the server implements the APIs, it never ships with the WAR.

Mainstream Java EE projects can be easily built with the following pom.xml:


Gradle build script has similar length:

def WAR_NAME='skinny.war'
apply plugin: 'war'
apply plugin: 'maven'
group = 'com.airhacks'
version = '0.0.1-SNAPSHOT'

repositories {
dependencies {
    providedCompile 'javax:javaee-api:7.0'

compileJava {
    targetCompatibility = '1.8'
    sourceCompatibility = '1.8'

    archiveName WAR_NAME

Project structure for skinny projects can be easily created with mvn archetype:generate -Dfilter=com.airhacks:javaee7-essentials-archetype.

See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting. Is Munich's airport too far? Learn from home:

NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.


A book about rethinking Java EE Patterns


In theory that's true. But in practice there is a problem with that dependency: IntelliJ Idea can't find jstl tlds any more. This was not an issue in version 6.0. That's why I use jboss-javaee-7.0 instead.

Posted by Paweł Walczak on February 04, 2016 at 07:35 AM CET #


the problem was solved a few years ago:

Java EE 6 API were only meant for compile -> the classes could not be loaded,



Posted by on February 04, 2016 at 10:10 AM CET #

As cool as your recipe sounds... Well, Adam, I strongly disagree. In a way, you're absolutely right. All you ever need to use JavaEE7 now is that single, simple dependency you mention in your post. But what about the future?

Mind you: every once in a while you meet a customer who is innovative. But that's the exception. More often than not, you meet a customer who just wants to have their job done. Recently, I've spent some time in the automotive industry, and they told me "we produce cars, not software". Which is to say: they don't want to care much about software. In particular, they don't want to care much about software updates. In my case, they strongly refuse to update from JavaEE 5. Chances are, they won't update any time soon.

That's a perfectly valid business decision. From the customer's point of view. My point of view is different, of course. I'm a software architect. I'm frequently reading your blog, so I'd like to use all this fancy stuff you write about. I don't want to force my team to use old-fashioned JavaEE 5. I want them to be as productive as possible. I want them them to earn money. I believe they are much more productive using JavaEE 7.

Actually, that wouldn't be a problem if I could convince my customer to use a simple Tomcat instead of an full-blown JaveEE application server. That, in turn, would force me to add each and every dependency manually. Thing is, it would allow me to do so. Currently, my customer uses a certain application server that doesn't even allow me to use a 2.0 version of the expression language. Which is to say, EL expressions aren't allowed to pass parameters. Granted, there are work-arounds, but you get the idea: Being stuck to the old version of JavaEE is not really fun. Needless to say it costs a lot of money.

There's that. The customer is happy. I'm not. I can deal with that.

But wouldn't it be nice if my team was able to use the next-generation API?

And - that's the other way round, and it is every bit as important - wouldn't it be nice if our customer could update their application server without having to update our application?

Both is perfectly possible with the Tomcat-only solution. The application is responsible for providing the JavaEE version it requires. It's up to the application developer to update the libraries or not. I've spent many hours discussing the pros and cons of my approach, so I know it's not the perfect solution to every problem. For instance, it shifts the responsibility to fix security leaks from the operations department to the developers. I'm totally aware of this. But I'm convinced this kind of problems are best dealt with by developers.

Your idea to simply add the JavaEE 7 dependency is going to backfire as soon as you meet a conservative customer. Or, for what it's worth, an all-too-innovative customer who updates eagerly.

Posted by Stephan Rauh on February 05, 2016 at 12:05 AM CET #


it boils down to two options. Either we use Java EE 7 server, or we transform Tomcat to a Java EE 7 server and let the client pay for that. It might be fun once, but not over and over again.

In the Tomcat case, I frequently deploy a WAR -- and Tomcat becomes TomEE. Then you only need a single dependency again :-)

All my current projects now are Java EE 7 + Java 8 projects Why? Because I explain the point 1. at the beginning of a project.



Posted by on February 05, 2016 at 03:09 PM CET #

Obviously, client preference affects, well, everything. The choices of platforms today are rarely purely technical.

We have legacy software that we still haven't moved off of GlassFish 3, for example. At least we can use Java 7.

But for a greenfield project, I'd still rather deploy a simple WAR onto GlassFish than Tomcat. The overhead of GF isn't enough to disqualify it compared to something "lightweight" like Tomcat. GF will use as much as your app wants to use in terms of services, and just flat out has a really amazing administrative aspect to it that Tomcat can't match.

Posted by Will on February 07, 2016 at 02:15 AM CET #

@Stephan, maybe you miss this rule (which I learnt in an Agile class): translate every technical thing into business value. For example, we use connection pool to be able to serve many users at a time, we use Java EE 7 to reduce the time to complete this project ...

Posted by Thai on February 10, 2016 at 07:45 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments