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 Sun, 04 Sep 2005 02:13:32 GMT
Sorry, Lance, I am assuming you mean I can't enforce classpath order.  
Yes, Dan has also made that point, thanks.


Lance J. Andersen wrote:

> David W. Van Couvering wrote:
>> Hi, all.  Yes, it's your favorite topic.  :)
>> I've been thinking about this further, and I would like to say that 
>> it's time to bite the bullet and address this.  I am planning on 
>> piloting this with the i18n work so that I can reuse the 
>> message.properties file rather than duplicate error messages. I am 
>> sure other uses will quickly follow.
>> I talked with Craig Russell today, and he had some very helpful 
>> advice for an approach to common code.  It is based on employing 
>> engineering discipline and policies around shared code.
>> The basic principle is you have full backward compatibility.  Each 
>> new revision of shared code has behavior and interfaces that are 
>> fully backward-compatible with older revisions.  Here is my proposal 
>> on how this is implemented.  After some discussion, I'd like to put 
>> this up for a vote.
>> - An "interface" is defined as anything externally visible that is or 
>> may be depended upon by subsystems outside of the common packages.  
>> This is not just a Java interface, but any method, constant, 
>> variable, class name, package name, etc., that is externally accessible.
>> - All common interfaces are guaranteed to work as defined in all 
>> subsequent releases of Derby.  This means you can't for instance keep 
>> the same method signature but rewrite its behavior. - If you want to 
>> introduce a new revision of an interface (e.g. new arguments or new 
>> behavior), you do not modify or remove the old interface.  You 
>> instead create a completely new revision.  For example, if you have a 
>> method doIt(int a), then the new version would be doIt_2(int a) or 
>> doIt(int a, String b)
>> - If an interface needs to be deprecated, it is documented as 
>> deprecated and is removed in the next major release (e.g if it's 
>> deprecated in 10.2, it can be removed in 11.0).  This should be 
>> avoided if at all possible
>> 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, e.g 
>> "/home/derby/10.2/derbyclient.jar:/home/derby/10.1/derby.jar".  This 
>> ensures that the newer code that depends on new interfaces (e.g. a 
>> new method for a class) will be able to function properly.
> Hi David,
> I do not believe you can enforce this if you are you the lib ext dir 
> model which would make this problematic for a J2EE environment.
> Regards
> Lance
>> Thanks,
>> David

View raw message