Desktop apps have long been passed around as single jars. I have done all kinds of things to pack fatjars full of things that needed recursive unpacking. Including JNI shared libraries that I could then load to provide missing OS support functions not in Java.
Sent from my iPhone > On Oct 7, 2021, at 3:05 AM, Glavo <zjx001...@gmail.com> wrote: > > Of course, this is feasible and will not introduce many new problems > like jlink. It's just not that convenient. It just introduces some > additional deployment steps, which is not so convenient. I believe that > it is very attractive to only distribute and deploy a single file, > which is proved by the popularity of fatJar and Golang. > > Mantas Gridinas <mgridi...@gmail.com> 于2021年10月7日周四 下午3:35写道： > >> I am a tad bit confused. How come packaging everything into a regular zip >> file and extracting it during deployment is not feasable solution? If >> anything, you retain ability to do partial updates to your deployments. >> Such approach also removes the need for special classloader that is capable >> of loading nested jars. This in turn makes packaging and runtime much >> simpler too, as you dont need to repackage the runtime jar. >> >>> On Thu, Oct 7, 2021, 06:57 Glavo <zjx001...@gmail.com> wrote: >>> >>> Emmm... My words caused some misunderstanding. I should say that jpackage >>> is good, but without it, we can easily achieve the same function in >>> other ways, so it doesn't cause real trouble. What really causes trouble >>> and needs to be solved by fatjar is a different problem. It is difficult >>> for me to achieve close results by third-party means (e.g., let's bundle >>> program jars in lancher jar, decompress them to a temporary location >>> at runtime and load them dynamically. But compared with this scheme, >>> I would rather give up JPMS and go back to fatJar). >>> >>> Ioi Lam <ioi....@oracle.com> 于2021年10月7日周四 上午8:36写道： >>> >>>> >>>> >>>> On 10/6/21 12:45 PM, Glavo wrote: >>>>>> I know this doesn't remotely satisfy all your requirements, but are >>> you >>>>>> aware you can jpackage an app *without* bundling a JRE? >>>>>> >>>>> Ah, this is what I missed, but it won't solve any of my problems, >>>> otherwise >>>>> I have implemented a similar function by myself. >>>> >>>> Doesn't jpackage always bundle a Java runtime with the app? From the >>> docs: >>>> >>>> >>> https://docs.oracle.com/en/java/javase/17/jpackage/packaging-overview.html >>>> >>>> "To eliminate the need for users to install a Java runtime, one is >>>> packaged with your applications. The packaging tool generates a runtime >>>> image based on the packages or modules that your application needs. >>>> >>>> If no Java runtime image is passed to the packaging tool, then jpackage >>>> uses the jlink tool to create a runtime for the application." >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> Sebastian Stenzel <sebastian.sten...@gmail.com> 于2021年10月7日周四 >>> 上午2:06写道： >>>>> >>>>>> Interesting topic and I'm keen to know what is the answer to the >>> general >>>>>> problem of modular fat or shaded jars. >>>>>> >>>>>> I know this doesn't remotely satisfy all your requirements, but are >>> you >>>>>> aware you can jpackage an app *without* bundling a JRE? >>>>>> >>>>>>> Am 06.10.2021 um 19:25 schrieb Glavo <zjx001...@gmail.com>: >>>>>>> >>>>>>> For a long time, unpacking and repackaging all dependencies into a >>>> file >>>>>>> called fatJar was the first choice for single file distribution of >>> Java >>>>>>> programs. However, the compatibility of this solution with JPMS is >>> very >>>>>>> poor - it breaks up all the modules and works with classpath. >>>>>>> >>>>>>> I think many programmers may expect JDK to provide a native >>> lightweight >>>>>>> solution that bundles multiple modules into a single file. From >>> users' >>>>>>> enthusiasm for fatjar, we can see that they have a keen demand for >>> such >>>>>>> a format. jlink and jpackage cannot solve the problem that fatjar >>> wants >>>>>>> to solve. We now have the jimage file format, but it seems that it >>> is >>>>>>> only the internal format of JDK and is only used in the modules >>> file. >>>>>>> >>>>>>> The lack of such a solution has caused us some trouble about >>> whether to >>>>>>> modularize. So I earnestly request JDK to add support for such a >>> file >>>>>>> format: >>>>>>> >>>>>>> 1. It can bundle multiple modules in one file (It may be based on >>>> jimage >>>>>>> or other compression/archive format). >>>>>>> >>>>>>> 2. It should only bundle application dependencies without carrying >>>> JDK >>>>>>> standard library or even complete JRE. >>>>>>> >>>>>>> 3. It should have a manifest file like the MANIFEST.MF for jar, >>>>>>> allows we to add descriptions of entry points, Add-Opens, module >>>> path, >>>>>>> and so on. >>>>>>> >>>>>>> 4. Allows simple execution, such as `java -jimage foo.jimage`. In >>>>>>> this case, use the contents described in the above manifest file. >>>>>>> >>>>>>> 5. Associate this file format during JDK/JRE installation, and >>>>>>> execute it in the above manner when double clicking it. >>>>>>> >>>>>>> 6. Like the ZIP (JAR) format, allow other content to be appended >>>>>>> before its content. This makes it easy to attach a launcher >>> (usually >>>>>>> exe or bash) before its content. >>>> >>>> >>> >>
