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 05:25:02 GMT
Hi Niclas,

Comments below:

Niclas Hedhman wrote:
> On Sun, Mar 15, 2009 at 5:40 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>> The tools source files are listed under the sun.tools classpath in the
>> navigation tree.
> 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.

sun.misc.Base64Encoder.java is included in Apache Harmony 5 in 

In other words it should be possible to remove the dependencies on 
externally maintained code that may break in future.  We can strip the 
code down to the bear minimum functionality required for River, this is 
opensource code that includes the classpath exception under GPLv2, so 
doesn't cause any licensing problems, this part should also then be able 
to build on Apache Harmony in theory.

Code in the sun.tools.* namespace that River is dependent on that 
doesn't ship with the JRE:
sun.tools.tree.* and sun.tools.java.*

Code in the sun.tools.* namespace that River "may" be dependent on (I 
need to follow the dependency trees properly to determine this), that 
ship with the JRE:
sun.tools.jar.* and sun.tools.util.*

Any dependents here could be added by Apache Harmony under the Sun 
Compatibility libraries "suncompat" so that River may eventually be 
build and run on Apache Harmony also.

>> The contents of this source file are not part of any
>> supported API.  Code that depends on them does so at its own risk:
>> they are subject to change or removal without notice.
> Correct. It is not an ideal situation, but considering that River is
> JDK1.4 at the moment, I think there is less need to be overly
> concerned about it. If we can't find a solution under JDK1.4, there is
> not much to do about it.
Browsing the code, there doesn't seem to be anything in the sun.tools 
packages that appear to be specific to JDK1.5 onward, this all looks 
like old code.  It'd be simple enough to download, open and compile to 
JDK1.4 or source=1.4, any errors will soon pop up.

>> If the above is not acceptable, is the alternative to document the
>> functionality supplied by the tools package interface and replace that by
>> constructing an apache licensed library?
> Finding a replacement is "good", but I wouldn't say critical at this
> point. When/If moving to JDK1.5, we could check with the Harmony
> project for ALv2 licensed parts.
I've had a look in Harmony, however I can't find any functional 

> Cheers
> Niclas


View raw message