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.