BIRT 4.12 JDK 11 vs. JDK 17 - Solution of new module handling (javax, com.sun.net.*, etc.)

[speckyspooky]

Hello Together,
today I have a question which comes up with BIRT 4.12 JDK 11.
I created 2 demo-prototype reports:

1. report: parse String to XML
2. report: creates REST-request and fetch the RESP-response

The results with JDK 11 was perfect. The same reports with JDK 17 crash in both cases with error.
The reason is that some jars are removed since JDK 16 from java.base and the new java module-handling is active (ok, it exists since JDK 9).

Can someone give me some hints how I can solve the java-handling with JDK 17?
Java hasn't the information of JAXB and some com.sun.*-jars.

report 1 - error: XML-parser

report 2 - error: HTTP-request

report 1 - report file: XML-parser
xml_parser_javax.zip

report 2 - report file: HTTP-request
rest_post_request.zip

[hvbtup]

I don't have a solution, but this could be related to a similar issue I noticed with Java 17 (see #1138).

In my case, the exception was
java.lang.IllegalAccessException: class org.mozilla.javascript.MemberBox cannot access class sun.java2d.SunGraphics2D (in module java.desktop) because module java.desktop does not export sun.java2d to unnamed module

In fact the mentioned class still exists in the JDK, but it could not be accessed from Rhino due to the complexities of interfaces and abstract classes.

In my case, one possible workaround (which I didn't follow further because it failed a few code lines later) was to move the code that deals with this class directly into a custom JAR in such a way that it hides these classes from the (Rhino) caller.
This kind of solution might work in your case, too.

Another, temporary workaorund is to use and --add-exports JVM option.

Note that your case might be different.
I know that sun.java2d.SunGraphics2D still exists in the JDK.
I don't know if that is true for the sun.net.www.protocol.https.HttpsURLConnectionImpl class.

According to https://stackoverflow.com/questions/70129530/is-it-possible-to-run-wildfly-10-on-new-jdk17, a similar approach could work for jaxp by using the JVM option --add-opens java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED

[speckyspooky]

Yes, you are right. I created a small jar file with the according methods and the new "module-info.java" (on jar side) and I was able to use the according objects via report resource import on report side. WIth this way all specific report implementations which use extracted module libraries with Java 16 needs to be used this way of special jars or we can update rhino (our issue thread).