Bug ID: JDK-8264261 Allow class path specification in java-options

Type: Enhancement
Component: tools
Sub-Component: jpackage
Affected Version: 16

Priority: P4
Status: Closed
Resolution: Won't Fix
OS: os_x
CPU: x86_64

Submitted: 2021-03-26
Updated: 2021-04-08
Resolved: 2021-04-08

Original Synopsis:
[macos]: Include the application directory $APPDIR in class path

ADDITIONAL SYSTEM INFORMATION :
Mac OS 10.15.7 Catalina
Java 16

A DESCRIPTION OF THE PROBLEM :
Previously the appbundler tool that was available related to the macport project had a Java/Classes directory that was included in java.class.path. I had various non-class resources added that I loaded off of class path. When jpackage didn't have such a directory entry in class path I jar'ed them instead. Being able to access these resources would be one use for this.
Another reason would be if there was actually a need for exploded classes as in the following bug report.
https://bugs.openjdk.java.net/browse/JDK-8263940
This concerns nio DefaultFileSystemProvider not working with jars, not modular, in class path. A workaround is to have the classes exploded. 
There might be other situations where 'app' or perhaps some directory in 'app' could be useful to have in class path.

Updated Synopsis
Allow class path specification in java-options:

Currently, specifying "-cp", "-classpath", or "-Djava.class.path=..." in the value of "--java-options" argument to jpackage would likely cause the application to not run, since the classpath generated by jpackage tool would be overridden by the classpath in the value of the --java-options option.
The proposed change is to append the classpath given by --java-options to the classpath generated by jpackage.
An app wanting to access files from either the input dir or a sub-directory of it) as resources could just include "--java-options='-cp \$APPDIR'" or "--java-options='-cp \$APPDIR/<subdir>'"

Consensus seems to be to leave existing behavior alone. If non-default class path is required, specify the whole required class-path in --java-options option.
08-04-2021
The desired effect can be achieved by adding a --java-options option to the jpackage command as follows: (1) --java-options -Djava.class.path="\$APPDIR" except the native code for a class-path app will be adding a class-path option by default, pointing to the apps, jars. The jli invocation will then have two -Djava.class.path arguments, and the second one will rule (the one given by the --java-options option) and the app will not find it's main class. This can be fixed (in example below of app with one jar: hello.jar) by the following (now assuming the resources desired to be added are in <input-dir>/resources): (2) --java-options -Djava.class.path="\$APPDIR/resources:\$APPDIR/hello.jar" So it appears to me, that if we want to enable (1) above, we should consider combining the automatic class path jli argument (generated by the various app.classpath entries in the applications cfg file, and any explicit class-path generated by a "--java-options="\$APPDIR/..." Meanwhile (2) above is a usable workaround for this need.,
29-03-2021
Although this would be easy to implement, I am not sure it is advisable. It may be beter to continue to require all application resources be contained in modules or jars. We shall continue to discuss this. As submitter indicates, you can just jar up the resources to have them included on the class-path. A bug in another component is not a reason for jpackge to implement a feature to get around it.
26-03-2021
RFE to include the application directory $APPDIR in class path. The bug may be related to https://bugs.openjdk.java.net/browse/JDK-8263940
26-03-2021