Alternative to fatJar - modular solution?

Ioi Lam ioi.lam at
Thu Oct 14 00:57:53 UTC 2021

Hi Glavo,

I have simplified my prototype so now there's no need to implement new 
URL handlers.

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:


All the modules are loaded from the /modules directories in the JAR file.

The URI for a class looks like this:


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
     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 :-)

- 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:/!/BAR) nor
> converted into a URL ( Nested JAR URLs
> are not supported). Is this a bug or an expected behavior?
> Alan Bateman <Alan.Bateman at> 于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

More information about the jdk-dev mailing list