db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: derbytools.jar loading derbyclient.jar
Date Wed, 01 Mar 2006 00:58:27 GMT
On 2/27/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
> So from what I understand, your patch for DERBY-1063 will reintroduce
> the DERBY-1045 regression  that derbytools will load a different
> derbyclient.jar than the one specificed by the user CLASSPATH but will
> improve the sysinfo output .  Is that correct?

First, let me say that I think that the sysinfo change could probably stand
on its own, in light of DERBY-668, although I made it with the goal of
resolving DERBY-1063 in mind.

With the sysinfo change, there is less chance of shadowing in general
with sysinfo. Any classes available to sysinfo will be displayed,
first, followed by any non-duplicated jars found to contain Derby

The answer to your question is yes, though, but DERBY-1045 is a
specific regression that occurs if:

* derbytools.jar, from 10.2 - with my patch for DERBY-1063 - is on the
classpath before some other version of derbyclient.jar, and the new
derbytools.jar resides in the same directory as derby.jar or
derbyclient.jar from 10.2


* a previous version of derby.jar or derbyclient.jar is on the
classpath, but after
derbytools.jar + DERBY-1063.

but not if:

* derbytools.jar from 10.2 (or, perhaps, later) is not on the classpath
* derbytools.jar from 10.2 appears later in the classpath than a
previous version of derbyclient.jar
* derbytools.jar is not in the same location as derby.jar or derbyclient.jar

The question arises:

How often is this likely to occur? Is this a typical use of Derby?
It's interesting that the testing brought DERBY-1045 to light, but
that's because the test just puts all the jars in the classpath. I'm
wondering how typical it is to have multiple versions of Derby on the
classpath (not necessarily loaded via classloaders).

It would seem to me that having multiple versions of Derby (or, at
least different major/minor versions of the same jar file) on the
classpath would never be guaranteed to work. If there are two versions
of the same jar on the classpath, it seems there would be no way to
prevent NoSuchMethodExceptions or IncompatibleClassChangeErrors for
classes that had methods removed or method signatures changed between
versions, and that would apply to all internal classes, not just
public api.

Also note that it only affects jars loaded via the -jars option or via
the classpath. The Class-Path attribute would have no affect on
classes loaded via a custom classloader or in an environment where
custom classloaders are used to partition resources, such as in a J2EE

> I am really very uncomfortable with anything that requires
> CLASSPATH ordering or causes one derby installation to affect
> another, but I'll think about it some more.

And this is a valid concern, which I understand.

I think the question here boils down to: in what situations would a
third party ship derbytools.jar, and include it on the classpath with
a previous version of derbyclient.jar? Is that a good practice anyway?

I don't have an immediate answer to either of those questions,
although my instict is to say "no" to the second one.

> I'd like to hear what others think.   Meanwhile could you say how
> this would be documented. Maybe that would better help me to understand
> the impact.

It should be documented in the Tools and Utilities guide,
demonstrating the optional syntax for executing the tools, as well as
in Getting Started where appropriate.

Also, it seems like, based on this and other issues and your proposal
for an 'application impact' checkbox in JIRA, that a section in the
Release Notes, or perhaps even a separate document, that covers all
potential application-visible changes is called for. Perhaps as a part
of a larger document about upgrading from previous versions to 10.2.
If you have other suggestions for how to document the change, I would
like to hear them.


View raw message