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 <[email protected]>
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
