#1752 HSQLDB should not depend on the jdk.unsupporte module

[Martin Desruisseaux]

The module-info.java file contains the following statement:

requires jdk.unsupported;

Usage of such module is strongly discouraged. It may change in incompatible way in any future Java version. I realize that HSQLDB uses Unsafe for releasing direct buffers, but recent Java versions emit warnings when this class is used, which scare users, and Oracle has clearly announced that many methods of Unsafe will not work anymore in the near future.

I realize that HSQLDB uses reflection for allowing the library to work even if Unsafe does not exist. However, all users are still seeing this scary warning everytime that a project using HSQLDB is run:

A terminally deprecated method in sun.misc.Unsafe has been called
sun.misc.Unsafe::invokeCleaner has been called by org.hsqldb.lib.java.JavaSystem (file:hsqldb.jar)
Please consider reporting this to the maintainers of class org.hsqldb.lib.java.JavaSystem
sun.misc.Unsafe::invokeCleaner will be removed in a future release

I realize that we can silent this warning with the --sun-misc-unsafe-memory-access option, but this is not guaranteed to exist in all Java implementations. Furthermore, for projects that are themselves libraries, we are just cascading the problem to our own users.

This is a potentially blocking issue: if HSQLDB is on the module-path of a Java platform that do not have the jdk.unsupported module, the JVM will refuse to launch the whole application. Using reflection in the HSQLDB source code changes nothing to this problem. Oracle said that modules starting with jdk. "are specific to the JDK and will not necessarily be available in all implementations of the Java SE Platform." (source: Javadoc overview page).

Proposal

At the very least, the statement in module-info.java should be replaced by the following:

requires static jdk.unsupported;

The static keyword means that the module is optional. That way, we do not prevent the application to launch if this module does not exist. I think that this change can be done immediately with no impact on the remaining of HSQLDB.

Second, disable the use of Unsafe by default. Enable it only if the user explicitly requested this feature with a system property. This change would solve the scary warning problem. Users willing to provide the --sun-misc-unsafe-memory-access option can also provide a -D option,

Finally, maybe in a later release, I think that the dependency to jdk.unsupported should be completely removed and HSQLDB should rely solely on the garbage collector instead for the release of direct buffers. The method invoked by HSQLDB will disappear anyway. Removing that dependency soon may be preferable, because many users do not upgrade their dependencies for years. For example, I think that the next HSQLDB release will still be in use even with Java 30 or 40.

[Martin Desruisseaux]

Additional notes:

• H2 already disable the use of Unsafe by default. It users want it, they need to enable it by setting the h2.nioCleanerHack property to true.
• According https://openjdk.org/jeps/498, "JDK 26 or later will throw an exception whenever a memory-access method is used, whether directly or via reflection. This will further alert application developers and users to the imminent removal of the methods."

While Java 26 is released and does not yet throw an exception, it may happen very soon in any future Java version.

[Fred Toussi]

Thanks. I will apply the minimum amount of change for the next release. Other changes may happen later.

[Martin Desruisseaux]

Thanks. Note that H2 documentation said that if Unsafe is not explicitly enabled, H2 invokes System.gc() in a loop. I would suggest to rather do nothing. Just let the garbage collector do its work as usual.

[Fred Toussi]

Changed to

requires static jdk.unsupported;