RFR: 8341641: Make %APPDATA% and %LOCALAPPDATA% env variables available in *.cfg files [v3]

Alexander Matveev almatvee at openjdk.org
Thu Mar 6 21:53:56 UTC 2025


On Thu, 6 Mar 2025 12:26:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TokenReplace.java line 112:
>> 
>>> 110:         regexps = new ArrayList<>();
>>> 111: 
>>> 112:         for(;;) {
>> 
>> Suggestion:
>> 
>>         for (;;) {
>
>> If you do echo on macOS in terminal for unset variable it will be expanded to empty string, so for "Unset variables are not expanded." should we have Welcome ! instead of Welcome $USER!?
> 
> This is true for any shell. It is also true that some shells fail to expand undefined variables if configured accordingly. Bash, for example:
> 
> bash -c 'FOO=10; echo FOO=$FOO; unset FOO; set -u; echo FOO=$FOO'
> 
> 
> output:
> 
> FOO=10
> bash: line 1: FOO: unbound variable
> 
> 
> .cfg file is not a script, and the jpackage app launcher is not a shell. The substitution performed is less of a variable expansion and more a token replacement, and a token is not replaced if it doesn't have a value.
> 
> Regardless of the handling of undefined variables, users have to deal with the case of undefined variables in .cfg files. Imagine they pass `--java-options -DmyAppData=$HOME/.myData` to jpackage and `HOME` happens to be undefined on the machine where the app runs. Is `/.myData` any better than `$HOME/.myData`?

Agree. Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23923#discussion_r1984101788


More information about the core-libs-dev mailing list