What Archive Format Should You Use, WAR or JAR?

Some time ago, RAM and disk space were scarce resources. At that time, the widespread strategy was to host different applications onto the same platform. That was the golden age of the application server. I wrote in an earlier post on how the current tendency toward cheaper resources will make the application server obsolete, in the short or long term. However, a technology trend might bring it back in favor.

Having an application server is good when infrastructure resources are expensive, and sharing them across apps brings a significant cost decrease. On the downside, it requires a deep insight into the load of each application sharing the same resources, as well as skilled sysadmins that can deploy applications that are compatible on the same app server. For old-timers, does requiring an application to be run alone because it mismanages resources ring a bell? When infrastructure costs decrease, laziness and aversion to risk take precedence and hosting a single app on an application server becomes the norm. At that point, the next logical step is to consider why application servers as dedicated components are still required. It seems the Spring guys came to the same conclusion, for Spring Boot applications' default mode is to package executable JARs - also known as Fat JARs. Those apps can be run as java -jar fat.jar. Hence the famous:

'Make JAR, not WAR.' — Josh Long

It wrongly thought that application server providers were still stuck in the legacy way of doing things - thanks to Ivar Grimstad for making me aware of this option (a good reason to visit talks that do not necessarily target your interest at conferences). Wildlfy, TomEE, and other app server implementers can be configured to package Fat JARs as well, albeit with one huge difference: there’s nothing like Spring Dev Tools, so the restart of the whole app server is still required when code changes. The only alternative for faster feedback regarding those changes is to work at a lower level, e.g. JRebel licenses for the whole team. However, there’s still one reason to use WAR archives, and that reason is Docker. By providing a common app server, and Docker image as a base image, one just needs to add one’s WAR on top of it, thus making the WAR image quite lightweight. And this cannot be achieved (yet?) with the JAR approach.

Note that it’s not Spring Boot vs JavaEE, but mostly JAR vs WAR, as Spring Boot is perfectly able to package either format. As I pointed out above, the only missing piece is for the later to reload classes instead of restarting the whole JVM when a change occurs - but I believe it will happen at some point.

Choosing between the WAR and the JAR approaches is highly dependent on whether the company values more fast feedback cycles during development or more optimized and manageable Docker images.