----- 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. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
