>>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> /usr/bin/gcj -C -d . @classes Mark> ./../java/security/BasicPermission.java:64: Class Mark> `java.security.BasicPermission' can't subclass interface Mark> `java.security.acl.Permission'. Mark> public abstract class BasicPermission extends Permission implements Mark> ^ Mark> The released version of gcj (3.0.3) does not have this strange bug. Mark> Changing Permission to java.security.Permission solves it. You'll have to work around it. 3.0.4 is perhaps the last of the 3.0 releases (hard to be certain). 3.1 is due in April. The gcj hackers aren't really fixing bugs in 3.0 at all any more; I have that tree checked out for reference but I haven't built it in many months. For problems like this, where the fix is something we wouldn't write from scratch and is just a workaround for a current compiler problem, I would prefer that we only have the fix in this particular Classpath release. So the idea would be that we make a release branch and then add the workarounds there. My idea here is that in the long term we'd prefer the existing code, as it is "more natural", and perhaps by the time the next Classpath release comes around we won't have to worry about this particular compiler any more. What do you think? Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
