com.google.gson.internal.reflect.UnsafeReflectionAccessor illegal reflective access operation on jdk12 #1540
Comments
|
+1 for this issue, JDK 12 and Gson v2.8.5 attempts illegal reflective access. Here's the stack trace of the error in case that helps: |
|
I got the same using Spring & MongoDB java.lang.reflect.InaccessibleObjectException: Unable to make jdk.internal.ref.PhantomCleanable() accessible: module java.base does not "opens jdk.internal.ref" to unnamed module @20ea98f |
|
also happened on JDK 13 |
|
any activity on this? it seems now that gson will stop to work at all on JDK 14 because of this - IMHO this should have some priority? I'm not sure if gson is still actively develop though.. maybe we all need to switch, maybe to https://github.com/square/moshi ? |
|
Is there any update on this? Seems to be a serious issue. |
|
Hi @Marcono1234 any thoughts about this issue? It seems this started happening in Java 12, this did not happen for me in Java 11 but it is happening for me in Java 14. |
|
It looks like this might be the same issue as #1216 which was fixed by #1218. So if Though since this issue only occurs when Gson accesses types of another module, in the stack traces provided even JDK modules, it would be good to consider writing your own TypeAdapter / TypeAdapterFactory and then creating a Gson using a GsonBuilder on which you register that adapter, or use the |
|
Well, as far as I know, I did workaround this issue by adding |
What exactly are you referring to? Getting
I am not that familiar with Netty, but I think it is a completely different use case. Gson has to perform reflective access on arbitrary types (whatever you want to deserialize), while Netty probably only used it to access implementation details of specific JDK classes. So there was probably a clean way to solve this for Netty. It appears #1218 which was supposed to suppress the warnings is not working in newer JDK versions because you cannot access any fields declared in However, as expressed in the comments of #1216, you should take these warnings seriously. If the illegal reflective access occurs for a type of a third party library or even a JDK class, then you are relying on implementation details (which could change at any point!) of that library and should really consider writing a custom type adapter (see comment above). |
No, sorry, no general-case alternatives for latest JDKs. However, we potentially could support a custom user-provided |
|
The reason why the previous workaround broke in Java 12 is because the field which was misused to suppress the warnings was purposely hidden by the JDK (see JDK-8210522). For the cases described in comments of this issue, neither the caller has access (because they are JDK types) and Gson should in my opinion really not try to suppress the warnings. If the type is under the control of the user, they could add an |
|
I'm afraid I'm not super experienced with specifics of modules which definitely makes utilising the newer versions of Java a bit harder. Just to confirm my understanding, is adding |
|
Adding |
This exclusion strategy makes sure to skip serialization of any classes implementing the WebDriver interface. Since this object is redundant when reporting command parameters and doesn’t pass serialization - we exclude it. See google/gson#1540 for more details on the serialization problem. (edited) Signed-off-by: Gil Eliyahu <gil.eliyahu@testproject.io>
Revert google#1218 Usage of sun.misc.Unsafe to change internal AccessibleObject.override field to suppress JPMS warnings goes against the intentions of the JPMS and does not work anymore in newer versions, see google#1540. Therefore remove it and instead create a descriptive exception when making a member accessible fails. If necessary users can also still use `java` command line flags to open external modules.
…tor (#1902) * Remove UnsafeReflectionAccessor Revert #1218 Usage of sun.misc.Unsafe to change internal AccessibleObject.override field to suppress JPMS warnings goes against the intentions of the JPMS and does not work anymore in newer versions, see #1540. Therefore remove it and instead create a descriptive exception when making a member accessible fails. If necessary users can also still use `java` command line flags to open external modules. * Fix failing to serialize Collection or Map with inaccessible constructor Also remove tests which rely on Java implementation details. * Don't keep reference to access exception of ConstructorConstructor This also avoids a confusing stack trace, since the previously caught exception might have had a complete unrelated stack trace. * Remove Maven toolchain requirement * Address review feedback * Add back test for Security Manager
…tor (google#1902) * Remove UnsafeReflectionAccessor Revert google#1218 Usage of sun.misc.Unsafe to change internal AccessibleObject.override field to suppress JPMS warnings goes against the intentions of the JPMS and does not work anymore in newer versions, see google#1540. Therefore remove it and instead create a descriptive exception when making a member accessible fails. If necessary users can also still use `java` command line flags to open external modules. * Fix failing to serialize Collection or Map with inaccessible constructor Also remove tests which rely on Java implementation details. * Don't keep reference to access exception of ConstructorConstructor This also avoids a confusing stack trace, since the previously caught exception might have had a complete unrelated stack trace. * Remove Maven toolchain requirement * Address review feedback * Add back test for Security Manager
|
I assume this can be closed; there is nothing Gson can do (or should do) to work around access restrictions imposed by the module system. You should only rely on reflection-based serialization and deserialization for classes you wrote, or which were explicitly opened for reflective access. For all other cases you probably have to write a custom The next Gson release will probably also support specifying a "reflection access filter" (#1905) which can help on older Java versions to detect such (unintentional) reflective access on third party classes. |
Hi,
Since upgrading to JDK 12 (Gson v2.8.5), we keep getting warning messages like the following when doing JSON-serialization using Gson:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.gson.internal.reflect.UnsafeReflectionAccessor (file:/C:/UA/wss-unified-agent-19.5.1.1.jar) to field java.util.concurrent.atomic.AtomicReference.value
WARNING: Please consider reporting this to the maintainers of com.google.gson.internal.reflect.UnsafeReflectionAccessor
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
It doesn't happen on JDK 8 or JDK 11 it only happens on JDK 12
Thanks :)
The text was updated successfully, but these errors were encountered: