Re: Getting Mauve running with Classpath+gcj/jikes+kissme
Hi, On Thu, 2002-10-10 at 23:13, Mark Wielaard wrote: - Add the attached file mauve-kissme to the mauve directory. (This tells the build which tests should/shouldn't be compiled/run.) [...] At the moment you will get the following results: 158 of 6276 tests failed (Some of these are known failures, some still have to be investigated.) Small update. I cleaned up some Mauve tests and it is now possible to use this shorter mauve-kissme file (attached). New results (i686-pc-linux-gnu): 160 of 6375 tests failed Kissme on Powerpc also works fairly well, except for native functions that use doubles as arguments. Cheers, Mark # Config file that tells mauve about the `kissme' tag. JDK1.0 JDK1.1 JDK1.2 JDK1.3 JDK1.4 JLS1.0 JLS1.1 JLS1.2 JDBC1.0 JDBC2.0 # Character.unicode seems to be very broken (the test) # Does not give meaningfull test results at the moment. !java.lang.Character.unicode # These are almost certainly buggy test cases. # The behaviour of the garbarge collector cannot be predicted. # Note the dot at the end, so we still test java.lang.reflect. !java.lang.ref. # Strange behaviour (crash or hang) !java.io.ObjectInputOutput !java.lang.reflect.Array.newInstance # Crashes when compiled with gcj !java.lang.Math.min # Not yet in GNU Classpath !javax.naming.*
serialVersionUID (again)
Hi, There was a small discussion on [EMAIL PROTECTED] (between Warren Levy, Tom Tromey, Michael Koch, Eric Blake and myself) when some of the newly added serialVersionUID fixes made by Michael were merged into libgcj. Since I assume not everybody reads that list I give the summary here (I hope one of the above people will correct me when I make a wrong conclusion). The specification for computing a Stream Unique Identifier (serialVersionUID) when it is not declared in a class is given here: http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/class.doc6.html This algorithm is implemented in java.io.ObjectStreamClass and for a Serializable class you can get the serialVersionUID by calling: ObjectStreamClass.lookup(Class).getSerialVersionUID() Warren Levy has made sure that our implementation gets all the corner cases right (or at least does the same as the Sun version) and that gcj generates class files that contain as much as possible the same method names as the Sun javac compiler does. So the rule for libgcj was: If the serialVersionUID is different from that calculated by the SUN JDK, then figure out _why_ it's different and fix either the compiler, or the class method names, or the ObjectStreamClass implementation and only if all that fails add a serialVersionUID and make sure to add a comment why it is necessary. But when we recently discussed the issue on this list (and as pointed out again by Eric Blake in the above discussion) the synthetic method names generated by different java bytecode compilers for e.g. inner classes access to private variables of their outer class or to implement the SomeClass.class construct are note the same. (Eric gives a nice example in the following email: http://gcc.gnu.org/ml/java-patches/2002-q4/msg00036.html.) And we currently use either jikes or GNU gcj to compile GNU Classpath which don't generate the same accessor method names. What I don't understand is why it is so hard to specify the actual accessor methods. Does anybody know why they were never clearly specified? If both Tom Tromey and Eric Blake say that although theoretical possible, it is too difficult for us to ensure compatibility in the free compilers with the proprietary Sun javac naming scheme and other synthetic stuff I think that are current policy (always add serialVersionUID if the class is Serializable) is a good one. What do others think? Should we try to reverse engineer the naming scheme? Or do we keep the current policy? Or we could even ignore being serializable compatible with the Sun JDK till this is clearly specified. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: serialVersionUID (again)
Your summary seemed good to me. Mark Wielaard wrote: What I don't understand is why it is so hard to specify the actual accessor methods. Does anybody know why they were never clearly specified? Partly because it was a hack added in JDK 1.1. To maintain the most possible backward compatibility with 1.0, the whitepaper spec for adding inner classes gave recommendations for things like this$0 for the enclosing class, Outerclass$num for anonymous classes, class$(String) as the method to compute class literals, access$num() for accessors, and val$i for accessing a final local variable in a local class. But none of these were set in stone, in an attempt to avoid polluting the user's namespace. Only one naming scheme was required, rather than recommended - and that was that member classes (such as Outer.Inner) be given the name Outer$Inner, because it affects how a compiler finds inner classes when referenced from other .java files. Likewise, the specification requires that non-private constructors of non-static member classes have an additional first parameter for the enclosing class (but parameter names are not specified). All other compiler-generated names are local to a .java file, so the name chosen really doesn't matter. In the 2nd edition JLS, this scheme was maintained - chapter 13 of the JLS specifies ONLY the naming scheme of member classes, and leaves everything else to the compiler. It is up to the compiler to avoid name clashes with the user's code, and JLS2 does not prohibit a user from naming things in his class with names that would clash with the whitepaper suggested names. (In my opinion, the choice of keeping '$' as a legal user identifier character is deplorable - if Sun had truly wanted to keep compiler names and user names separate, they should have given the compiler a unique character or namespace for naming synthetic constructs). If both Tom Tromey and Eric Blake say that although theoretical possible, it is too difficult for us to ensure compatibility in the free compilers with the proprietary Sun javac naming scheme and other synthetic stuff I think that are current policy (always add serialVersionUID if the class is Serializable) is a good one. What do others think? Should we try to reverse engineer the naming scheme? Or do we keep the current policy? Or we could even ignore being serializable compatible with the Sun JDK till this is clearly specified. I don't think it ever will be clearly specified what accessor methods must be named - I think it is up to the compiler to choose its naming scheme. And, if I am correct about compiling the Foo.class literal, jikes will never compile serial versions compatibly with javac, because jikes relies on class$(String, boolean) to avoid initializing the class, whereas javac is still using class$(String) and incorrectly initializing classes when evaluating the .class literal. So I am okay with the proposal to always add a serialVersionUID to all Classpath files (with libgcj, I'm not as sure that it is necessary, except for the hassle of maintaining two sources). But I may be a bit biased, so I look forward to other's views on the matter. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
