Knut Anders Hatlen wrote:
more good stuff...
Right, that would solve the issue of compile-time checks without adding
new build dependencies. Writing the stubs for JSR 169 was a much smaller
task, though, since we only needed to strip down a small subset
(java.sql.* and javax.sql.*) of Harmony's class library. Now we're
talking more or less about the full class library. Before we go ahead,
we should probably sort out these things:
o Does Harmony implement all of Foundation Profile 1.1?
o How can we ensure that the stubs have the exact same signatures as the
specification, are complete, and contain no extra classes, interfaces or
methods?
Right. This is a chunk of work which I doubt that anyone is eager to do.
The original topic of this thread, and the thread on derby-user, was to
remove the build-dependency on JDK 1.4. Some components still need to be
compiled against the 1.4 libraries (client driver, dynamically loaded
nio modules, JDBC 3.0 driver), so compiling most of the engine against
FP doesn't solve that problem, unless we either
a) drop support for J2SE 1.4, or
b) include stubs for J2SE 1.4
I'm not following you. I think that we continue to claim support for
JDK1.4 if we
1) claim support for CDC/FP 1.1, which is a subset of JDK1.4
2) provide a JDBC3 driver
I'd say that if we choose to implement stubs for Foundation Profile, we
should do the same for all the class libraries we require (1.4 and 1.5)
so that only one Java version is needed on your system in order to build
Derby. (I fear though that this means that most of our code base will be
class library stubs and not database code...)
I guess we could do that. Seems like pulling more of the ball of yarn
than we need to.
What I proposed in my previous mail, might be a simpler short-term
solution, although it doesn't address the lack of compile-time
checking. But it would address the JDK 1.4 dependency, which is not
addressed by creating FP stubs. We would then do something like this in
our build scripts (perhaps in the PropertySetter ant task?):
1) set the Java 1.5 compile classpath as we do today
2) set the Java 1.4 compile classpath as we do today if Java 1.4 is
found, otherwise construct one that uses the 1.5 compile classpath
3) set the JSR 169 compile classpath as we do today (use
jsr169compile.classpath if set, otherwise construct one as
java14compile.classpath + stubs)
Something along those lines sounds promising. I would be content with a
two part solution:
I) A simple build for people who are new to the community. This builds
everything including the JSR169, JDBC3, and JDBC4 drivers. Extra credit
if all you need is the Derby source and a Java 5 compiler.
II) A straightforward way for derby-dev(elopers) to plug in other
libraries to verify at compile-time that
a) the core engine doesn't spill outside the CDC/FP limits
b) the JDBC3 driver and network server don't spill outside the JDK1.4 limits
I suspect that this means we need to supply:
i) JSR169 stubs (already done)
ii) JDBC3 stubs
iii) JDBC4 stubs
Regards,
-Rick
