A new JPMS-friendly Java program packaging format

Glavo zjx001202 at gmail.com
Thu Dec 7 08:10:11 UTC 2023


> Please provide a way to exclude files or packages from a particular Jar.
For example, I may not want Multimap.class in the Guava Jar.

This feature is very useful. I'll put this on my TODO list.

> Is this compatible with Proguard's and Graal VM's to trim fat Jars?  Both
of these will eliminate unused classes, methods, and fields to reduce the
size of the fat Jar.

I have some interest in Proguard and will look into it at a later date.

As for GraalVM, I have no plans to support it yet. I think japp and
native-image are parallel.
If users need it, they should probably build native-image directly through
the build script instead of creating a japp file first and then build
native-image based on the japp file.
Moreover, I don’t seem to be able to provide support for native-image in a
non-intrusive way, I can only modify the source code of GraalVM itself.
Therefore, I won't consider it for now.

Glavo


On Thu, Dec 7, 2023 at 7:29 AM Nathan Reynolds <numeralnathan at gmail.com>
wrote:

> Please provide a way to exclude files or packages from a particular Jar.
> For example, I may not want Multimap.class in the Guava Jar.
>
> Is this compatible with Proguard's and Graal VM's to trim fat Jars?  Both
> of these will eliminate unused classes, methods, and fields to reduce the
> size of the fat Jar.
>
> On Wed, Dec 6, 2023 at 3:17 PM Glavo <zjx001202 at gmail.com> wrote:
>
>> Hey everyone,
>>
>> Recently, I have been busy developing a new JPMS-friendly Java program
>> packaging format: JApp (https://github.com/Glavo/japp).
>>
>> JApp is intended as a better alternative to shadow jar (fat jar).
>> Users need to specify the module path and classpath when creating a JApp
>> file.
>> Resources in all module path/classpath entries (JAR or directory) are
>> packaged into a single japp file,
>> but unlike shadow jars, japp isolates resources from different module
>> path/classpath entries.
>>
>> For example, we can create a japp file with the following command:
>>
>>     japp create -o myapp.japp \
>> --module-path commons-lang3-3.14.0.jar:commons-io-2.15.1.jar \
>>         --classpath guava-32.1.3-jre.jar:gson-2.10.1.jar
>>
>>
>> This will create a japp file named `myjapp.japp` that contains resources
>> from four jar files.
>> At runtime, the URIs for the resources from the four JAR files each look
>> like this:
>>
>>
>> japp:/modules/org.apache.commons.lang3/org/apache/commons/lang3/ObjectUtils.class
>> japp:/modules/org.apache.commons.io/org/apache/commons/io/IOUtils.class
>>
>> japp:/classpath/guava-32.1.3-jre.jar/com/google/common/collect/Multimap.class
>> japp:/classpath/gson-2.10.1.jar/com/google/gson/Gson.class
>> At runtime, each entry in the module path and classpath is independent,
>> just like passing the `--classpath`/`--module-path` option directly to
>> the `java` command.
>>
>> By sharing the class constant pool, using zstd as the compression method,
>> and
>> compressing the file metadata, japp files are generally smaller than
>> shadow jars.
>>
>> JApp files also support specifying some conditions, such as requirements
>> for the Java version.
>> JApp selects the Java runtime to use to run the program based on these
>> conditions.
>>
>> Here is its GitHub repository, for more features and detailed
>> instructions please refer to the README:
>>
>>     https://github.com/Glavo/japp
>>
>> Now that the basic features of JApp are complete, I'm sharing it here in
>> the hope
>> that more people will try it and give feedback.
>>
>> Thank you to everyone who is willing to read this email!
>>
>> Glavo
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20231207/6412d045/attachment-0001.htm>


More information about the jdk-dev mailing list