On Sun, 15 Aug 2004 12:07:48 +0200, Mark Wielaard <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, 2004-08-12 at 19:18, Tom Tromey wrote: > > I notice that VMClassLoader still has this: > > > > * <strong>For backward compatibility, this just ignores the protection > > * domain; that is the wrong behavior, and you should directly implement > > * this method natively if you can.</strong> > > > > I suggest we pick a flag day to switch this. In particular I think we > > ought to simply remove the old form of defineClass() and only have the > > form that accepts a ProtectionDomain. > > I agree. And a since the old form of defineClass() isn't even used from > the rest of GNU Claspath I think we can remove it immediatly. Runtimes > will probably have provided their own VMClassLoader implementation > already. >
Hi All, FYI, JamVM implements the version with the ProtectionDomain natively, as suggested in the comments. I also implement getPrimitiveClass natively with a type char, rather than relying on the Java method that converts it to a string (e.g. D->double). This method is also marked as destined to be removed. Would it be a good idea to tidy up both at the same time? Of course, the class would still need modifications by the runtime because loadClass/getResource, etc. are stubs which must be implemented. Rob. P.S. I'm going by the Classpath-0.10 release snapshot, and not CVS. > If nobody objects I want to commit the attached patch next week. > > 2004-08-14 Mark Wielaard <[EMAIL PROTECTED]> > > * vm/reference/java/lang/VMClassLoader.java (defineClass): Removed > version that didn't take a ProtectionDomain. > > Cheers, > > Mark _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
