Support Repackaging of Pre-Existing Nested Jar Files/Disable Modifying Input Jar

[ghost]

I currently have a pre-packaged executable JAR file (from java -jar) that I am passing into this plugin. I have specified skipCopyingDependencies = true, as the dependencies are already packaged into the JAR file.

The problem is that this plugin repackages the existing jar as shown in this debug message: Updating jar file: ${FILE_SYSTEM_PATH}/application.jar. This message is provided when I set theupdateExistingJar = true property.

I solved this problem manually by taking the .app output from jfxNative, and replacing the modified JAR with the original JAR file that is passed to this plugin. The application worked as intended.

Is is possible to modify the input JAR without changing the ZIP compression of the library directory from a STORE type of compression OR disable modification of the input JAR?

Thanks for reading.

[FibreFoX]

The problem is that this plugin repackages the existing jar

The underlying javapackager just works on some extracted jar-file or some jar-file, it is by design that the jar-file is re-created, mostly because they (the creators of the javapackager) wanted to have control over the META-INF/MANIFEST.MF-entries.

As far as I understood your problem, you are saying that the jar-file isn't compressed anymore?

[ghost]

No, I mean that the nested library jars which are already included in the input jar-file are being compressed when it is re-created, which makes them not useable by the class loader it seems. I need them same mechanism used to originally store the library jars into the lib directory for my existing nested library jar-files.

I will give more detail. My input jar-file is made with the Spring Boot plugin, which essentially packages all library jars together with the application and avoid having to set the classpath in the META-INF/MANIFEST.MF . This is since it dynamically loads the application through a proxy main() method. This is why I am unable to replace the existing library directory, as it is rewriting the classpath in the manifest currently.

In case you were wondering, the exception I am receiving is from the Spring Boot dynamic loader (so it may not be as relevant here): java.lang.IllegalStateException: Unable to open nested entry 'BOOT-INF/lib/fxcharts.jar'. It has been compressed and nested jar files must be stored without compression. Basically what it saying is that the nested library jar-files need to not be compressed.

[FibreFoX]

Hm, seems this is a conflict with a Spring Boot then. Can you create a small project for me, where I can re-create this situation? Does not have to be productive code, just the bits and pieces which are required to get this Exception.

[FibreFoX]

I'm flagging this as It's the JDK as there is no option for deactivating the compression-level, but I might be able to re-re-create the jar-file, just with the compression being disabled.

But to be honest, I'm pretty interested in this project-type, never crossed my mind to combine Spring Boot with JavaFX launchers.

[ghost]

I attached the MVCE. It is an Intellij project on Java 8.

Steps to reproduce:

1. Refresh Gradle dependencies
2. Run ./gradlew jfxJar
3. Run cd build/jfx/app
4. Run `java -jar project-jfx.jar

library-compression-mvce.zip

You will notice that the main class is org.springframework.boot.loader.JarLauncher, which is the Spring Boot loader's proxy class for loading classes dynamically.

If you unzip the jar-file project-jfx.jar you can take a look at how it is doing so.

[FibreFoX]

Hi there,

yes I see the problem, and it is the JDK itself which does re-compress the jar-file (not the javafx-gradle-plugin).

As I'm reworking this plugin for Java 9 compatibility (and some interface changes), there is no quick solution for this problem. Even on current JDK 9 this bug is existing. Maybe you want to open a new issue at the official Java bugtracker from Oracle?

[ghost]

Alright, I'll try that. Do you have a link to their bugtracker? I can't find it on Google.

[FibreFoX]

Just start here: http://bugreport.java.com/ Please file the bug with the following configuration:

• Type: Bug
• Product/Category: JavaFX
• Subcategory: Packager

When you have some feedback from oracle, please report it back here, so others can find this (and I can check when it gets fixed, ...or getting closed as "won't fix").

Just refere to javapackager when reporting, but you can add this issue as some reference. The bug is that when repackaging an existing JAR, they do not take care of the packaging method (STORE or DEFLATE).

[ghost]

We will review your report and have assigned it an internal review ID : 9050654 . Depending upon the completeness of the report and our ability to reproduce the problem, either a new bug will be posted, or we will contact you for further information.

We recommend using the Early Access Release available on JDK 9 Early-Access Builds to check if the report you have submitted has been fixed in the Early Access Release.

We will try to process all newly posted bugs in a timely manner, but we make no promises about the amount of time in which a bug will be fixed. If you just reported a bug that could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support.

Thank you again for using this site.

It is an internal review, so I am not sure if it is publicly viewable.

[FibreFoX]

All reports will be converted into real JDK-issue-numbers, have done this several times :) they make it to separate unconfirmed bugs and real bugs, like a pre-filtering system. You will get the real JDK-number after they evaluated your issue.

[ghost]

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8187357

[FibreFoX]

Thanks for the update, will check the sources what they changed, and if I need to add some workaround for older versions.

For reference, the link to the openjdk-jira: https://bugs.openjdk.java.net/browse/JDK-8187357

Resolution: Incomplete

Will wait some days for re-checking this.

[FibreFoX]

@arminnaderi can you recheck this using current JDK 8?

This issue is reported with an older Java version 8u65. Checking it's status with current JDK version 8u144 as well as 9 ea build.

[FibreFoX]

After evaluation with JDK 10, this still is relevant, and still inside the JDK.

[sdorof1]

Hi there,

Is there a some perspective to resolve this issue?

[omtodkar]

Following workaround worked for me, I am using plugin only for building native package.

Build a jar using spring bootJar task. It is by default enabled, though just to make sure Gradle builds jar using spring bootJar task.

bootJar { enabled true }

Disable the jfxJar task. jfxJar { enabled false }

Provide bootJar output path to jfxAppOutputDir and also provide Spring boot JarLauncher as mainClass.

jfx {
    mainClass = 'org.springframework.boot.loader.JarLauncher'
    
    jfxAppOutputDir = "${buildDir.path}/libs"
}

Let me know if there are any side-effects, thanks.