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 Sharing code
Date Thu, 01 Sep 2005 22:34:44 GMT
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.

Thanks,

David




Mime
View raw message