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
