On 04/25/2012 02:07 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi. >> >> Attached is a patch that enables GNU Classpath to distinguish between >> normal assertions and assertions for system classes (i.e. null >> classloader) as discussed on the Classpath mailing list [1]. >> >> Note that the new method >> 'java/lang/VMClassLoader.getSystemAssertionStatus()' must be >> implemented >> otherwise an exception will occur. >> > > I'm confused about something in this patch which perhaps you can explain. > > I was under the impression that all system classes had assertions enabled > and disabled as 'system assertions' (-esa/-dsa). So I was expecting > the patch to just return this value if the classloader was null. Why does > it instead retrieve a system classloader and probe that on a per-package/class > basis? How would these values be set? > > As quoted before, the Oracle documentation explicitly states that -ea does > not turn on system assertions. This patch would imply that e.g. assertions > for java.lang could be turned on by -ea:java.lang. Is this intentional?
As far as I understood the documentation (in my case http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#enable-disable as a reference) it is true that '-ea' (no argument) only applies to normal classes. The flag '-ea:*' does apply all classes: "The above switches apply to all class loaders. With one exception, they also apply to system classes (which do not have an explicit class loader). The exception concerns the switches with no arguments, which (as indicated above) do not apply to system classes." Did I miss anything? > > On the administrative side, AFAICS you haven't contributed before. Do you > have > a copyright assignment with the FSF? > >> josef >> >> [1]: >> http://developer.classpath.org/pipermail/classpath/2012-April/003195.html >> >> 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. >> >> > > Thanks,
