river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Date Mon, 16 Mar 2009 12:31:55 GMT
I thought I'd do it for the exercise,  backporting a subset of the tool 
library to jdk 1.4, just finished and compiled it.  No methods stripped 
out yet though, just unneccessary class files and changing foreach loops 
to for and StringBuilers to StringBuffer etc... and commenting out 
annotations.

Let me know if your interested in the code.

Cheers,

Peter.

Peter Firmstone wrote:
> Ok, no worries, it just had a priority of major on JIRA, so I thought 
> I'd have a crack at it, perhaps it should be changed to minor, next 
> version?  I was starting to get my head around the problem, it didn't 
> seem too difficult to solve.
>
> Any suggestions where a newbie might start?  I picked that one because 
> ClassDep.java is relatively independent of other River code.
>
> Cheers,
>
> Peter.
>
> Niclas Hedhman wrote:
>> On Mon, Mar 16, 2009 at 1:25 PM, Peter Firmstone <jini@zeus.net.au> 
>> wrote:
>>
>>  
>>> Niclas Hedhman wrote:
>>>    
>>>> The JDK/JRE itself is not a dependency of the River project, but a
>>>> system requirement.
>>>>
>>>>       
>>> The tools library ships with the JDK, but not the JRE.  The tools 
>>> library,
>>> uses parts of other sun libraries that ship with the JRE but are not 
>>> part of
>>> the public API (eg imports: sun.net.www.MessageHeader,
>>> sun.misc.BASE64Encoder, sun.security.pkcs.* in
>>> sun.tools.jar.SignatureFile.java) , are forbidden and not part of 
>>> the public
>>> JRE API.
>>>     
>>
>> I think you missed my point. It is OK for a project to list (for
>> instance)  "Sun's JDK" as a "System Requirement" without coming into
>> the legal discussion around "Dependencies". "Forbidden" is too strong
>> a word, I think. "Strongly discouraged" would probably be better, and
>> we are on thin ice using it, agree.
>>
>> So, for the "short term", I don't see a problem, even if the classes
>> leads to GPL'd code. We don't depend on it...
>>
>> And for the long-term (especially if/when moving beyond JDK1.4), I
>> totally support the idea of getting rid of it.
>>
>>
>> Cheers
>> Niclas
>>   
>


Mime
View raw message