RE: hasClassInitializer and exception
Mark Wielaard wrote: On Thu, 2005-07-21 at 11:59 -0500, Archie Cobbs wrote: Nicolas Geoffray wrote: there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. How about this: add this line to ObjectStreamClass before calling VMObjectStreamClass.hasClassInitializer to force class initializationahead of time: Class.forName(cl.getName(), true, cl.getClassLoader()); Then we'll know that any exception thrown in the JNI code is not an initializer exception. That, or we actually throw the exception, instead of clearing it in the jni code when it isn't a NoSuchMethodException. This is a bit of a corner case though. We only use hasClassInitializer() when we have to calculate the serialVersionUID by hand. Which means we actually are going to create an object for this class. Which will fail anyway since the class cannot be initialized... This seems like the sensible thing to do. The question is whether or not we are throwing the right exception at the right place. I haven't looked closely at the code yet Can someone come up with a nice (or probably contrived) testcase for this? See attached. Sun throws a NoClassDefFoundError on serialization and the expected exception (i.e. either the Error or ExceptionInInitializerError) on deserialization. Both exceptions are throws from ObjectStreamClass.getSerialVersionUID(). Regards, Jeroen ser.java Description: ser.java ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: hasClassInitializer and exception
Hi, On Fri, 2005-07-22 at 08:28 +0200, Jeroen Frijters wrote: The question is whether or not we are throwing the right exception at the right place. I haven't looked closely at the code yet Can someone come up with a nice (or probably contrived) testcase for this? See attached. Sun throws a NoClassDefFoundError on serialization and the expected exception (i.e. either the Error or ExceptionInInitializerError) on deserialization. Both exceptions are throws from ObjectStreamClass.getSerialVersionUID(). Thanks. I turned this into some mauve tests. See gnu/testlet/java/io/Serializable/BreakMe. It seems we already have the correct behavior since all these tests PASS. Or I implemented the tests wrong of course. Please check. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: hasClassInitializer and exception
Mark Wielaard wrote: Thanks. I turned this into some mauve tests. See gnu/testlet/java/io/Serializable/BreakMe. It seems we already have the correct behavior since all these tests PASS. Or I implemented the tests wrong of course. Please check. Thanks! The tests look correct to me and BreakMeTestSer correctly demonstrated that IKVM didn't throw the NoClassDefFoundError. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
hasClassInitializer and exception
Hey everyone, there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. I have no patch to propose to you, but what i did (as a vm implementor) is reimplementing the VMObjectStreamClass.hasClassInitializer function, which now does the search without cliniting the class (so it doesn't use jni directly anymore). Am I right? Nicolas ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: hasClassInitializer and exception
Nicolas Geoffray wrote: there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. How about this: add this line to ObjectStreamClass before calling VMObjectStreamClass.hasClassInitializer to force class initialization ahead of time: Class.forName(cl.getName(), true, cl.getClassLoader()); Then we'll know that any exception thrown in the JNI code is not an initializer exception. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: hasClassInitializer and exception
Hi, On Thu, 2005-07-21 at 11:59 -0500, Archie Cobbs wrote: Nicolas Geoffray wrote: there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. How about this: add this line to ObjectStreamClass before calling VMObjectStreamClass.hasClassInitializer to force class initialization ahead of time: Class.forName(cl.getName(), true, cl.getClassLoader()); Then we'll know that any exception thrown in the JNI code is not an initializer exception. That, or we actually throw the exception, instead of clearing it in the jni code when it isn't a NoSuchMethodException. This is a bit of a corner case though. We only use hasClassInitializer() when we have to calculate the serialVersionUID by hand. Which means we actually are going to create an object for this class. Which will fail anyway since the class cannot be initialized... The question is whether or not we are throwing the right exception at the right place. I haven't looked closely at the code yet Can someone come up with a nice (or probably contrived) testcase for this? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
