Hi Niclas,
Comments below:
Niclas Hedhman wrote:
On Sun, Mar 15, 2009 at 5:40 PM, Peter Firmstone <[email protected]> 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
./working_classlib/modules/suncompat/src/main/java/sun/misc
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
replacements.
Cheers
Niclas
Cheers,
Pete.
