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 Thu, 15 Sep 2005 15:43:55 GMT
One thing I'd like to raise is that the code cloning is a build process. 
  If in the future we realize we have painted ourselves into a corner, 
unless I'm missing something we can just remove the cloning step and we 
have the module-based approach that Jeremy and I have been backing.



Jeremy Boynes wrote:
> 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

View raw message