Packaging Java programs in the modern age of microservices and mobile apps
The packaging of Java programs has taken an interesting turn, as the original JAR format becomes a favorite even for Java web apps deployed as microservices.
Right from day one, the standard format for packaging Java programs was the Java ARchive, or JAR file for short.
There was a tendency toward silliness in the naming of technical components in the early days of Java. The components you wrote were known as JavaBeans. And where else would you store JavaBeans other than in a JAR? So, from day one, the standard format for packaging Java programs was the JAR, and while times have changed and formats for packaging Java programs have arisen, it looks like the trend toward microservices and cloud-native development is ushering in a enthusiasm for the JAR.
Packaging Java programs as JAR files
There's nothing particularly interesting about a JAR file. At its heart, it's simply a mechanism to compress multiple files. A JAR file uses exactly the same compression algorithm as popular archive utilities, such as 7-Zip and WinRAR. In fact, if you change the extension from .jar to .zip, it opens quite easily with WinZip or a TAR utility. Other than the Java-based contents contained within, a JAR really isn't anything special.
Packaging Java web apps as WARs
Like JAR, the Web Application ARchive (WAR), the default format for packaging Java web apps, isn't particularly special. When the Servlet and JavaServer Pages specification became available to facilitate the development of web-based applications, this WAR file format for packaging Java web apps arose. Java applications were packaged in JAR files, and web applications were packaged in WAR files. Shortly thereafter, developers started deploying Java web apps and Enterprise JavaBeans together as Java Platform, Enterprise Edition (Java EE) applications, so we needed a third format for packaging Java programs. This format for packaging enterprise Java programs was the EAR, an acronym for Enterprise Application ARchive.
Packaging Java enterprise apps as EARs
Since the release of Java 2 Platform, Enterprise Edition in December 1999, packaging web applications as WAR files, enterprise applications as EAR files and Java libraries or stand-alone desktop applications as JAR files has remained the Java standard. The emergence of cloud-native computing and microservices-based architectures, though, has triggered a sea change that could encourage the industry to embrace JAR files once again.
Historically, a servlet engine would host multiple Java web applications. But with microservices, the relationship is one-to-one. Docker flips the deployment model on its head. With Java web apps packaged within their own embedded Tomcat or Jetty container after each and every build, there is no longer a need for a full-scale Java EE-based application server to manage hosting. And since the WAR and the servlet engine are packaged together, the entire executable product is self-contained. It can be run on its own, on the Java Development Kit command line, just like any other stand-alone application.
Packaging Java microservices in containers
To keep in line with the philosophy that we should package independent, stand-alone Java applications in JAR files, the current trend is to package these embedded Java web applications as such. The fact that a Docker container can easily consume the executable JAR format makes the packaged Java artifact ripe for deployment as a Kubernetes orchestrated microservice.
So, the more things change, the more things stay the same. The history of packaging Java applications has seen a number of different formats and incarnations. But today, as microservices and cloud-native computing dominate the software development landscape, the original JAR format has become the preferred format. Long live the Java ARchive.
