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. >> > >> > >> >
