db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olav Sandstaa <Olav.Sands...@Sun.COM>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Sat, 27 May 2006 07:32:56 GMT
Myrna van Lunteren wrote:
> On 5/26/06, Olav Sandstaa <Olav.Sandstaa@sun.com> wrote:
> [...snipped excellent investigative work...]
>> Any preferences or suggestions for better ideas?
>> Thanks,
>> Olav
> I may be misunderstanding or just have missed it, but why does this
> work with jdk15 and earlier?
My understanding is that it works with jdk15 and earlier since these 
jvms do not support/do autoloading of JDBC drivers:

 * When you run derbyall with jdk15 and earlier the embedded driver will 
be loaded when the Nist tests (via ij) explicitly requests the embedded 
driver to be loaded (via Class.forName(....)). At this point 
derby.system.home is set to the correct value.

 * When you run derbyall with jdk16 autoloading is in effect (see 
Derby-930), and the embedded Derby driver is loaded during startup of 
the test harness when the RunList.shouldSkipTest loads the DB2 driver:

       // skip if the IBM Universal JDBC Driver is not in the Classpath
       // note that that driver loads some javax.naming.* classes which
may not
       // be present at runtime, and thus we need to catch a possible
error too
       try {
           Class.forName("com.ibm.db2.jcc.DB2Driver");  // THIS LOADS 

Due to autoloading, the Embedded driver is also loaded here. I guess the 
reason is that the DB2 driver issues some calls that make the class 
loader look in the derby.jar file and then autoloads the embedded 
driver. (I might be wrong about the details here, but this is what I 
have observed). At this point in the test derby.system.home is not set. 
When the Nist tests starts this instance of the embedded driver and 
Derby engine is used.

Did this explanation make it more clear why we do not see this problem 
with jdk15 and ealrier, only with jdk16?


View raw message