[ 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)