Is this approach Valid

[Andrew Haley]

Adam Young writes:
 > Hi, I'm the guys that joined recently and claimed he would implement 
 > the javax.security.auth packages.  As I've dug through the volumes of 
 > info, the public Java docs, and the messages about what was or wasn't a 
 > good way to approach coding I've come up with a plan.  Before I go down 
 > this path, I'd like a little validation.
 > Since I can't look at the Sun code, I'm trying to find a way to make a 
 > test that the new Classes I implement do the same thing as the 
 > original.   I've started with
 > 
 > javax.security.auth.Subject.
 > 
 > Along with this is implementations of AuthPermission and
 > SubjectDomainCombiner, all written just referring to the official
 > Javadocs and a couple books I have on Java Security.  I would like
 > to write a test ala JUnit or Mauve.  If I write this Test in
 > Eclipse, and use its automatic code generation facility to read the
 > Sun Version of the Subject class and write delegation code within a
 > class, I will at least have a comprehensive list of all the public
 > methods in the interface.  This simplifies my test to making sure
 > that all these methods work.  Is this Kosher?

It seems to me that the list of public methods in a class file is part
of its published interface, and thus is probably legit.

However, I question the need to do this.  You have online Javadocs for
all the public methods.

 > If I write a Test against the Sun implementation, and then rewrite my 
 > implementation until that Test runs,  should this test then be added to 
 > Mauve?

Yes.  But please don't simply assume that Sun's implementation is
correct: we code to the specification. not the implementation.

 > Has anyone used the Mauve framework to write unit test other than for 
 > Classpath?  Is there a Test framework portion of the code separate from 
 > the Testlets defined for testing Classpath?

I don't understand this question.  Mauve works with any Java library.

Andrew.