Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undeclared module dependency for Java 9 #1695

Closed
boganiLuca opened this issue May 19, 2020 · 2 comments · Fixed by #1993
Closed

Undeclared module dependency for Java 9 #1695

boganiLuca opened this issue May 19, 2020 · 2 comments · Fixed by #1993

Comments

@boganiLuca
Copy link

boganiLuca commented May 19, 2020

Hello, I was using GSON 2.8.6 to save some data received from a device over a TCP connection, using simply
Gson gson = new Gson() return gson.toJson(this);
to serialize my custom class (and then save it into a text file), and
gson.fromJson(input, Analysis.class);
to de-serialize the saved file, so no special configuration or custom serialization involved.
The issue appeared when I built a custom JRE9 using jdeps and jlink and ran my program using that JRE9: when deserializing, I got the exception
Caused by: java.lang.UnsupportedOperationException: Cannot allocate class LocalDateTime at com.google.gson.internal.UnsafeAllocator$4.newInstance(UnsafeAllocator.java:104) at com.google.gson.internal.ConstructorConstructor$14.construct(ConstructorConstructor.java:225) ... 88 common frames omitted
I implemented a custom de-serializer for the classes that caused the exception (just two, LocalDateTime and a custom class), and the issue was solved, but, as was pointed out here , seems that there's an undeclared dependence on the module 'jdk.unsupported' that throws this exception.
Probably it's not a major issue, but I thought you'd like to know. Let me know if you need more code or details

@Marcono1234
Copy link
Collaborator

Marcono1234 commented May 19, 2020

As pointed out in Nicolai's answer on StackOverflow, Gson should declare a dependency on the jdk.unsupported module which contains Unsafe. However, he suggests an optional dependency (requires static).

The question is whether a regular dependency should be used since Gson's functionality is apparently limited without Unsafe. The jdk.unsupported module seems to be pretty small, so the module size should not be a problem.

Edit: Though apparently not everyone wants to use or can use Unsafe, see #445.
Edit 2: Nicolai's answer:

This should be discussed on the GSON issue. Short answer: The presence of jdk.unsupported should not be relied upon (notice its name) and since GSON works without it (just not as comfortable), avoiding a strict dependency would be a good choice IMO.

@Marcono1234
Copy link
Collaborator

@inder123, what are your thoughts? Should Gson only declare an optional dependency on jdk.unsupported and then mention in the README / user guide that users should add the module jdk.unsupported at runtime if they want support for Unsafe-based initialization? This would then also allow fixing #445 at a later point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants