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:19:31 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> writes:

> Bryan Pendleton wrote:
>>> 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
>> Perhaps we are trying to force the build to do too much?
>> Would it be easier to verify this via testing, than at build time?
>> For example:
>>  - to verify that we are compatible with JDK 1.4, we should test
>> under 1.4
>>  - to verify that we are compatible with JDBC 3.0, we should test
>>    under JDBC 3.0
>>  - to verify that we work in a CDC/FP environment, we should
>>    test in a CDC/FP environment
>> I have no idea whether this actually makes things simpler or
>> harder, just wanted to toss this out there to see if it was useful.
>> thanks,
>> bryan
> I don't think this would be a step backward for CDC/FP support. We
> rely on test-time checks for our claims about small device
> support. For our JDK1.4 claims, I think that we already provide
> support for plugging in the JDK1.4 libraries so that we verify that
> support at compile-time. The incremental work here would be a little
> tweaking to make the build use the small device libraries (rather than
> the JDK1.4 libraries) when building the core engine and network
> server. I'm guessing that this is just a little tweaking but the devil
> could be in the details.

Another point is that we can't guarantee by testing alone that no JDK 5
methods have been used, thereby breaking the JDK 1.4 support, unless we
have 100% test coverage. Compile-time checks would also discover
problems in code paths that are not exercised by the tests.

Knut Anders

View raw message