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 Thu, 15 Sep 2005 05:10:05 GMT
David W. Van Couvering wrote:
> 
> 
> Jeremy Boynes wrote:
> [snip]
> 
>> Daniel John Debrunner wrote:
>>
>>> The issue is that today this is fully supported because the client and
>>> engine do not share code.
>>>
>>> Some of the code sharing approaches regress Derby in this area by not
>>> supporting this, or require class path ordering for it to be supported.
>>>
>>
>> Some of the others support this by defining compatibility contracts 
>> and eliminate the need for classpath ordering by not duplicating classes.
> 
> 
> Can't you have the situation where common 10.2 and common 10.3 are both 
> included in the classpath (by accident, as Dan brings up)?  Wouldn't you 
> end up with order dependencies then?
> 

To what extent do we need to cater for accidents? But, yes if you do end 
up with both then the (actual) order would determine which one you ended 
up with. In many cases the user would not notice due to the API 
compatibility between 10.2 and 10.3 (with 10.3 being a pure superset by 
the rules defined). The key thing is that there is no overlap in 
functionality between jars (so you are not getting 10.2 (containing 
client + common) merged with 10.3 (containing engine + common)).

> [snip]
> 
>> Let's recharacterize this a little. What we are contemplating with 
>> code sharing is extracting common functionality out into a library. By 
>> saying that we are not willing to accept any solution where a 
>> component depends on a library we are shutting ourselves off from 
>> using any external library or any functionality not provided by Derby 
>> itself. This dooms us forever to reinvent any functionality that could 
>> be provided by other projects.
>>
>> For example, there are libraries out there that support bytecode 
>> generation, JMX for management, high-performance concurrency on Java 
>> 1.4, regexp processing to support SQL patterns, ... By saying we are 
>> not prepared to incorporate them but instead need our own versions 
>> that can be morphed for client and server we dramatically reduce the 
>> functionality that can be made available to users.
>>
>> So let me ask this: do our users want more functionality faster by 
>> allowing the use of libraries, or a completely standalone solution 
>> with tight control over the entire implementation?
> 
> 
> You make a compelling argument here.  I already would like to use stuff 
> in Jakarta Commons (I haven't brought it up yet, one thing at a time).  
> It seems a good Apache Java citizen should make use of what's in Jakarta 
> Commons rather than build stuff themselves.  And I think Jeremy's right 
> that we will run into this same configuration situation with these guys.
> 
> Jeremy, how *do* the users of commons avoid accidentally using a version 
> they are not compatible with (e.g. a consumer depends on new features 
> that aren't available in an older version of the common jar file)?
> 

This can be a problem - Java's variant of DLL hell. The solution 
generally relies on two factors:
1) upward compatibility between versions - because they are small-ish
    components then they tend to do one thing and not suffer from API
    scope creep. You just use the latest version and add it to the
    classpath once

2) multi-classloader loading mechanisms, which are commonplace in
    open source projects, even command line utilities like Ant and Maven
    not just the application servers

It is kind of self-fulfilling - when you adopt a modular structure then 
you expect to be loading modules with libraries at different version 
levels and so use a classloading architecture that fits.

There is also a cultural thing here. For example, suppose I am writing a 
database because I happen to think writing database stuff is fun (yes, I 
  do realize that doing this for fun makes one appear somewhat odd). I 
come up with the idea that converting the query plan to executable code 
is a neat idea and so need to generate that code. I can implement a code 
generator myself, or look for one out there that is already written and 
is available under a suitable license. Given my main interest is in 
databases, using someone else's code to generate byte code save me a lot 
of effort (especially when the class format changes). If it doesn't do 
what I want, I could hack my own but it is generally easier to donate 
those changes back so that someone else can maintain them. After all, my 
interest is in databases not in byte code generation.

Basically, a volunteer community scales better by incorporating each 
other's code rather than trying to do it all.

--
Jeremy

Mime
View raw message