[
https://issues.apache.org/jira/browse/DERBY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295078#comment-15295078
]
Bryan Pendleton commented on DERBY-6854:
----------------------------------------
Does this classloader re-arrangement have any effect on the way that an
application loads JDBC drivers for use? That is, things like the auto-loaded
driver, DriverManager.registerDriver, etc?
Where's a good resource to learn about the difference between the "boot" and
"platform" classloaders? I looked at
https://en.wikipedia.org/wiki/Java_Classloader, but it is nearly 10 years old,
and simply says:
When the JVM is started, three class loaders are used:[3][4]
* Bootstrap class loader
* Extensions class loader
* System class loader
> 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)