Hi, Kathy, I am a bit confused by your response. You seem to be OK with
the classpath ordering issue given that it's an edge case, but you say
you want to go for approach 2. Approach 2 does not require any
classpath ordering.
Also, note that in general classpath ordering isn't important except in
the case where the user is already consciously futzing with the
classpath to mix versions in the same VM.
David
Hi David,
Thank you very much for the clear explanation. From a usability
perspective, I would vote for approach 2. Requiring a classpath to be
in a particular order is always an issue. However, the saving grace
is that it sounds like the ordering issue only comes up if you mix
versions of the derby.jar and the derbyclient.jar in the same
classpath. I don't believe most users put the client and engine in
the same classpath (unless there's a new requirement I don't know
about), so that definitely helps. Requiring classpath in a specific
order can easily lead to complications though, so I'm not in favor of
it in general.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
