Not issue, need a hint to make this work. (please)

[chjan]

I am a little stuck and hope it ok to ask here.

What I have working: For a java applicaton, a build.gradle that generates a shadowjar, based on which the launch4j gradle plugin generates an exe, which is finally used to create a win installer using NSIS. Has been working for years, the jar on WIN, LIN and MAC.

WHAT I WANT: To include a minimized JRE with the shadowjar (or a something else) so that the user can avoid installing java JDK on their machine. On the targetplatform WIN, I want to use that result to create an exe, not a bat, so I assume that "some" resulting jar can be used as input for the launch4j plugin. However, I accept other outcomes.

FIRST STEP is just to create the JRE image for the app. I am working on a mac and i grasp the targetplatform feature. So lets say I will just try to create a JRE for the mac platform.

MY CONFUSION: I have tried (and tried) to grasp the concept of modular or non-modular projects, but still confused. Question: Is a shadowjar per definition bringing the project to non-modular state, even if it is based on 3. party libraries (approx 20, divided on jars in a /lib folder and maven dependencies)? Or could it still be modular?

I have tried both badass plugins. There is some response when I use the runtime version, but no JRE is generated, allthough a build/distributions folder is, but its files are similar in size to the app itself = approx 10Mb, so no JRE there.

PLEASE WITH A TEASPOON, what do I add to this code in order to scrupulously create the minimized JRE/JDK image, and where will it be after it is created. I hope it will be a part of the shadowjar, but I accept other outcomes.

`...
runtime {
options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages']
}

shadowJar { etc...`

[TheRedSpy15]

This plugin is for non modular projects, Not sure why you are doing anything in regards to a shadowJar

[hakanai]

Shadow jars in general are trouble, I've never had a situation where I tried to shadow some other jar and not had some issue with it.

Last two that freshly come to mind:

1. Someone had hardcoded names of their classes inside their source files in a non-standard fashion
2. Someone had a boobytrap set inside the JDK itself that repackaging their jar caused it not to be considered secure

But even so.

You'd think this would be a matter of correctly configuring your runtime classpath?