Alternative to fatJar - modular solution?

[Glavo]

>
> In fact, I don't understand why people started packing JAR files inside
> JAR files. Maybe there were some esoteric reasons (related to
> Class-Path: attribute in manifest files???).
>

 Sometimes it's necessary to keep jars intact and distribute them as
they are. In fact, a program I just developed today is not compatible
with your solution: It uses
cls.getProtectionDomain().getCodeSource().getLocation()
find its place, create a zip file system and traverse some of its folders.
We also have some strange use cases that require additional data to be
appended before the jar content. Dismantling the jar will destroy the
data.

Ioi Lam <ioi.lam at oracle.com> 于2021年10月14日周四 上午8:57写道：

> Hi Glavo,
>
> I have simplified my prototype so now there's no need to implement new
> URL handlers.
>
>      https://github.com/iklam/tools/tree/main/jigsaw/uberjar
>
> Please see the "Super-JAR Demo" section.
>
> The new demo uses standard features supported by the JDK's built-in
> "jar:" URL handler. The only difference with my previous demo is that we
> store the "exploded" version of the modules. I.e., the JAR file looks
> like this:
>
>      modules/com.lib/com/lib/Lib.class
>      modules/com.lib/module-info.class
>      ...
>      modules/com.simple/com/simple/Simple.class
>      modules/com.simple/com/simple/Simple$Foo.class
>      modules/com.simple/module-info.class
>
> All the modules are loaded from the /modules directories in the JAR file.
>
> The URI for a class looks like this:
>
> jar:file:///tmp/apps/super-launcher.jar!/modules/com.lib/com/lib/Lib.class
>
> For modularized apps, I think this is a much better approach than the
> traditional Uber-JARs that store JAR files inside a JAR file, which will
> require more complex decompression.
>
> In fact, I don't understand why people started packing JAR files inside
> JAR files. Maybe there were some esoteric reasons (related to
> Class-Path: attribute in manifest files???).
>
> But, whatever reason they had would not apply to a modular application,
> where every component is already in a Jigsaw module. Packing the
> exploded image into a JAR file will be good enough.
>
> **********************
>
> Going forward, I would suggest --
>
> [1] Frameworks such as SpringBoot can consider the idea in this demo for
> a possible solution for packaging modules
>
> [2] For the JDK, we should investigate supporting a single-file
> packaging format for modules. E.g. extend the --module-path command-line
> option to support modules that are stored in a single file (either a JAR
> file or an image file produced by jlink).
>
>      java --module-path=super-jar.jar -m com.simple
> or
>      java --module-path=super-jar.jar -m com.simple
>
> Or even this (with appropriate attributes in the JAR manifest):
>
>     java -jar super-jar.jar
>
> I believe [2] is doable as the underpinning support is already in the
> JDK. We need to decide what format to support, how to specify the
> location of the modules directory inside a JAR file, etc.
>
> As always, since the Oracle Java team has limited resources,
> participation from the Java community is very much appreciated and
> encouraged :-)
>
> Thanks
> - Ioi
>
>
>
> On 10/11/21 3:48 PM, Glavo wrote:
> > I mistakenly believe that the implementation of the filesystem
> corresponds
> > exactly to the URL. The problem I really want to express is that JDK
> > does not support URLs of nested jar file systems. It seems that this
> > problem still exists in JDK 17. To make matters worse, we can use toUri()
> > to convert the path of the file in the nested jar into a URI, but this
> > URI is neither accepted by Paths.get (java.lang.IllegalArgumentException：
> > URI does not contain path info ex. jar:file:/c:/foo.zip!/BAR) nor
> > converted into a URL (java.net.MalformedURLException: Nested JAR URLs
> > are not supported). Is this a bug or an expected behavior?
> >
> > Alan Bateman <Alan.Bateman at oracle.com> 于2021年10月12日周二 上午2:58写道：
> >
> >> On 11/10/2021 15:09, Glavo wrote:
> >>> I think this is a great prototype. Based on it, I think such
> requirements
> >>> can also be realized by enhancing jar in these aspects:
> >>>
> >>>     1. Nested jar file system (The ujar file system seems unnecessary.
> >>>        I never understand why jar file systems cannot be nested.)
> >> This was fixed in JDK 12, are you seeing issues with release recent
> >> releases? If so then would it be possible to submit a bug with a test
> >> case or bring the issue to core-libs-dev?
> >>
> >> -Alan
> >>
>
>