db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Sharing code
Date Fri, 02 Sep 2005 16:36:44 GMT
Yes it's true that we can't control the ordering of a classpath, and we 
do need to address this.  However, most version policies I have worked 
with let an old version of a consumer work with a new version of 
producer, but if a new version of consumer tries to use an old version 
of producer it gets an exception.  Even today if a new version of Derby 
finds an old version of a database file, it performs some form of 
upgrade before it will work with it (right?) rather than continuing to 
work with the old format (right?).

Maybe you have an idea of how to make it easy to accomplish, but as far 
as I can see, it's a big burden on the developers of consumer classes to 
know how to "work with" older versions of common services, especially 
when this type of configuration (with mixed versions of jar files) is 
such an edge case.

That said, I think it's not right for the user to get some strange 
NoSuchMethodException when the new consumer tries to use a method that 
doesn't exist in the old producer.  So it seems to me we need some type 
of service manager (I'm not committing to which one yet, I need to do 
some investigation) that allows you to say something like "give me an 
implementation of this interface at this version level or higher".  If 
the service manager says "I don't have that" then we can throw an 
exception saying something like "Unable to load version 10.2 of the 
Message Service.  It is probable that your classpath has older versions 
of Derby jar files listed first; please check your classpath and make 
sure that all Derby jar files are listed ahead of older versions."


Daniel John Debrunner wrote:

>David W. Van Couvering wrote:
>>Hi, all.  Yes, it's your favorite topic.  :)
>[snipped - good shared code proposal]
>>The common classes will be placed into both derby.jar and
>>derbyclient.jar.  When you have a classpath with a network client at one
>>revision and the embedded driver at another revision, the jar with the
>>highest revision should always go first,
>The issue is how to enforce that. I think it's impossible to enforce
>that or guarantee any class path ordering. Remember class path problems
>are by far the leading cause of technical support calls related to Java
>What it means is that the interface needs to have a version number that
>can be obtained easily, and thus the caller must only use the interface
>to the level offered. If a caller was written against version 3, but
>only version 2 is available then it can only use version 2 functionality.

View raw message