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 14:57:34 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> other good stuff ...
>>
>>
>>   
>>> Our current small device claims aren't based on compile-time
>>> checks. Instead, we rely on warnings raised by community members who
>>> run the tests on small platforms. If we want to continue supporting
>>> small devices, then I think that we ought to be compiling the bulk of
>>> the core engine against CDC/FP 1.1.2 libraries, not against JDK 1.4.2
>>> libraries.
>>>     
>>
>> Are you suggesting that we make the Foundation libraries a required
>> component for building Derby? I'm not sure I think we should do that, as
>> that would make it even more complicated to compile Derby. I would
>> rather say that we should should make it possible to build (most of) the
>> core engine against the Foundation libraries, and it should also be
>> possible to build it against libraries from a newer JDK. That way we
>> could make it easier for those who just want to download the source and
>> build Derby for themselves (they don't need to download many different
>> JDKs and libraries), and make it possible to get more compile-time
>> checks for those who care about that and are willing to spend more time
>> to set up their build environment (primarily active developers and those
>> who run nightly regression tests).
>>
>>   
> I agree that we don't want to make the Derby build more complicated
> for people who are new to the community. I was suggesting a
> moderate-sized chore: provide stubs for the CDC/FP api just as we do
> for the JSR169 api today.

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?

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'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...)

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)

-- 
Knut Anders

Mime
View raw message