CF2023 Java error

[donaldy1202780]

I am running CF2023 with JDK-21 using commandbox. I am getting the following error (see attached screenshot), which doesn't occur for me on prior versions of CF/Java. I added the following to my server.json which my understanding is this should be added by commandbox to the jvm.config file and I had assumed this would have stop the error, but it did not. Any advice/help would be appreciated:"jvm":{
        "minHeapSize":"${MINHEAP:1G}",
        "heapSize":"${MAXHEAP:2G}",
        "args":[
            "-Dcoldfusion.datemask.useDasdayofmonth=true",
            "-Dcoldfusion.xml.allowPathCharacters=true",
            "--add-opens=java.desktop/com.sun.awt=ALL-UNNAMED"
        ],
        "javaHome":"C:\\Program Files\\Java\\jdk-21"
    },

[donaldy1202780]

After realizing CF2023 still doesn't support JDK-21 I switched to JDK-17 and same issue. However switching to JDK-11 stopped the issue. What's more interesting is that running JDK-17 on a stand alone install of CF2023 this issue does not arise, it's only occurring on a commandbox instance of the server. Any advice would b emuch appreciated. Thanks!

[BKBK]

As a test (using JDK-17 and JDK-21), what happens when you leave out the flag 

"--add-opens=java.desktop/com.sun.awt=ALL-UNNAMED"

from the JVM?

[donaldy1202780]

It also fails, I only added that argument into the server.json file because the error was occurring and I was hopeful that argument would propogate at runtime and stop the error. Either way it fails in both JDK-17 and JDK-21 with or without the argument passed through to commandbox. Frankly I don't think the argument is being consumed and passed onto the server via commandbox at runtime because this populates on commandline at startup and it doesn't contain the line I added above Picked up JDK_JAVA_OPTIONS:

JDK-11, without the argument, works fine via commandbox running CF2023. It's just not really helpful because my qa and live environments are running JDK-17 in standalone CF without this issue, so I don't want to develop in my local on an older version of Java if I can avoid it.

[donaldy1202780]

FYI here is the full set of options that populate in commandline at server startup, with and without that argument passed nothing changes:

NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.base/sun.nio.cs=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.annotation=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.module=ALL-UNNAMED --add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.net.spi=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.nio.channels=ALL-UNNAMED --add-opens=java.base/java.nio.channels.spi=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.nio.charset.spi=ALL-UNNAMED --add-opens=java.base/java.nio.file=ALL-UNNAMED --add-opens=java.base/java.nio.file.attribute=ALL-UNNAMED --add-opens=java.base/java.nio.file.spi=ALL-UNNAMED --add-opens=java.base/java.security=ALL-UNNAMED --add-opens=java.base/java.security.cert=ALL-UNNAMED --add-opens=java.base/java.security.interfaces=ALL-UNNAMED --add-opens=java.base/java.security.spec=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.text.spi=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.time.chrono=ALL-UNNAMED --add-opens=java.base/java.time.format=ALL-UNNAMED --add-opens=java.base/java.time.temporal=ALL-UNNAMED --add-opens=java.base/java.time.zone=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED --add-opens=java.base/java.util.function=ALL-UNNAMED --add-opens=java.base/java.util.jar=ALL-UNNAMED --add-opens=java.base/java.util.regex=ALL-UNNAMED --add-opens=java.base/java.util.spi=ALL-UNNAMED --add-opens=java.base/java.util.stream=ALL-UNNAMED --add-opens=java.base/java.util.zip=ALL-UNNAMED --add-opens=java.base/javax.crypto=ALL-UNNAMED --add-opens=java.base/javax.crypto.interfaces=ALL-UNNAMED --add-opens=java.base/javax.crypto.spec=ALL-UNNAMED --add-opens=java.base/javax.net=ALL-UNNAMED --add-opens=java.base/javax.net.ssl=ALL-UNNAMED --add-opens=java.base/javax.security.auth=ALL-UNNAMED --add-opens=java.base/javax.security.auth.callback=ALL-UNNAMED --add-opens=java.base/javax.security.auth.login=ALL-UNNAMED --add-opens=java.base/javax.security.auth.spi=ALL-UNNAMED --add-opens=java.base/javax.security.auth.x500=ALL-UNNAMED --add-opens=java.base/javax.security.cert=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.nimbus=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.motif=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.nimbus=ALL-UNNAMED --add-opens=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-opens=java.desktop/sun.java2d=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-opens=java.base/sun.security.rsa=ALL-UNNAMED --add-opens=java.base/sun.security.pkcs=ALL-UNNAMED --add-opens=java.base/sun.security.x509=ALL-UNNAMED --add-opens=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.base/sun.util.cldr=ALL-UNNAMED --add-opens=java.base/sun.util=ALL-UNNAMED --add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-exports=java.desktop/sun.java2d=ALL-UNNAMED --add-exports=java.base/sun.util=ALL-UNNAMED

[BKBK · Accepted solution]

Are you by any chance mixing up 64-Bit with 32-Bit somewhere? If so, then that might explain it. Apparently, from Java 17 onwards, some 32-Bit clients fail. 

Suggestion: include the following flags in the JVM

--add-exports=java.base/sun.security.action=ALL-UNNAMED
--add-exports=java.desktop/com.apple.eawt=ALL-UNNAMED
--add-exports=java.desktop/com.sun.awt=ALL-UNNAMED
--add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.image=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.shell=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.windows=ALL-UNNAMED
--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.desktop/sun.print=ALL-UNNAMED
--add-exports=java.desktop/sun.swing.plaf.synth=ALL-UNNAMED
--add-exports=java.desktop/sun.swing.table=ALL-UNNAMED
--add-exports=java.desktop/sun.swing=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.desktop/java.awt.event=ALL-UNNAMED
--add-opens=java.desktop/java.awt=ALL-UNNAMED
--add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED
--add-opens=java.desktop/javax.swing.plaf.synth=ALL-UNNAMED
--add-opens=java.desktop/javax.swing.plaf=ALL-UNNAMED
--add-opens=java.desktop/javax.swing.tree=ALL-UNNAMED
--add-opens=java.desktop/javax.swing.tree=ALL-UNNAMED
--add-opens=java.desktop/javax.swing=ALL-UNNAMED
--add-opens=java.desktop/javax.swing=ALL-UNNAMED

Reference: https://forum.inductiveautomation.com/t/linux-java-17-opens-and-exports/83546/2 

[BKBK]

There's something else I am curious about.  Why did you use Java 21? Adobe recommends Java 17 for ColdFusion 2023.

[donaldy1202780 · Accepted solution]

The only reason I used JDK-21 is that what I was directed to do when I first installed it here by another developer and at the time I didn't think to question it. I do realize now it's not yet supported by adobe. I was able to get the issue resolved, apparently I wasn't using the proper string, when I add this to the args, it began working:

"--add-opens=java.desktop/sun.awt=ALL-UNNAMED"

[donaldy1202780]

One of the things that was odd was that when using the exact sytax ortus solutions documentation listed to add an argument to jvm args was that it added it improperly which caused more delay in me getting to the right answer:

box server set jvm.args=["--add-opens=java.desktop/sun.awt=ALL-UNNAMED"] --append

When I do that, it actually overrides the jvm.args and I get this as my args:

"args":"[--add-opens=java.desktop/sun.awt=ALL-UNNAMED]",

So this does not append, it actually overwrites it and on top of that it changes args from an array to a string with an array inside of it, which seemed odd to me. When I attempt box start, I get the following:

[ERROR] Error: Could not find or load main class [--add-opens=java.desktop.sun.awt=ALL-UNNAMED]
[ERROR] Caused by: java.lang.ClassNotFoundException: [--add-opens=java/desktop/sun/awt=ALL-UNNAMED]

If I subsequently change this back to an array with a string inside:
"args":[
"--add-opens=java.desktop/sun.awt=ALL-UNNAMED"
],
Everything worked... @BKBK thanks for taking the time to respond to my questions.