db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 21:59:27 GMT
Kathey Marsden wrote:
> Jeremy Boynes wrote:
>>In that context, components that come to mind are engine, client, net,
>>tools and common and external dependencies for consideration include
>>logging, configuration and thread management.
> What type of version  interoperability do you propose for these
> components and how would that be managed?

I think the same as what we have proposed earlier on this thread.

The public interface for any component can only be extended at the same 
major.minor level. So 10.3 may have stuff that 10.1 does not have but a 
consumer built against 10.1 is guaranteed to work with any 10.X 
implementation provided X >= 1. Any incompatible changes require a new 
major version and no compatibility is implied.

Implementation can provide version information about themselves and 
about the interfaces they support; this might be through the Package 
info or through some custom mechanisn. Consumers can query that and 
adapt as appropriate.

This applies within a single classloader; if a user needs a more 
esoteric scheme within a single JVM then they need to isolate the 
versions from each other by using different classloaders. I do not 
consider this an unrealistic expectation given this is a non-trivial 
case in the first place.

One thing I think we should add is separation between in-VM client (the 
JDBC implementation) and the engine implementation. This should allow a 
program in one classloader to access an engine in another; this may 
involve data copies which would make it less performant than an 
in-classloader configuration but it will be better than using a network 
connection which is the only option now.

Across JVMs we support up-down compatibility across a wider spread of 
versions but that can be done with the wire protocol and does not need 
class-level compatibility.


View raw message