db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: JDK 1.4 support
Date Tue, 02 Dec 2008 17:14:45 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> 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

Right. But I guess we won't be able to compile the JDBC 3.0 driver or
the client driver against CDC/FP/JSR-169, because JSR-169 lacks classes
like DriverManager and XADataSource. And the nio modules in store would
also not compile because of the lack of java.nio.* in FP 1.1.

So we'd either need JDK 1.4 libraries or compile against newer libraries
(JDK 5) in order to produce a JDBC 3.0 driver that runs on JDK 1.4. If
we choose the former, we'd either need to continue having JDK 1.4 as a
build-time requirement or provide stubs. If we choose the latter, our
build would not guarantee that we haven't introduced calls to methods
that don't exist in JDK 1.4.

My point was that if we can't claim support for FP 1.1 because we don't
have full compile-time checking, we'd have the same problem claiming JDK
1.4 support if we remove the build-time requirement for 1.4.

>> 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

Agreed. This sounds like what we should be aiming for.

> I suspect that this means we need to supply:
> i) JSR169 stubs (already done)
> ii) JDBC3 stubs
> iii) JDBC4 stubs

Knut Anders

View raw message