This is the mail archive of the mauve-discuss@sourceware.org mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: legal question about writing mauve test cases


Greg Orlowski wrote:
Hi,

Is it legal to use the reflection api's w/ sun's jdks to generate
lists of method signatures and then compare them to gnu-classpath's
method signatures as a reference-point from which to develop test
cases for mauve?

I assume that you're interested in seing which classes/methods/fields are missing/bad in GNU Classpath, in order to figure out which areas to go after, you may be interested in looking at Japitools comparison results at http://www.kaffe.org/~stuart/japi/


Does using the reflection capabilities of java with sun's libraries
constitute reading source code (legally)?

No, afaict. Otoh, if you are using or writing, say, an automated test generator for libraries, the cleanest way to do it is to generate your tests against GNU Classpath sourcecode, and then to run the tests against a non-free VM, to see if the assumptions codified in GNU Classpath also exist in the non-free VM.


On a side note, CnC from http://www.cc.gatech.edu/cnc/welcome.html might be interesting for such a task.

I'd like to contribute to classpath, but I'll be using sun's tools
extensively at my job, and I'm worried that I'll be tainted by doing
so.

Afaik, using Sun's tools does not taint you, since you don't get to see actual implementation details by just using java/javac. Looking at the sources or having a NDA/contract with Sun not to disclose their implementation details otoh, would prevent you from contributing respective souce code to GNU Classpath. In that case, there are still other areas one can contribute to.


cheers,
dalibor topic


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]