db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Sharing code
Date Sat, 03 Sep 2005 22:52:16 GMT

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.


> Thanks,
> David

View raw message