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: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 23 Nov 2005 20:01:05 GMT
Ok, sorry if I haven't been clear.  I appreciate all the feedback I 
received on the proposed patch.  There are small bugs that can be fixed, 
and I think we'd have something somewhat livable.

However, the issues raised by Deepa around what it takes to code 
forward-compatible code and your issues around not putting code that is 
going to change a lot into the shared code area, have underscored my 
desire to remove the compatibility hoops you have to jump through with 
the current proposal.

This may be as best we can do, and it looks like it would be accepted. 
If we go down that route, I will spend more time working with you to 
make sure we're clear on the impact of package sealing.

However, since I have submitted the patch, I have come up with an idea 
for how to create and install a specialized classloader for Derby such 
that Derby jars that contain common code don't "bump into each other" in 
a mixed version environment.

I'm still working out the details, and it's more than possible it won't 
be feasible, but here's the general idea:

- It is possible for to inspect the search path of a classloader for all 
instances of a resource, such as derby.jar or derbyclient.jar

- Use this mechnaism to search the default classloader and then build a 
URLClassLoader that only has the latest version of derbyclient.jar (for 
the network client driver) or of derby.jar (for the  embedded driver).

- This classloader is "installed" as the default classloader for loading 
common code (I don't want to get into the details of this just yet, 
still working it out).

- In this way, with no code changes, you are guaranteed to get the 
latest version of your client or engine driver *and* common code without 
any issues of shadowing that has been the source of building this entire 
framework in the patch I submitted around compatibility.

Note that getting the latest version is the best we can do without code 
changes.  If you want a specific version of Derby for your specific 
application, that's going to take some configuration, which requires 
some change to the Derby API...


Kathey Marsden wrote:
> David Van Couvering (JIRA) wrote:
>>   [ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12358384
>>David Van Couvering commented on DERBY-289:
>>I am aware of the package sealing issue.  The unit test I wrote actually has a test
case that shows what package sealing does.  One way package sealing impacts things that new
classes can not be loaded from a package where a class was already loaded from the old jar
file -- it's another form of "shadowing".
> OK.  I am not sure I understand the full  implications of this.  I am
> also a little confused about the status of your patch.    It kind of
> sounds like you are taking the whole code sharing thing in a new
> direction, so maybe it is not important for me to understand right now. 
> Could you  clarify where we are on  the  code sharing proposal? 
> Thanks
> Kathey

View raw message