On thinking further about this, I have a couple more questions/concerns
- I think Jeremy has a very good point that has not been directly
answered. If we do not allow potential compatibility issues by running
multiple versions in the same VM, then doesn't that mean we are not
going to be willing to incorporate third-party components like from
Jakarta Commons?
I think this is a real problem, and I think a stance like this would not
be looked upon positively from the rest of the Apache community.
- It seems to me that the environments in which mixed versions in the
same VM occur are:
* app servers, which already deal with this through multiple
classloaders
* home-built servers in which case we can expect the user to be
expert enough to know how to affect the order in which jars are loaded
- I agree with Jeremy that dealing with shared resources is a well-known
problem and although mistakes can happen good app providers know how to
deal with this. Is it our responsibility to munge our code and paint
ourselves into a corner regarding use of shared components to deal with
app providers who don't know how to work with this?
Thanks,
David
Jeremy Boynes wrote:
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
David W. Van Couvering wrote:
Can't you have the situation where common 10.2 and common 10.3 are
both included in the classpath (by accident, as Dan brings up)?
Wouldn't you end up with order dependencies then?
I feel my scenario keeps being misrepresented by the choice of terms
used to decribe it. Using 'accident' makes it sounds as though it's not
an important problem to deal with, as seen in Jeremy's reponse here:
To what extent do we need to cater for accidents?
The end user didn't accidently install two applications, they chose to
and didn't realise/know that one used client at version 10.2 and one
used engine at version 10.3. In many cases the use of Derby engine is
hidden by the application developer.
I actually thought "accident" was appropriate here :-) The collision in
Derby versions is "an unexpected and undesirable event, especially one
resulting in damage or harm"[1] arising from the installation of two
applications.
I would assign fault here to the application providers who are not
allowing for other applications using a common shared resource - the
system or user classpath; it's like if they both insisted in being
installed in the same directory.
I would also say that most application providers are aware of this
problem (usually from some unfortunate prior experience) and take
explicit control of the classpath using mechanisms described elsewhere.
Their end-users are unaffected by this scenario.
So whilst there is high impact from your scenario, it applies to
end-users who install multiple applications that do not exhibit
classpath discipline and which happen to use different versions of Derby
client and engine (but not two different engine versions or two
different client versions). And never mind that these users may be
affected by any other libraries these applications use.
Rather than address this ourselves (and just for Derby) by convoluted
code-rewrites and avoidance of third party libraries we should encourage
the application providers avoid this entirely by exhibiting discipline
when using shared resources. We can even point them at something like:
http://classworlds.codehaus.org/
--
Jeremy
[1] http://dictionary.reference.com/search?q=accident
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
