On 9/1/2020 11:54 AM, Michael Hall wrote:
On Sep 1, 2020, at 10:30 AM, Andy Herrick <andy.herr...@oracle.com> wrote:
I have been following this discussion , and feel it is worth pursuing.
Currently , the values of --arguments and --java-options are pre-processed at
launch time by expanding the values of $APPDIR, $ROOTDIR, and $BINDIR to values
determined by the native launchers.
If we can do so without breaking existing functionality we should also expand
environment variables to their values at launch time.
example: "--java-options \$USER_JAVA_OPTIONS", "--java-options -Dfoo=\$USER_BAR_VALUE",
"--arguments \$USER_MYAPP_ARGS"
Developer would have to make sure that the resulting java options or app
arguments make sense both with and without the corresponding environment
variable set. jpackage could make sure that an empty option or argument did
not cause a problem (as in first and third example above when there is no
corresponding env setting).
Actually I think about Serban’s original idea. Which seems would be workable in
a lot of cases. Unless you actually need it to be an environment variable.
I think Serban's original request was just this, to allow arbitrary
environment variables:
Is there a way to pass values from environment variables when using
--java-options?
It would be nice to be able to write something like this:
--java-options "-DmyAppData=$HOME/.myData"
(Instead of using the $ sign, another notation may be more appropriate, in
order to not conflict with macros such as $APPDIR or $ROOTDIR.)
Although I don't think there is a problem conflicting with the existing
macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more
exclusive that "$XXXX" since dollar sign may be a legitimate character
in an existing argument or vm option ("-DPRICE=$10.50") or
("-DCURRENCY_TAG=$")
anyway, wouldn't this go a long way to alleviating the concerns of
JDK-8250950 <https://bugs.openjdk.java.net/browse/JDK-8250950> ?
/Andy
