On 04/24/2012 02:29 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi there. >> >> I want to reanimate a discussion from 2007 [1,2] about the >> Assertion/System Assertion handling. As far as I know GNU Classpath >> can't distinguish between normal assertions (-ea/-eanableassertions) >> and >> assertions for system classes (-esa/-enablesystemassertions, i.e. >> classes with no classloader [3]). >> The only interface for the VM is the method >> VMClassLoader.defaultAssertionStatus(). It is not clear if this is >> supposed to return the system assertion status or the normal >> assertion >> status (vm integration doc [4] vs. javadoc [5]). On the one hand, it >> is >> used to set the defaultAssertionStatus for java.lang.ClassLoader [6] >> which would imply that it is the normal assertion status. On the >> other >> hand, the very same flag is used for setting the assertion status for >> system class in java.lang.Class (desiredAssertionStatus)[7]. >> >> I think we need two dedicated methods in VMClassLoader. >> getDefaultAssertionStatus() for normal assertions (i.e. -ea) and >> getDefaultSystemAssertionStatus() for system assertions (i.e. -esa). >> ClassLoader should use VMClassLoader.getDefaultAssertionStatus() as >> its >> default value and Class.getDesiredAssertionStatus() should use >> VMClassLoader.defaultSystemAssertionStatus() for system classes. >> >> I understand that this would be a rather big change because all VMs >> using GNU Classpath will fail if they do not adopt their >> VMClassLoader >> accordingly. >> >> I want to revitalize the discussion on this topic and I'm ready to >> prepare a patch for this issue but things should be discussed first >> ;). >> >> I hope my explanations are somehow understandable ;). >> >> - josef >> >> PS: I think the patch from 2007 is does not fix this issue as it does >> not modify java.lang.Class and java.lang.Classloader receptively. >> >> >> [1]: >> http://developer.classpath.org/pipermail/classpath-patches/2007-August/005601.html >> [2]: >> http://developer.classpath.org/pipermail/classpath-patches/2007-September/005605.html >> [3]: >> http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#enable-disable >> [4]: >> http://www.gnu.org/software/classpath/docs/cp-vmintegration.html#SEC7 >> [5]: >> http://git.savannah.gnu.org/cgit/classpath.git/tree/vm/reference/java/lang/VMClassLoader.java?id=18f4bdd925d1a78d11598fb23dcaf1110772dcae#n334 >> [6]: >> http://git.savannah.gnu.org/cgit/classpath.git/tree/java/lang/ClassLoader.java?id=18f4bdd925d1a78d11598fb23dcaf1110772dcae#n220 >> [7]: >> http://git.savannah.gnu.org/cgit/classpath.git/tree/java/lang/Class.java?id=18f4bdd925d1a78d11598fb23dcaf1110772dcae#n1233 >> >> > > You're right. The issue is here: > > "But if you use them with no arguments (-ea or -da), they do not apply to system classes." > > (from http://java.sun.com/developer/technicalArticles/JavaLP/assertions/) > > Both when the classloader is null (a system class) and when there is no class or package-specific setting, the same default setting > from VMClassLoader.defaultAssertionStatus() is used. > > There should instead a separate method for system classes as you mention: VMClassLoader.getSystemAssertionStatus() > (I don't think it needs to be called default because it can't be overridden by the class/package settings). > > As we're just after a release (0.99), this would be an ideal time to add that method. fyi: I've proposed a patch for this issue on the classpath-patches mailing list. josef
