InacessibleObjectException under JDK 16

[BadSkater0729]

I've already filed an issue report under the watson developer cloud SDK, but it seems like the issue has to do with the actual core SDK.

See more details below:
watson-developer-cloud/java-sdk#1171

[Andras-Csanyi]

@3xpl0itz Thanks for contacting us! Let me take a look at it and get back to you in a few days.

[Andras-Csanyi]

@3xpl0itz Sorry for the late answer. Based on the error message it is related to gson, the they have a similar issue: google/gson#1875
Let's wait until they fix it - they say there is an unmerged fix - and give it a try. I leave this ticket open until then.

[BadSkater0729]

Sounds good! Appreciate you looking into it.

[padamstx]

The java core was just updated to pull in the latest version of gson (2.8.9) to address a security vulnerability.
Perhaps this new version of gson also fixes the Java 16 issue as well.
The new version of the java core is 9.13.4

[BadSkater0729]

Hi, just checked; still getting the same "module java.base does not "opens java.lang" to unnamed module."

[ricellis]

FWIW Java 16 changed default behaviour for these cases from warn to deny; it is possible to workaround in Java 16 by reverting to the old behaviour with the option --illegal-access=warn.

In Java 17 the --illegal-access option is removed, but it is possible to workaround by breaking encapsulation e.g.
--add-exports java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED

As it says in the JEP 261 that I linked to; breaking encapsulation should be used with care and an understanding of the risks. However, until the ecosystem catches up with the module changes it can provide a workaround to these problems.

See also IBM/cloudant-java-sdk#114 (comment)

[BadSkater0729]

Yes, @ricellis's approach is a good workaround for now.