How Much Code You Can Delete With Vanilla Java EE 7 - Some Numbers

Sebastian please briefly introduce yourself.

I'm a freelancer working as consultant, software architect and developer, living in the beautiful city of Munich. I've been enjoying — not working with — Java for more than 5 years now and I really like the productivity of the language — especially when working with Java EE.

You are the author of the great jaxrs-analyzer-maven-plugin. How you got the idea and how long did it take to implement this tool?

Well, I got the idea because in my client's projects it's almost always needed to have a documentation of the RESTful resources in a Java EE project. This was mostly done by writing Swagger JSON or any other text format by hand. There've already been some tools around which could automate that task by code analysis but I haven't been too happy with the depth of information of the results. I created my tool which analyzes JAX-RS using a Bytecode analysis algorithm as part of my computer science thesis in about 3 months and I'm continuing to work on it in my spare time.

You attended JavaOne 2015. Was it worth it?

Yes, definitely. This was my first time at JavaOne and I was able to attend some very interesting sessions and just as well I could connect with a lot of people of the Java community. I participate in the JCP as an individual member and so it was very exiting to have a chat with some of the spec leads and expert group members of the new Java EE 8 JSRs. And of course the evening events of JavaOne were a great pleasure.
San Francisco is probably interesting as well but there's a constant lack of time when going on a conference... — at least I had the chance to see the Golden Gate :-)

During a JavaOne session we coincidentally found that the JCountdown AdoptOpenJDK project was unnecessary bloated. You brought it back to vanilla Java EE 7 and Java 8. How much code have you deleted?

Yes, there were tons of unnecessary or even unused Maven dependencies, over-engineering in the code and inconvenient use of features like CDI. But in fact it was a pretty good example of what I see in real world projects as well... I really deleted half of the project — from more than 2,200 LOC to about 1,100.

How many Maven pom dependencies were removed?

I removed 15 (!) Maven dependencies, mostly because they aren't needed anymore in the age of Java EE 7 but some of them weren't even used in the project at all. All plugin definitions have been removed as well. Now it only contains the (provided) Java EE 7 dependency and the needed DB driver for MongoDB — the latter will also move to the application server's lib as soon as the cloud provider allows that.

What was the difference in WAR size before and after the migration?

The WAR file size went from 2.3 MB to 2.0 MB, not that spectacular as a lot of the unneeded dependencies were (esoteric) test frameworks. We definitely want to move the DB driver bloat to the server's lib as that would result in a WAR with not even 200 KB.
And IMO this is one of the biggest advantages of the Java EE standard: tiny deployment artifacts without any plumbing content which allow very fast builds and fast deployments.

Did your migration influenced the build times meaningfully?

Well, as we've been using Java EE in an older version before the build was already resonably fast. But still the migration changed the build time from 5 to 3 seconds (measured on my 4 years old ThinkPad) — yes, every second counts :-) However, in some projects I would even be happy with 10 second build times because using other "light-weight" web / enterprisy frameworks very often result in deployment artifacts of 50 MB or more and build time of several minutes...

What is your general impression of Java EE 7?

Java EE 7 even improves the great developer experience of Java EE 6. It's really incredible what you can achieve and what ideas can be realised in a really short amount of time.
But I think the real advantage over other competitors is the standardization in forms of JSRs. Standards may sound boring but you can not only choose your provider and be independent from any company but also you can rely as a developer that some feature will not just change and stop working — which is crucial for long-term projects in the enterprise world.

Any links and resources you would like to share with readers? How we can hire you?

I can really recommend to have a look at the Java EE related JSRs. I would download the needed specifications and do a full-text search for specific topics while programming and having questions about the technology. The specs are of course very technical and not that easy to read but I would challenge the readers of Adam's blog to at least give them a try :-)
For the enthusiastic Java developers out there I can also recommend to follow the ongoing Java EE 8 JSRs. The expert group mailing lists are public to everyone and it's really interesting to see in which direction the technology evolves.

I'm indeed available for hire and you can find my contact data under I'm favourably looking for Java EE 7 migration projects and giving technical consultation for clients.

Sebastian, thank you for the interview!

The nice thing about this migration story: it is based on an open source project which is part of the AdoptOpenJDK github repository. Checkout the repository: try to streamline the project even further and create a pull request.


we went from ~40k to 10k loc...

Posted by Adam Kędziora on November 18, 2015 at 11:00 AM CET #

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