Hi, Ioi,
Thanks for the update! This is starting to look interesting indeed.
Now, the main problem I personally have with the JDK is that it provides
no way to manage native libraries packaged in JAR files. It provides
some limited support for modules packaged in JMOD files, but nothing for
modules packaged in JAR files. Would you have any recommendations for
that use case as well?
As for contributions from the community, well, I feel that Oracle should
really consider turning OpenJDK into an independent foundation. Right
now, OpenJDK is 100% managed by Oracle, which has a very bad reputation
among the community. Suing other corporations just for their money isn't
a great way to build a community, especially given that the "limited
resources" in this case isn't money, but people. Please try to make your
bosses understand that it would be wiser to leave the money where it's
needed. :)
Samuel
On 10/14/21 09:57, Ioi Lam wrote:
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.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
