Warning: Illegal access operation for Java 10

[srijancerner]

Although deepClone is working fine for me in Java#10 but I am getting the warning messages:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.rits.cloning.Cloner (file:/D:/eclipse_neon/workspace/CloneTest/cloning-1.9.9.jar) to field java.util.TreeSet.m
WARNING: Please consider reporting this to the maintainers of com.rits.cloning.Cloner
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Is there any plan work on it ? As there is a possibility of these operations will actually be denied in near future.

[kostaskougios]

cloning is heavily based on reflection and reflective access of private fields. I suppose if newer Java versions blocks that, then the library will be unusable. My guess is that there should be a way to override it in future versions of Java but we can't be sure at the moment.

[bergmannm]

Actually, the Java#10 warning could be avoided for most use cases. It's caused by Cloner.registerKnownConstants() method, which scans static fields of a few java.util classes (Maps&Sets) . But this rarely needed, because they are usually cloned by FastCloner . Only when cloning class, which inherits from one of TreeSet, HashSet, HashMap, TreeMap, static fields need to be scanned.

[albertcheng]

@kostaskougios what shall we do though? downgrade java to java 7 ?

[bergmannm]

Downgrade to java 7 won't resolve the issue, because new Java versions are here to stay.

I suppose there is only one way to really fix it - don't use reflection on java internal classes, because it's going to stop working with future java versions anyway. Since Oracle is releasing new Java versions quite rapidly, it may happen pretty soon.

For backward compatibility

• registerKnownConstants could be called on demand when really needed.
• or there could be Cloner configuration option for that.

[tweimer]

@kostaskougios and those it may concern:

In java 16, the default mode will be --illegal-access=deny instead of --illegal-access=permit. See JEP 396.

So, you have to explicitely use permit in combination with this cloner, to have access to private fields, if the module isn't open for reflection.

[Petkomat]

In Java 17, this solution is not a solution anymore: Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0.

I got the error Unable to make field private transient java.util.Hashtable$Entry[] java.util.Hashtable.table accessible: module java.base does not "opens java.util" to unnamed module @482f8f11

and --add-opens=java.base/java.util=ALL-UNNAMED resolved the issue.

However, this seems like a dirty hack and maybe, it would be better to change the cloner itself if possible.

[albertcheng]

it is pointless, if they do not want others to use reflection why did they design this feature first place?

[robertvazan]

@albertcheng Since Java 9, every module decides for itself whether it wants to open its classes for reflection. The correct solution is to turn every library into a module and "open" (in module-info.java) those libraries where reflection makes sense. For java.base, this library should have dedicated fast cloner for every class that needs it.