Am Dienstag, 28. Dezember 2004 16:33 schrieb Archie Cobbs: > Jeroen Frijters wrote: > >>The goal for this file should be "the right contents assuming the > >>VM doesn't have any bugs". If the VM wants its own private > >> version, that's that particular VM's private business. But we > >> need a version that we can point to and say "if your VM is based > >> on Classpath and otherwise does everything correctly then it > >> should definitely pass all these tests". > > > > Agreed. Unfortunately this means that we have to be conservative > > and that some tests can never be part of it (the ones that depend > > on GC behavior for example). > > OK, here's a first stab at a new "mauve-classpath". This one is > surely out of date on several counts, but happens to be the one > I've been using for a long time. > > # Classpath based VM's should pass these tests, assuming > # the VM is working perfectly. > JDK1.0 > JDK1.1 > JDK1.2 > JDK1.3 > JDK1.4 > !java.beans. > !BinaryCompatibility.BinaryCompatibilityTest > !java.applet > !java.awt > !java.net.DatagramPacket. > !java.net.DatagramSocket. > !java.io.ObjectInputOutput > !java.lang.Character.unicode > !javax.imageio > !javax.naming > !java.text.RuleBasedCollator > !javax.swing > > # These tests may vary depending on VM details, so failures here > # could be false negatives. > !java.lang.ref.WeakReference.weakref > !java.lang.ref.PhantomReference.phantom > > Let me know what changes we should make. I'll keep track, and let's > try to come to an agreed-upon master file.
Not that some tests in java.awt.color/image depend on the JVM too as they depend on a proper floating point implementation. I really wonder how much people will use this files. Most people using mauve use ./batch_run and this does not use classpath-mauve or xfail files. Michael -- Homepage: http://www.worldforge.org/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
