db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: JDK 1.4 support
Date Wed, 03 Dec 2008 19:53:27 GMT
Rick Hillegas wrote:
> 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
> 
> 
It is likely if such an approach were taken, that the builds used to 
produce the tests results published at the derby public site from ibm 
would continue to use a jdk14 jvm to do the build. So it would be good 
to make it easy to configure the build to continue to use 1.4 after 
whatever changes in this area is implemented.  These are publicly
available at:
http://db.apache.org/derby/derby_tests.html
under the IBM Regression Test Results link


  I also believe it useful
to continue 1.4 support such that the small device jvm's can be 
supported.  But agree that it would be useful going forward to allow new 
developers to work with jdk15, but provide as quick feedback as possible 
if they use 1.5 specific features that would break 1.4 derby support.

If no implements the stub approach it may be useful to require patches 
to be tagged against which jvm they have been compiled against, to give
a heads up to committers to check against 1.4 or not:
http://people.apache.org/~myrnavl/derby_test_results/

Mime
View raw message