It’s all about deciding on how a specific application project could best delivered to the end-users. AppImage is just on choice amongst many.
You could say that .JAR archives where the first type of application containers and JVM the initial form of application virtualization, from where projects like Docker, FlatPak and Snappy derive their deign principles from, with the difference of having the container acting as the virtualizer instead of having the virtualized session executing the application container archive (JVM use-case).
You can consider AppImage as the .JAR files of Linux.
With that in mind, a .JAR file holds only resource based data (.class files and embedded binary files such as images, config files, embedded database files …) that exist within domain-specific class-path (e.g. com.myapp.resources.myAppIcon.png) which are accessible only to the application instance once objectified by a class reference (e.g. Image app_icon = new Image(this.getClass().getResourceAsStream("/com/myapp/resources/myAppIcon.png"); ). Now, if you have files that need to be accessed outside of the application instance (e.g. from a GNU-based Linux OS class-path -or- from a WFT-is-this-mess? Windows OS classpath ) then you need to utilize the java.io functionality that will basically instruct the JVM to stream that data in the application context (and the opposite for creating or saving to files).
Having that said, AppImage offers several traits can complement a Java based application such as:
- Have a container that will contain both the .JAR application as well as any referenced .JAR libraries and other non-resource based classpath files ad (optinaly) the JRE runtimes if the project requires a specific version of the JVM in order to operate as expected.
- Have pre/post execution shell scripts to perform processes in regard to the application’s execution (e.g. set/update host OS environment-variables, add external library/application references from the host OS to the application execution classpath, …)
- Have OS integration of the AppImage package with the ‘appimaged’ utility.
- Have all of the above and many other nice stuff in a nice little package for non tech users to be able to use without having the need of a computer-science degree.
Regarding security, Java is extremely secure by design, but still, whether your developing an app in C/C++, Python, Java or even using a bunch of shell-scripts, 99% of the security aspect is the developer’s responsibility. Application containers and virtualizers will only offer the tools to enable for secure development. The rest is up to the developer.
P.S. Apple also uses similar principles to AppImage with their .DMG package system.