jpackage: support for environment variables in --java-options

Andy Herrick andy.herrick at oracle.com
Tue Sep 1 18:18:41 UTC 2020


On 9/1/2020 11:54 AM, Michael Hall wrote:
>
>> On Sep 1, 2020, at 10:30 AM, Andy Herrick <andy.herrick at 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




More information about the core-libs-dev mailing list