This is the mail archive of the mauve-discuss@sourceware.cygnus.com mailing list for the Mauve project. See the Mauve home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Project Mauve: A Free Java Regression Test and Compatibility Package



> 
> I'm afraid I don't understand either of these objections.
> 
> What is it about this approach that makes it impossible to test JNI
> compatibility?
> 

 I meant to test C programs that make use of the particular engine's JNI
interfaces.

> For the second point: are you concerned about testing for exceptions
> thrown in `main' in particular?  Or do you want to be able to test
> constructors that cause ExceptionInInitializerError to be thrown?  You
> can certainly test the latter; you just need two classes.

Here's an example:  can your testing framework handle this test?

/*
 * Try a join before main().
 */
public class JoinBeforeMain implements Runnable {
    public void run() {
        System.out.println("in run");
    }

    static {
        System.out.println("static init");
        JoinBeforeMain jbm = new JoinBeforeMain();

        Thread t = new Thread(jbm);
        t.start();
        try {
            t.join();
        } catch (Exception _) { System.out.println("caught " + _); }
    }

    public static void main(String av[]) {
    }
}

For instance, Sun 1.1.3 would deadlock on this one, 1.1.6 would
produce correct output.

> 
> I guess that's too bad.  I personally don't like it, but there it is
> anyway.  Some of the untestable things really approach being tests of
> the runtime and not the library per se.  I don't know if these really
> fall within mauve's remit.

That's what my concern was:  the testing requirements for the runtime
and for the library are different, at least potentially.
What I'd like is something that could do both.

However, something that only tests the libraries would be useful too,
of course.

> Godmar> It would also be nice if it didn't require anything but
> Godmar> /bin/sh to run.
> 
> I believe we currently require GNU make, sh, a Java runtime, and a
> Java compiler.  It would probably be possible to get rid of the GNU
> make dependency.  I'm not particularly motivated to do it.

GNU make, I think, is not ideal, but tolerable.  
I was just concerned developers would have to have guile or a particular
version of perl or something like that.

	- Godmar