Java 16 issue illegal access

[nithril]

Hello,

Please note it appears that jena-sparql-api is not compatible with java 16.

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make java.lang.invoke.MethodHandles$Lookup(java.lang.Class) accessible: module java.base does not "opens java.lang.invoke" to unnamed module @7494e528
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:188)
	at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:181)
	at org.aksw.jena_sparql_api.mapper.proxy.MapperProxyUtils.proxyDefaultMethod(MapperProxyUtils.java:2048)
	at org.aksw.jena_sparql_api.mapper.proxy.MapperProxyUtils.createProxyFactory(MapperProxyUtils.java:1401)
	... 133 more

Have you planned to make it compatible?

[Aklakan]

Hi, thanks for the report.

As a quick fix, adding the following --add-opens JVM options should mitigate the issue with the reflective access:

java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED [-cp/-jar...]

I need to investigate whether it is possible to devise a solution for Java 16+ that makes the proxy mapper system work out-of-the-box.

The background is, that the core module provides (besides other things) the RDFConnectionEx interface which extends Jena's RDFConnection interface with a getMetaData method akin to JDBC's connection class. Because we are in the RDF world, that metadata is just a resource in an RDF model. However, a default Java view with certain essential attributes is provided with RDFConnectionMetadata - and this view is generated by the proxy system. Of course, custom views can be obtained using connEx.getMetaData().as(CustomView.class). So because the proxy system already simplifies such fundamental tasks and also makes things more flexible I wouldn't want to separate this feature out.

Note for myself: This stack overflow post may contain helpful information.

[Aklakan]

Turns out that one of the answers of the stack overflow post pointed to class in the spring framework which so far solved at least the MethodHandles issue; it seems that dynamic collection getters (<T> Collection<T> getFoo(Class<T> clz)) yet trigger another illigal access exception with cglib.

[nithril]

Hello,

Can I do smth to help you? Maybe can you point out what should be updated and give some hint on how :)

With Java 17, the "add-opens" option does not exist anymore.

[Aklakan]

Hi, I am about to complete a quite big restructuring and some refactoring of this project in order to improve modularity and disentangle certain awkward dependencies; I'll come back to this issue once this is complete which should be during next week.

[Aklakan]

Time passes on so quickly ... in any case I finally managed to migrate from cglib to bytebuddy and the first couple of my apps that used to show illegal access warnings no longer show them; its currently in the refactored code based and still needs to be pushed to this repo though :/

[nithril]

Great news and job! 👍

[KonradHoeffner]

@Aklakan: I would be very happy to see the new version, I tried to fix some errors in LIMES and this is a problem when running it under Java 16.

[Aklakan]

the refactoring of jena-sparq-api "jenax" (simply for jena extensions) 4.4.0-1 is available on mvn central https://mvnrepository.com/artifact/org.aksw.jenax

i hope it doesn't take that long anymore to merge the code back into this repo :)

[nithril]

Thank you very much 👍