Re: Alternative to fatJar - modular solution?

[Ioi Lam]

Removing the jdk-...@openjdk.java.net mailing list.

This topic should be discussed on jigsaw-dev@openjdk.java.net only.

Thanks
- Ioi


On 10/14/21 9:06 AM, Ioi Lam wrote:

On 10/14/21 8:29 AM, Glavo wrote:

    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.

Since we are discussing about a solution for storing modules in a single file, there's an API to list all the contents of a module -- java.lang.module.ModuleReader::list().

Here's an example:

   import java.lang.module.*;

   public class FindAllInModule {
        public static void main(String args[]) throws Exception {
            Module module = java.lang.Object.class.getModule();
            ModuleReference mref = module.getLayer().configuration()
                    .findModule(module.getName())
                    .orElseThrow(() -> new RuntimeException())
                    .reference();
            try (ModuleReader reader = mref.open()) {
                 reader.list().forEach(n -> System.out.println(n));
            }
        }
   }

There's no requirements that a module must be stored in a JAR file. In fact, your program will not work if it was packaged into an image produced by jlink. That's why we have the ModuleReader::list() API.

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.

Could you explain what the actual scenario is? Is it for patching the contents of a module (similar to --patch-module)?

Thanks
- Ioi

Ioi Lam <ioi....@oracle.com <mailto:ioi....@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
<https://urldefense.com/v3/__https://github.com/iklam/tools/tree/main/jigsaw/uberjar__;!!ACWV5N9M2RV99hQ!e5b75N_Cpd4IjSBjjO1rN9cnWFTiv-dPnb8qKrG9xrFoL9LH9NDBuNVoO-O7nQ$>

    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
<https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!e5b75N_Cpd4IjSBjjO1rN9cnWFTiv-dPnb8qKrG9xrFoL9LH9NDBuNXMJHaheg$>.MalformedURLException:
    Nested JAR URLs
    > are not supported). Is this a bug or an expected behavior?
    >
    > Alan Bateman <alan.bate...@oracle.com

    <mailto:alan.bate...@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
    >>