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
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
