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 18:35:28 GMT
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
> 
>>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
>>   JVMs.
>>
>>   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.
> 
> 
> Hopefully I made it clear in my other e-mail, but the issue is not how
> the code is laid out, but do we want to require Derby contributors &
> committers to download multiple JDKs to build Derby, or a single one?
> And how do I make progress on J2ME if developers cannot download a J2ME
> environment?
> 

I still see this as an effect of the one-jar-fits-all model that 
requires everything to be built all the time.

If we had three small modules for the JDBC API impls then they could be 
compiled once under the appropriate JDK and then just referenced by 
others as needed (e.g. during packaging). The amount of code in each 
would be small and stagnant so there would be no need to build from 
source all the time.

Under this model, I could do all my development and testing using 1.4 
and the JDCB3.0 modules and you would do all your development and 
testing using J2ME and the JSR169 modules. We take care in shared code 
not to use features that are not available in the other platform. We 
both make progress, and rapidly because we can concentrate on the 
feature we're working on rather than the cross-platform build.

Every so often, say nightly, an automated process builds all versions on 
all platforms so as a whole we catch any issues with inappropriate 
dependencies or non-portable code. That process may be Gump, it may be 
something else.

For this to work, we would need to break things down so that a developer 
could work with just one platform at a time. I think that means moving 
away from the one-jar-fits-all model to a package-by-platform model.

--
Jeremy

Mime
View raw message