[
https://issues.apache.org/jira/browse/DERBY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6854:
--------------------------------------
Attachment: d6854-classloader.diff
The JDBC classes are about to be moved out of the boot class loader and into
the platform class loader in JDK 9. See
[JDK-8154189|https://bugs.openjdk.java.net/browse/JDK-8154189] in the OpenJDK
bug tracker for details.
I ran the regression tests with JDK 9 patched up with the changes suggested in
the OpenJDK bug report to see if it would break anything. With sane jars, most
of the tests that ran under a security manager failed with
AccessControlExceptions. It looked better with insane jars, but there were
still failures (NoClassDefFoundErrors) in the upgrade tests and
SysinfoLocaleTest.
The reason is that Derby has some test and debug code that assumes that the
JDBC classes live in the boot class loader:
1) Some tests create a new class loader in order to make the test load the
Derby classes afresh (SysinfoLocaleTest), or to test against a different
version of Derby (the upgrade tests). To achieve this, they create a
URLClassLoader which contains the Derby jar files they want to test against,
and set the parent of the URLClassLoader to null, which means that the boot
class loader is the parent.
Now that the JDBC classes are not on the boot class loader, this URLClassLoader
is not able to find the JDBC classes, and the tests fail with
NoClassDefFoundErrors when trying to load them.
This is fixed by setting the parent of the created URLClassLoader to what
java.sql.Connection.class.getClassLoader() returns. On JDK 8 and earlier it
returns null, so nothing changes there. On JDK 9 it returns the platform class
loader, which is capable of loading the JDBC classes.
2) The org.apache.derby.impl.services.bytecode.d_BCValidate class contains some
debug code (only included in the sane jars) which runs some sanity checks on
the generated byte code. To do this, it accesses the class loader of all the
classes in the method signatures.
When getClassLoader() is called on JDBC classes, a RuntimePermission is needed
now. This was not the case before when the JDBC classes were in the boot class
loader, since Class.getClassLoader() does not check for permissions if the
class loader is null. Now this causes an AccessControlException in tests that
run with a security manager. The tests actually grant the required permission
to derby.jar, but the call is not wrapped in AccessController.doPrivileged(),
so it fails because the permission is not granted to the test code.
The fix is to wrap the call to getClassLoader() in a doPrivileged() block.
Additionally, because RuntimePermission("getClassLoader") is not a mandatory
permission for derby.jar, we need to check if it raises a security exception.
d_BCValidate only needs the class loader in order to check if it is the same
class loader as d_BCValidate's own class loader. Since Class.getClassLoader()
does not require any permissions if the class has the same class loader as the
calling class, we can conclude that the class loaders are different if a
security exception is raised.
The attached patch [^d6854-classloader.diff] makes those changes. With this
patch, the tests run cleanly both with JDK 8 and with JDK 9 in my environment.
> Make it possible to run Derby tests on early access versions of JDK 9
> ---------------------------------------------------------------------
>
> Key: DERBY-6854
> URL: https://issues.apache.org/jira/browse/DERBY-6854
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.12.1.1
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: d6854-classloader.diff, derby-6854-01-aa-fixFor9-ea.diff
>
>
> Early access versions of JDK 9 (build 100) have "9-ea" as the java.version
> and "9" as the java.specification.version. This confuses the
> JavaVersionHolder class which the regression tests use in order to determine
> the vm level. At a minimum, we need to make JavaVersionHolder recognize these
> early access strings.
> This issue can be left open even after a fix is applied because we have no
> idea how java.version and java.specification.version are going to evolve over
> the remaining development cycle for JDK 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
