Hi Jeroen, On Thu, 2005-07-28 at 10:52 +0200, Jeroen Frijters wrote: > I agree that the call to registerInitiatingLoader() in > ClassLoader.defineClass() is a bit iffy. The reason I left it in there > is to not break any VMs when I check in this patch. I was a bit > surprised by the fact that two people complained that JamVM broke with > cvs head after my changes (I wasn't surprised that it broke, but I was > surprised that people actually ran into this without knowing how to > solve it). So I tried to be more careful with this change.
To be honest I was also a bit surprised. Since in this case the change was so small and obvious. I am afraid there is not much we can do to make that experience better if the change to the runtime is readily available. And it was not like people were completely locked out from doing any work for more then a few hours since the solution was posted quickly when people asked for it (and I told several people on irc how to add the one line and made them happy I hope). But for a larger change like this it is probably good to get a sign-off by Robert, Stephen, Archie or any other runtime implementor who you know uses pristine Class/ClassLoader classes from GNU Classpath to make sure they agree that they will keep on using them. Or hear from people like Tom, David or Dalibor that the new interfaces will make it easier for them to adopt the GNU Classpath versions. If you have one or two runtime developers with you that say that the change is good and they can/will provide it soon (or at least by the time we do a new snapshot release) then I don't really see a problem checking changes in. We do have to make breaking changes from time to time and people cannot really expect non-released versions to work flawlessly all the time (otherwise we would do a release every day!). > It is already possible to keep the table completely in the VM (in fact, > this is what IKVM does), but you cannot get rid of the call in > Class.forName() because the VM is not involved in that process. It looks like that is also what gcj and jamvm do already. That is why I am surprised that we really need the double callbacks everywhere. Does that make the interface really more flexible? In the case of Class.forName() you mean that when we need to delegate to ClassLoader.loadClass() we need to register the initial class loader explicitly because that class loader could load the class through delegation to one of its parents? Even though there is that one exception I would make the VMClass.loadClass(), VMClass.loadArrayClass() and VMClassLoader.defineClass() (reference) methods do the registration themselves. That seems to me to make some things easier for the runtime implementers that already do these things internally. But since I don't actually implement a runtime myself maybe I am just imagining things. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
