Java 17 fix doesn't work correctly on Windows

[lrbarber]

daffodil-debugger.bat, created from bat-template does not correctly parse the extra args required for java 17 and above.

['-J--add-opens', '-Jjava.base/java.lang=ALL-UNNAMED']

The second parameter is being terminated at the period after the first "java"
Thus, the issued java command is malformed:

"java" --add-opens java -cp ""C:\...\daffodil-vscode\daffodil-debugger-3.5.0-1.3.1\bin\..\lib\org.apache.daffodil.daffodil-debugger-1.3.1-classpath.jar"" org.apache.daffodil.debugger.dap.DAPodil --listenPort 4711 .base/java.lang ALL-UNNAMED

[shanedell]

This is a blocking issue for PR #894 and Issue #772. Two of the failing CI items are caused by issue reported by @lrbarber . See the links provided below for sample output of the error:

• https://github.com/apache/daffodil-vscode/actions/runs/6790305997/job/18506868152
• https://github.com/apache/daffodil-vscode/actions/runs/6790305997/job/18506868288

Both use windows-2019 as the runner OS and Java 17, the only difference between the two is the one uses NodeJS 16 and the other uses NodeJS 18.

[lrbarber]

utils.js contains this block of code that eventually is used by batch (or bash) script to construct a command line invoking java program...

const extraArgs = isAtLeastJdk17
    ? ['-J--add-opens', '-Jjava.base/java.lang=ALL-UNNAMED']
    : [ ]

The batch file is invoked:

daffodil-vscode\daffodil-debugger-3.5.0-1.3.1\bin\daffodil-debugger.bat --listenPort 4711 -J"--add-opens java.base/java.lang=ALL-UNNAMED"

However, when the .bat file parses this, it breaks the second parameter into several pieces and produces the following command:

java   --add-opens java -cp ""C:\Users\larry.barber\Documents\daffodil-vscode\daffodil-debugger-3.5.0-1.3.1\bin\\\..\lib\\org.apache.daffodil.daffodil-debugger-1.3.1-classpath.jar"" org.apache.daffodil.debugger.dap.DAPodil  --listenPort 4711 .base/java.lang ALL-UNNAMED  

The two parameters actually are a single option setting and must be place together and with the '=' in place.
I tried changing the utils.ts file to use only a single entry -J--add-opens java.base/java.lang=ALL-UNNAMED which still didn't work correctly, but adding double quotes fixed it -J"--add-opens java.base/java.lang=ALL-UNNAMED"

and produced the following command:

java   --add-opens java.base/java.lang=ALL-UNNAMED  -cp ""C:\Users\larry.barber\Documents\daffodil-vscode\daffodil-debugger-3.5.0-1.3.1\bin\\\..\lib\\org.apache.daffodil.daffodil-debugger-1.3.1-classpath.jar"" org.apache.daffodil.debugger.dap.DAPodil  --listenPort 4711

Unfortunately, the double quotes are not eliminated by the bash file's parsing and the linux version of the command becomes:

java   "--add-opens java.base/java.lang=ALL-UNNAMED"  -cp ""C:\Users\larry.barber\Documents\daffodil-vscode\daffodil-debugger-3.5.0-1.3.1\bin\\\..\lib\\org.apache.daffodil.daffodil-debugger-1.3.1-classpath.jar"" org.apache.daffodil.debugger.dap.DAPodil  --listenPort 4711

Which, of course, java doesn't like.

After further experimentation with Hitesh, we discovered that there is a formatting of the text in utils.ts that works for both Windows & Linux -- it's just ugly!

const extraArgs = isAtLeastJdk17
    ? ['-J--add-opens', '-J"java.base/java.lang""=""ALL-UNNAMED"']
    : [ ]

Don't ask us how this works, but...
Windows parses it and produces this:

--add-opens java.base/java.lang"="ALL-UNNAMED

and Rocky9 this:

--add-opens java.base/java.lang=ALL-UNNAMED

Both of which actually seem to run.
The only alternative to this would be to add logic to the utils.ts file to contain different settings based upon the operating system with an if then...else clause.

  const extraArgs = isAtLeastJdk17
   ? [ osCheck('-J"--add-opens java.base/java.lang=ALL-UNNAMED"',     // Windows
               '-J--add-opens java.base/java.lang=ALL-UNNAMED')]      // Linux
   : [ ]

[shanedell]

@lrbarber So instead of doing:

const extraArgs = isAtLeastJdk17
    ? ['-J--add-opens', '-Jjava.base/java.lang=ALL-UNNAMED']
    : [ ]

if you did

const extraArgs = isAtLeastJdk17
    ? ['-J--add-opens java.base/java.lang=ALL-UNNAMED']
    : [ ]

does that work? If not I would ask why does windows option need surrounded by double quotes for

const extraArgs = isAtLeastJdk17
   ? [ osCheck('-J"--add-opens java.base/java.lang=ALL-UNNAMED"',     // Windows
               '-J--add-opens java.base/java.lang=ALL-UNNAMED')]      // Linux
   : [ ]

? If that is the only way it can be done that is fine just curious as the double quotes seem like they shouldn't be needed. Meaning instead of needing two different commands for the different OSes that we instead need to send these values as one big string instead of two separate ones like my snippet from before.

[lrbarber]

@shanedell The way the parameters are being parsed by Windows breaks the command in to 2 pieces at the space character. The initial implementation tried to get around this by encoding the 2 pieces separately but expecting that they would be placed together on the java command line. Unfortunately, this wasn't working due to the parser also breaking the parameter at the equals sign. The double quotes on the windows version forces the parser to take the entirety of the string as one parameter as intended. Linux parser doesn't eliminate these quotation marks, thus corrupting the java command line it's trying to build and forcing us to use separate implementations based upon the operating system.

[arosien]

I see this in the JDK docs:

The equals sign between --add-opens and its value is optional on the command line.

So let's try that!