What are: ThinWARs, HollowJARs, SkimmedJARs, FatJARs, UeberJARs, FatWARs and Executable Images?

ThinWAR
contains application code only. The runtime is strictly separated. "Hello,World" is about 4kB and takes advantage of Docker layering. The WAR is deployed to a (running) server.
HollowJAR
deployment comprises a single runtime JAR and an application "Thin"JAR (sometimes a WAR). The ThinJAR contains application code and it is going to be deployed at startup of the runtime. The ThinJAR (could be even a WAR) is as small as a ThinWAR and it also takes advantage of Docker layering.
SkimmedJAR (inversed HollowJAR)
the application JAR is executable and comes with a minimalistic bootstrap mechanism. The SkimmedJARs are larger: ~50-100kB than the strict "Thin*" variants. The immutable runtime JARs are strictly separated from application code. The SkimmedJAR has to be deployed on every "commit", the runtime remains untouched. There is no deployment phase, the runtime and the application are considered at runtime as a single unit.

In container environments the application JAR ships in the upper most container layer the infrastructure JARs in a layer below.

FatJAR, UberJAR, (actually: UeberJAR)
The application code and the runtime are not separated. Container image layering is not possible - everything ships at once. a "Hello,World" comes with a few MBs. FatJARs are perfectly suited for bare metal environments (without containers like e.g. Docker) and CLIs (like e.g. wad.sh, jwtenizr.sh). There is no deployment phase, there is only a single JAR.
FatWAR
Infrastructural services like e.g. Jenkins ship as executable WARs. (java -jar jenkins.war). Ease of installation is the main motivation. Container layering is not possible - everything ships at once.
Executable Image
Runtimes like GraalVM allow "Ahead of Time" compilation of Java applications. The AOT process results in an OS-specific, executable binary file, which contains the JVM, the runtime and the application code.

The executable image contains the JVM, entire runtime and the application code, so it does not take advantage of container layering. However the executable file is significantly smaller than the sum of all docker layers in a "traditional" Java deployment.

The smaller the deliverable (JAR, WAR) affected by a "commit", the less artefacts have to be built, packaged, (security) scanned, processed and uploaded to clouds.

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

Comments:

I wasn't completely understanding "HollowJAR", so I read https://dzone.com/articles/an-introduction-to-hollow-jars which helped.

A HollowJAR *deployment* consists of two things:
* The HollowJAR itself, which is the application runtime or "server".
* The ThinJAR/WAR that contains the actual application and business logic.

Then deployment looks like this:

java -jar hollow.jar application.war

We call it "hollow" simply because it doesn't contain any business logic. A server with no applications is "hollow".

I realize this is exactly what you wrote with fewer words, but I needed some extra words to understand it :)

Posted by David on October 22, 2019 at 07:13 PM CEST #

1.4M Thinwar. It is possible? Or I miss another kind of war :)

Posted by Albert on October 31, 2019 at 10:43 PM CET #

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