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...
David
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
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
