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: Modular build, was: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 23:24:58 GMT
Well, this is an interesting wrench you have thrown in here, Jeremy.  I 
personally have always been a believer in the scheme you suggest, with 
modules of code being built independently rather than a single 
monolithic code base.  It allows for greater flexibility, but it does 
require a lot more discipline in terms of version compatibility.  This 
is the way Solaris works, for instance, and they have been quite 
successful at it.  But you should see the level of rigor they apply here 
at Sun to make sure that works.  Before this level of rigor was applied, 
Solaris was a nasty ball of yarn indeed.

Now, we do have a guide for us in this approach.  Jakarta Commons is a 
collection of independent modules that are released independently, and 
which must meet strong compatibility rules.  Take a look at their 
versioning guidelines here:

http://jakarta.apache.org/commons/releases/versioning.html

The question is, what are the benefits of the approach, and do they 
merit the rigor that we would have to follow to make sure things don't 
break?  I have to think about this myself.  What do others think?

P.S. Jeremy I don't understand why separate classloaders are needed to 
work with different versions in the same VM, if we meet compatibility rules.

David

Jeremy Boynes wrote:

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


Mime
View raw message