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: Single JDK14 compile model?
Date Sun, 06 Mar 2005 00:02:49 GMT
RPost wrote:
>>Jeremy Boynes wrote:
>>Having one JAR for the database is nice, but not if the price is
>>post-compilation bytecode hacks.
> So how does everyone feelf about pre-compilation sourcecode hacks?
> Would someone please state the need a little more clearly? 

I think there are two basic problems here:

1) How do we provide implementations of the JDBC interfaces?
    The problem here is that JDBC3.0 (JDK1.4/1.5) added classes
    to the API in java.sql that are not present in JDK1.3 or JSR169

    Perhaps the solution here is to have two separate modules that
    implement the APIs and which are compiled with the appropriate VM.
    We can avoid post-compilation hacks and although we could use source
    code pre-processing I would suggest it may not be necessary as the
    modules would mostly just be delegating to internal Derby classes
    making it trivial to support two separate code trees.

    This is very similar to how the build works now. We may be able to
    simplify this by building the API implementations totally separately
    so most of the time people would just use the one for their platform.

2) How do we provide different configurations for distribution?
    Essentially, are we sticking with the one-jar-fits-all model or
    should we break things down into separate modules that can be built
    and packaged separately. In the separate module model, different
    versions could be built for different platforms and assembled into
    distributable configurations as needed but users would need to
    select the configuration applicable to their environment.

If done right, the separate module approach can work very well e.g. 
Apache HTTPD, Eclipse, Maven and is well suited to the distributed 
development model that is open source; it can also go horribly wrong if 
not managed properly.

Back last year I did some experimentation with Maven about breaking down 
the build into a module structure. If anyone is interested I could try 
and finish that up so folks can have a look.


View raw message