----- 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