db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6854) Make it possible to run Derby tests on early access versions of JDK 9
Date Sat, 21 May 2016 21:24:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295268#comment-15295268

ASF subversion and git services commented on DERBY-6854:

Commit 1744989 from [~knutanders] in branch 'code/trunk'
[ https://svn.apache.org/r1744989 ]

DERBY-6854: Make it possible to run Derby tests on early access
versions of JDK 9

JDK 9 will move the JDBC classes out of the boot class loader and into
the platform class loader (see JDK-8154189 in the OpenJDK bug

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

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.

> 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:
>            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

View raw message