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 PLEASE READ AND REVIEW: Proposed text for code sharing contribution
Date Wed, 09 Nov 2005 19:11:55 GMT

Here is the proposed text of the vote describing the approach and impact 
of sharing code that would come along with the contribution that I would 
be submitting for a vote.  Your comments and refinements are requested 
now, so that when it comes time for a vote we can avoid a debate on the 
wording and just have the vote.

Thanks,

David

=========

This contribution provides a framework to allow code sharing across the 
Derby product jars. Sharing code provides many important benefits, such as

   - Avoiding code (and bug) duplication (e.g. no cut-and-paste)
   - Improving Derby developer productivity
   - Ensuring consistency/compatibility between client and server
   - Providing a clear repository for code that is usable across Derby 
jar files

This framework will not have any significant impact on jar file size or 
otherwise affect product distribution or usage.

This contribution provides mechanisms and guidelines, such as guidelines 
and tools for supporting forward and backward compatibility, to help 
ensure that Derby jars with different versions can be loaded in a Java 
VM without having to use specialized classloaders.  If an 
incompatibility exists between versions, it will be clearly documented. 
  Any undocumented incompatibilities will be treated as a bug.

However, not all issues can be resolved.  For example it is possible for 
"shadowing" to take place if there are different versions of network 
client and embedded client in the same VM, and each provides a different 
implementation of the same common method.

The detailed guidelines for how to provide code sharing to meet these 
goals, and what issues may arise, are provided in the package.html for 
org.apache.derby.common (as part of this contribution).

Although not included in this initial contribution, we will need to 
provide mechanisms to help track down and resolve mixed version issues. 
  Possible mechanisms include:

   - upgrade sysinfo to use the current classloader rather than the 
classpath to determine version information
   - to print a warning if multiple versions of Derby are detected 
within the same classloader context.
   - update documentation to warn users about these potential issues and 
how they can be resolved (by either changing the order in which Derby 
jars are loaded or through using specialized classloaders that isolate 
Derby versions from each other).
   - example code showing how to use classloaders to isolate versions of 
Derby within the same VM

=====

David

Kathey Marsden wrote:
> David Van Couvering (JIRA) wrote:
> 
> 
>>    [ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
>>
>>David Van Couvering updated DERBY-289:
>>--------------------------------------
>>
>>   Attachment: DERBY-289.diff
>>
>>Hi, all.  Here is the proposed patch that provides the framework for code sharing.
 I was thinking folks could look at it and discuss, and then once issues have (hopefully)
been worked out, we can have a vote.
>>
>> 
>>
> 
> Thanks David for the patch. What will the wording in the vote describing
> the new restrictions on mixing client and server versions in the same
> JVM and the new classpath ordering requirements be?  Having the wording
> now will help provide context in reviewing the patch.
> 
> 
> Kathey
> 
> 

Mime
View raw message