Olav Sandstaa wrote: > Hi, > > Based on some of the findings with the Nist tests failing when running > with JDK 1.6 due to autoloading of the embedded driver I am not sure if > it is a good idea to support autoloading of the embedded Derby driver. > > Consider the following example: > > 1. Someone is having a small application that is using (for instance) > the DB2 driver to connect to a Derby database. This application is > running with JDK 1.5. It also happens that all the derby jar files in > the path (afterall they do no harm since they are not used). > > 2. Someone is upgrading to JDK 1.6 and restarting this client > application. It is still running as it should, but if the owner > carefully examines it, she notices that the footprint of the application > has increased and a profiler might show that there are at least one > extra thread running (the Derby anti GC and possibly the background > thread?) - basically the embedded driver and the derby engine might > "automagically" have been loaded into the client depending on where > derby.jar happened to be in the class path.
I'm not sure this scenario is a problem. The application upgraded to Derby 10.2 at some point, I hope the 10.2 documentation will indicate that the driver is auto-loaded in a jdk 1.6 environment. Thus this is fully documented behaviour that any application developer must understand. Dan.
