If we were implementing all of this now, we would not separate
AutoloadedDriver from EmbeddedDriver. But Derby co-evolved with the JDK
from the start. By the time that Java introduced driver autoloading, we
already had legacy customers whose applications we did not want to
disturb. We did not
The mock driver supports a sort of bogus URL ("jdbc:mock") that it
recognizes for its purpose which is only to respond to a single query
with canned data (whereas I'll be able to populate Derby with as much
and whatever data I ever want). Of course, its driver doesn't ever do
anything "real,"
It's hard to say what's going on, but the instability in your
experiments is hard to reconcile against the deterministic code paths
involved in JDBC autoloading.
I can only speculate about what is causing this instability:
1) What JDBC URLs does your MockDriver claim to support?
2) Is
...again, don't know what I changed.* I'm only depending on
/derby-10.15.2.0.jar/.
What I think is going on is an artifact of being side-by-side with
another JDBC driver implementation.
I was hoping to keep the original mocked test driver working alongside
the Derby implementation at least
