I have a fairly simple program which does this Reflection thing you're
talking about.  I've caught a few errors in my code already from doing that.
I'll clean it up and check it in sometime before we release so that we can
check things.
    javap is inadequate for the comparison of this stuff, since it does not
output exceptions thrown from a method.  And the different versions thing is
a good point, as well.
    The best thing is what you are describing.  Distribute the output from
running this program on Sun's JDK, and compare the output to running it on
the classpath.jar file after it has been built at the client.
--John Keiser

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Stuart Ballard
> Sent: Saturday, October 03, 1998 11:58 AM
> To: Paul Fisher; [EMAIL PROTECTED]
> Subject: Re: Compatibility testing
>
>
> Paul Fisher wrote:
> >
> > Stuart Ballard <[EMAIL PROTECTED]> writes:
> >
> > > The same thing could maybe even be achieved with javap and some
> > > clever grepping and sedding.
> >
> > I wouldn't do this -- unless you're talking about using javap on
> > Classpath files.  It would be better to write a test which compares
> > Sun's javadoc output to our classes and methods.  If I remember
> > correctly, downloading the javadocs does not require one to enter into
> > a license agreement with Sun (unlike downloading the JDK).
>
> I was thinking more like distributing the database that we have to
> match, and then testing against that. For example, say we write a
> program (or a script using javap) called dumpsigs, which outputs every
> public and protected class and member signature in the java.* hierarchy.
> Someone on the classpath team runs dumpsigs on JDK and puts the results
> in the source tree. Then the testsuite runs dumpsigs on classpath and
> compares the two outputs.
>
> Admittedly, it requires someone to have the JDK, but I wouldn't say that
> using Reflection on the public and protected members of the java.*
> classes is really violating the clean room. Even more so if you use
> javap, but then you get problems if the output of javap changes between
> versions of the JDK - a program written by ourselves could be designed
> to work on every version from 1.1.0 through 2.0 and beyond. This would
> also be a problem with using the javadoc, as I don't see any automatic
> script that we could write now being able to handle even the output of
> 1.2FCS.
>
> Stuart.
>
>

Reply via email to