You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2009/03/15 10:40:39 UTC
RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
There's a great site up at www.lumentier.com that allows traversal of
the jdk-7 source tree.
Check out this link:
http://www.lumentier.com/java/ext/jdk-7-bld1/sun.tools.javac/SourceClass/class-source.lmtr
The tools source files are listed under the sun.tools classpath in the
navigation tree.
I've noticed that the tools classes that River relies on are marked
@Depreciated, and include a warning:
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.
The code is covered under the GPLv2 with class path exception, the
availability of source makes it easy to traverse the dependencies back
to the main jdk source tree.
So I'm wondering, is it possible to start by adding this library as a
separate lib tree to River, under the GPLv2 license with classpath
exception and begin by stripping all un-necessary functionality. The
tools code also includes imports from forbidden packages from the main
jdk source tree, we could then look at how replacing that code
functionality might be achieved.
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?
Cheers,
Peter Firmstone.
Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <ji...@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
>>
>
Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <ji...@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
>
Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Mar 16, 2009 at 1:25 PM, Peter Firmstone <ji...@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
--
http://www.qi4j.org - New Energy for Java
Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Niclas,
Comments below:
Niclas Hedhman wrote:
> On Sun, Mar 15, 2009 at 5:40 PM, Peter Firmstone <ji...@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
./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.
Re: RIVER-272 ClassDep.java relies on Sun specific Internal JDK API
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sun, Mar 15, 2009 at 5:40 PM, Peter Firmstone <ji...@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 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.
> 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.
Cheers
Niclas
--
http://www.qi4j.org - New Energy for Java