db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: derbytools.jar loading derbyclient.jar
Date Wed, 01 Mar 2006 07:21:14 GMT
Andrew McIntyre wrote:

> 10.2 tools : 10.1 client : 10.1 engine = 10.2 client / 10.2 engine
> 10.1 client : 10.2 tools : 10.1 engine = 10.1 client / 10.2 engine
> 10.1 derby : 10.1 engine : 10.2 tools = 10.1 client / 10.1 engine
> Of course, I'm not sure what sort of usage (outside of our tests)
> would lead to such a pattern as the above. I'd expand with e.g. 10.2
> derby.jar in there, but that would lead to far too many premutations
> to stick in an email. But you get the idea.

Looking at the classpaths where the behaviour changes for applications
that are expecting the earlier versions:

Let's assume this class path was set up by three independent
applications, A, B & C.

10.2 tools (A) : 10.1 client (B) : 10.1 engine (C)

If application A is using engine *and* client then making the DERBY-1063
changes makes no difference. Without the changes the explicit setting of
classpath required would change the version one of B or C is expecting.

If application A is using client *or* engine then making the DERBY-1063
changes only makes a difference if A ships the jar file it is not using.
Since this is a 10.2 user, and they must have read the documentation
that said they only needed tools in the classpath, then maybe they will
have read any warnings we also put in there about not shipping jars you
don't need.

If application A is really just using ij/dblook, with a different JDBC
driver, maybe Oracle, maybe DB2's JCC for a remote derby engine,
DERBY-1063 does make a difference, but only if application A is shipping
derbyclient.jar and/or derbyengine.jar. Do we care about this usage
enough to hold back usability improvements in Derby? Is anyone using ij
as client to other databases?
In this case they might not have read the docs, maybe they were using
10.1/10.0 and just upgraded, no changes were needed as they are just
using ij/dblook and they only ever needed tools.jar for that.

Then the underlying fact is that we do work hard for compatibility, how
badly will it affect applications B or C in the above cases that they
are picking up the newer client or engine? They will continue to work,
that's our forward compatibility goal, applications continue to work
with no change.

I think the difference to shared code, is that mixed jars in a simple
shared code model could break each other, or reduce functionality, that
doesn't happen here.

View raw message