Driver registration, Derby drivers and Derby versions

[Russell Bateman <ru...@windofkeltia.com>]

How do the myriad Derby drivers work?

I am using Apache Derby in-memory with no daemon or outside dependencies 
in support of being called from JUnit tests. This is working pretty 
well, but what it's going to be doing underneath will eventually cause 
me to walk the following road, I think.

I am using 10.15.2.0. I find myself needing to register a driver such 
that a call to DriverManager.getConnection()will find it. (Or, I think I 
do; I'm looking at some existing homespun mocking code that does this 
and I'm trying to imitate then replace it with Derby.)

     DriverManager.registerDriver( new 
org.apache.derby.jdbc.AutoLoadedDriver() );

Here and there, in examples on-line, I see references to drivers like:

    org.apache.derby.jdbc.AutoloadedDriver
    org.apache.derby.jdbc.EmbeddedDriver

However, unless I'm mistaken, these do not exist in derby 10.15.2.0. I 
am using derby-10.15.2.0.jar. I have also tried adding the same 
version's shared and tools JARs.

Any thoughts on this would help. I only discovered this phenomenon of 
registering drivers today, so I'm stumbling around a bit.

Thanks.

Re: Driver registration, Derby drivers and Derby versions

[Russell Bateman <ru...@windofkeltia.com>]

Rick,

This is helpful to understand. I have noticed as I perused myriad 
examples of third-party use-Derby examples that how Derby is set up 
seems to have changed in past versions. Some authors have pointed out 
Java versions and Derby versions in relevance to their samples. (And, I 
prefer using the latest Derby, of course.)

However, it's an unstable state for me. I was able to get connections 
via java.sql.DriverManager.getConnection()for several days, but then it 
stopped working. Debugging through this method, I see in (private) 
DriverManager.getConnection(), when it doesn't work, that the 
registeredDriverslist is empty whereupon I get:

    java.sql.SQLException: No suitable driver found for
    jdbc:derby:memory:sampledb;create=true

Given that I don't/can't/need not do DriverManager.register()in using 
Derby, I am mystified as to why I get away with it sometimes, then find 
it not working.

What is my formal responsibility  to ensure the presence of Derby's 
driver in DriverManager.registeredDriverslist? I'm encouraged to believe 
that this is what calls to DriverManager.registerDriver()accomplish.

My earlier impression was that the simple presence in /pom.xml/ of 
/derby-10.15.2.0.jar/ was sufficient. When it did work, that's all I had 
done (or so I think).

This morning, I have experimented adding Derby dependencies (it doesn't 
even work with derby, derbysharedand derbytoolsJARs present). I fear I 
skipped a step as soon as, last week, it began working thinking I was 
home and free. I'm sure I have done something to break that in the 
meantime. As noted, I'm trying to replace /ad hoc/ mocking code with 
something more "live" that I can use to regress and debug my JDBC code 
and have chosen Derby to accomplish this.

Many thanks,
Russ

On 7/8/20 6:49 AM, Rick Hillegas wrote:
> Hi Russell,
>
> This is a little complicated because it involves a bit of history. 
> Derby and Java grew up together. The core of Derby is the Cloudscape 
> database engine, which appeared around 1996, close to the the 
> appearance of Java itself. Two significant events in the evolution of 
> Java have affected what happened to the Derby drivers. Where the code 
> ended up is a little weird, but the aim all along has been to minimize 
> disruption to legacy applications. The two events are:
>
> 1) The introduction of JDBC driver autoloading in Java 5 and the 
> further refinement of driver autoloading in Java 6.
>
> 2) The introduction of the JPMS module architecture in Java 9.
>
> If you are getting connections via 
> java.sql.DriverManager.getConnection(), then you don't need to 
> register drivers at all. That is because the JVM will load all of the 
> JDBC drivers which are visible on the application classpath--that is, 
> all of the drivers which have metadata recorded in the manifests of 
> their respective jar files.
>
> In Derby 10.15, the drivers around, in order to achieve the clean 
> package partitioning required by JPMS. The original embedded driver 
> now lives in the tools jar. The autoloading driver moved into another 
> package in the engine jar. It is now called 
> org.apache.derby.iapi.jdbc.AutoloadedDriver.
>
> Hope this helps,
> -Rick
>
>
> On 7/7/20 6:00 PM, Russell Bateman wrote:
>> How do the myriad Derby drivers work?
>>
>> I am using Apache Derby in-memory with no daemon or outside 
>> dependencies in support of being called from JUnit tests. This is 
>> working pretty well, but what it's going to be doing underneath will 
>> eventually cause me to walk the following road, I think.
>>
>> I am using 10.15.2.0. I find myself needing to register a driver such 
>> that a call to DriverManager.getConnection()will find it. (Or, I 
>> think I do; I'm looking at some existing homespun mocking code that 
>> does this and I'm trying to imitate then replace it with Derby.)
>>
>>     DriverManager.registerDriver( new 
>> org.apache.derby.jdbc.AutoLoadedDriver() );
>>
>> Here and there, in examples on-line, I see references to drivers like:
>>
>>    org.apache.derby.jdbc.AutoloadedDriver
>>    org.apache.derby.jdbc.EmbeddedDriver
>>
>> However, unless I'm mistaken, these do not exist in derby 10.15.2.0. 
>> I am using derby-10.15.2.0.jar. I have also tried adding the same 
>> version's shared and tools JARs.
>>
>> Any thoughts on this would help. I only discovered this phenomenon of 
>> registering drivers today, so I'm stumbling around a bit.
>>
>> Thanks.
>>
>

Re: Driver registration, Derby drivers and Derby versions

[Rick Hillegas <ri...@gmail.com>]

Hi Russell,

This is a little complicated because it involves a bit of history. Derby 
and Java grew up together. The core of Derby is the Cloudscape database 
engine, which appeared around 1996, close to the the appearance of Java 
itself. Two significant events in the evolution of Java have affected 
what happened to the Derby drivers. Where the code ended up is a little 
weird, but the aim all along has been to minimize disruption to legacy 
applications. The two events are:

1) The introduction of JDBC driver autoloading in Java 5 and the further 
refinement of driver autoloading in Java 6.

2) The introduction of the JPMS module architecture in Java 9.

If you are getting connections via 
java.sql.DriverManager.getConnection(), then you don't need to register 
drivers at all. That is because the JVM will load all of the JDBC 
drivers which are visible on the application classpath--that is, all of 
the drivers which have metadata recorded in the manifests of their 
respective jar files.

In Derby 10.15, the drivers around, in order to achieve the clean 
package partitioning required by JPMS. The original embedded driver now 
lives in the tools jar. The autoloading driver moved into another 
package in the engine jar. It is now called 
org.apache.derby.iapi.jdbc.AutoloadedDriver.

Hope this helps,
-Rick


On 7/7/20 6:00 PM, Russell Bateman wrote:
> How do the myriad Derby drivers work?
>
> I am using Apache Derby in-memory with no daemon or outside 
> dependencies in support of being called from JUnit tests. This is 
> working pretty well, but what it's going to be doing underneath will 
> eventually cause me to walk the following road, I think.
>
> I am using 10.15.2.0. I find myself needing to register a driver such 
> that a call to DriverManager.getConnection()will find it. (Or, I think 
> I do; I'm looking at some existing homespun mocking code that does 
> this and I'm trying to imitate then replace it with Derby.)
>
>     DriverManager.registerDriver( new 
> org.apache.derby.jdbc.AutoLoadedDriver() );
>
> Here and there, in examples on-line, I see references to drivers like:
>
>    org.apache.derby.jdbc.AutoloadedDriver
>    org.apache.derby.jdbc.EmbeddedDriver
>
> However, unless I'm mistaken, these do not exist in derby 10.15.2.0. I 
> am using derby-10.15.2.0.jar. I have also tried adding the same 
> version's shared and tools JARs.
>
> Any thoughts on this would help. I only discovered this phenomenon of 
> registering drivers today, so I'm stumbling around a bit.
>
> Thanks.
>