Mark Wielaard wrote:
>
> Hi,
>
> On Mon, Jun 12, 2000 at 12:19:37PM -0400, Stuart Ballard wrote:
> > <shameless plug>
> > See also my recent post; if my japicompat tool is legal for Classpath to
> > use, it would be a good way to make sure that we cover all of 1.1.
>
> There is a nice idea. Since you are at the FSF lab (what does that look like?)
> you seem to be in the right position to get in contact with people that can
> decide if the Classpath project can use the japicompat tool. I guess it is
> perfectly legal to use the java reflection api to see if our version of a
> class implementation is binary compatible with another version.
That's my guess too... or I wouldn't have written the tool :) But I
don't want to place the classpath project in legal jeopardy over
something that's just a guess...
> The normal Classpath policy is to use only publicly available documentation
> to develop our classes.
I think it's also permitted to run a "black-box" test (I had to do this
with the Collections API sort functions to see how they handled NaN - it
turned out they didn't handle it at all :) ). It's hard to see that
there's much of a difference between testing the behavior of a sort
function for given arguments and testing the results of the Reflection
API for given classes, but who knows?
> And using the reflection api might be considered
> the same as reverse engineering. Although I thought that reverse engineering
> is legal if used for compatability reasons. We also could ask someone in
> a country that permits such reverse engineering to run the tool and publish
> the results on a web site.
I believe reverse engineering is legitimate, period, unless you buy the
click-wrap licensing on the JDK. I'm more concerned with whether I'm
overstepping the bounds of "reverse engineering"... where does the line
get drawn between this and disassembling the bytecode and mechanically
constructing Java sourcecode from that?
Stuart.
