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

Make dependency on java.sql optional #1707

merged 6 commits into from Aug 25, 2021


Copy link

Note: This is based on #1656
Fixes #1629

Makes the dependency on the java.sql module optional. If its classes are present at runtime, the respective type adapters will be used, otherwise Gson will not try to load the classes and will therefore not fail with a ClassNotFoundException anymore. The entry point for all SQL type adapters is now SqlTypesSupport.

I am however, not that familiar with the module system so it would be good if others who are more familiar with it can check if this is a sane implementation.

Especially #1500 (@Degubi) is confusing me because from what I understood about the JPMS requires transitive is only so modules depending on Gson would also be "reading" java.sql, which however makes no sense because Gson does not expose these types publicly anywhere, so it should not provide them transitively. To my understanding requires should have been enough to require java.sql being present at runtime, however based on the ClassNotFoundException reports this was not the case?
Or are they using tools (as it is the case here which break the module system)? Though that would be a rather common issue then, see the question "java.sql.Time exception".

Also pinging @nicolaiparlog, if you have any spare time, any hints regarding the JPMS would be appreciated :)
Sorry to pester you in case you don't have any time.

Copy link

nipafx commented May 26, 2020

Don't worry, I don't pester easily. 😉 I'm happy to provide input, but keep in mind that I don't know GSON or the diff in detail (don't have the time to study them right now), so I may be off. Caveat emptor, I guess. Also, I wrote a blog post about optional dependencies that may help understand the feature.

As I understand the situation, GSON only needs to work with java.sql types if the user already uses them, right? I.e. there's never a situation where a GSON user doesn't need the java.sql module, but GSON uses its types anyway. If that is so, requires static is the right way to go.

Note that requires static alone does not make the module available at run time. That means, even if GSON is launched on a Java runtime that contains the module, it will only be available at run time if some other module requires it (or the app is launched from the class path).

In case you're interested, the blog post shows a method isModulePresent(String) that, well, does what the name suggests. 😁 You can use it (I hereby provide it under the Apache Software License 2.0) if you need to programmatically determine whether java.sql made it into the module graph.

I agree with your confusion about #1500. Turning requires into requires transitive doesn't make a difference regarding its presence at run time - it is present either way (another vlog post). I agree with Alan Bateman's comment - this looks like class loader shenanigans to me.

Copy link
Collaborator Author

Thanks for your clarification! Yes Gson does not need any java.sql types on its own, it only provides (de-)serialization support for them in case they are used.

Your isModulePresent(String) is quite verbose for what it tries to solve. Though maybe there is no better / more complete way of doing this (I have created a StackOverflow question for that). However, Gson cannot use this solution because it wants to support Java 6, so this pull requests checks using Class.forName for a class present in java.sql, assuming that the other classes must be present then as well:

sqlTypesSupport = true;
} catch (ClassNotFoundException classNotFoundException) {
sqlTypesSupport = false;

Regarding previously reported ClassNotFoundException and class loader shenanigans: It looks like Gson itself does not create or uses any special class loaders, so I assume the callers have a broken setup then.

Copy link

mP1 commented Aug 4, 2020

Heres another example of the same problem this time with CLosureCompiler, so+++ from me as well.

[INFO]         java.lang.SecurityException: Prohibited package name: java.sql
[INFO]         	at java.base/java.lang.ClassLoader.preDefineClass(
[INFO]         	at java.base/java.lang.ClassLoader.defineClass(
[INFO]         	at java.base/
[INFO]         	at java.base/
[INFO]         	at java.base/$100(
[INFO]         	at java.base/$
[INFO]         	at java.base/$
[INFO]         	at java.base/ Method)
[INFO]         	at java.base/
[INFO]         	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(
[INFO]         	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(
[INFO]         	at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(
[INFO]         	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
[INFO]         	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
[INFO]         	at<init>(
[INFO]         	at<init>(
[INFO]         	at<init>(

Copy link

neilwightman-intergral commented Aug 13, 2020

This pull request worked great for me in a java agent (which cant use java.sql)

When building it I got this test failure though :

Failed tests: testDateFormatString( expected:<2018-06-2[5]> but was:<2018-06-2[4]>

I'm wondering if this is a timezone issue.
Tests on master branch passed.

Ubuntu 20.04

Copy link
Collaborator Author

Yes the ISO8601UtilsTest is faulty and will be fixed by #1665 / #1687

Copy link

Thanks for your work on resolving this issue with this pull request, @Marcono1234.

@inder123, Is it possible we could get a review on this PR?

When using the jlink CLI tool to build a custom minimal JRE, gson's explicit module dependency adds another 10MB+ of Java module dependencies. A prominent use case of using jlink is building lean Docker images; however, this explicit SQL dependency adds dead weight to the final image (a 20% size increase for my project). Intentionally removing the java.sql module results in a runtime error of java.lang.NoClassDefFoundError: java/sql/Time, despite it not being necessary for execution.

The indirect/transitive module dependencies that end up being added are listed here:

I would really appreciate seeing the java.sql dependency being optional. Thank you for your time.

Copy link

I ran this against all of Google's internal tests that depend (directly or indirectly) on Gson, and didn't see any problems. I think this is good to go.

@eamonnmcmanus eamonnmcmanus merged commit 1023f0f into google:master Aug 25, 2021
@Marcono1234 Marcono1234 deleted the optional-sql branch August 25, 2021 20:02
@Marcono1234 Marcono1234 mentioned this pull request Sep 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

Remove support for java.sql types
7 participants