db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: JDK 1.4 support
Date Tue, 02 Dec 2008 21:40:35 GMT
Kristian Waagan wrote:
> Knut Anders Hatlen wrote:
>> 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.
>>   
>
> I think a compile-time check would be best, if we are to continue 
> supporting JDK 1.4 and/or CDC/FP.
> Testing would have to be done in addition, of course.
>
> From what I read, I get the impression we're assuming everyone has to 
> compile against these libraries.
> But is that really the case?
Hi Kristian,

I think we're converging on the same goals. What I meant by (I) was what 
you are suggesting: we want a default build which works for anyone who 
just downloads the Derby source and Java 5 jdk.
> Why can't a smaller group go through the hassle of downloading the 
> extra libraries and configure the build framework accordingly?
>
> I'm suggesting that even though we support these versions in official 
> Derby releases, building Derby against the libraries could be 
> optional. The main point with this, is to allow newcomers to build 
> Derby easily by using only one JDK. This might even attract more 
> contributers.
>
> The smaller group would typically be committers, seasoned developers 
> spending a lot of time working on Derby, release managers and testers.
> The downside of such an approach is that some patches fail to compile 
> for this smaller group, because the contributer only compiled and 
> tested it with, say, JDK 5.0. In such cases the patch must be 
> declined, or even backed out if a committer committed it without 
> proper building/testing.
>
>
Right. And that's what I was trying to say by (II): we can rely on 
interested community members to configure the build so that they get 
compile-time checks for CDC/FP and JDK 1.4 support. As you note, the 
practical implications of this are that we discover build problems 
lazily and may have to back out bad patches if we discover later on that 
they break the CDC/FP or JDK1.4 contracts.

Regards,
-Rick


Mime
View raw message