I saw this project and it sounds to be interesting , though im not sure that will make differences for .jar programs/applications. my main concern is this:
since .jar need java already installed inside the distro in order to make it work, well how about AppImage?
A- If java need to be installed on the distro as well , then AppImage not a big different.
B- if JRE or OpenJDK ā¦etc going to be shipped by default inside an the AppImage then:
when there is security problem that JRE/JDK need to be updated should the appimage developer implement that? ->
if not then will it be upgradable with appimageupgrade without the developer interfering (like linking it to the main upgradeable link of the program or so) ? ->
if not then thats very horrible problem of having appimage in a secure or not headacheable way to the developer.
Funny Note: AppImage in concept sound cool but in the name sound horrible because it reminds me of AppStore which used inside the surveillance operating system Apple-IOS.
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.
AppImage follows the āone app = one fileā philosophy which mandates that everything either needs to come with the default installation of each target system (distribution), or needs to be bundled inside the AppImage.
Since we cannot reasonably assume that a Java runtime is installed by default in each target system (distribution), applications that need it need to bundle a private version.
Should an update of the JRE be needed, then the AppImage should be updated. Thanks to AppImageUpdate binary delta updates, users would only need to download the bits that have changed.
since .jar need java already installed inside the distro in order to make it work, well how about AppImage?
) then you need to utilize the