Andrew John Hughes wrote: > Keeping the VM interfaces in sync sounds like a good idea to me, but > keep a couple of things in mind: > > 1) A lot of VM differences between the two will be due to new methods > that just don't exist outside the generics branch e.g. > cast(), isEnum(). > You mention two of these below. Thus, you'd never get exact identical > copies without introducing lots of generic library code into > HEAD, which we simply can't do at this stage.
Sorry, I should have been more clear. What I would like to see is that the interface between the Foo and VMFoo classes doesn't contain any types that are not in HEAD. This way VMs that replace the VM* classes can use one set of VM classes for both HEAD and the generics branch. > Also, on reading the new specs. for this stuff, something > seems to apply that this run-time dropping may only be temporary (i.e. > that the idea is to ween people off non-generic code). But I'd be > really interested to hear the opinion of others on this. If seen this sentiment too, but I don't think it is realistic. It will break too much code. > > This means, for example, that in VMClass, we use Class instead of > > Class<T>. In some cases this requires additional casts in the > > corresponding class, but these casts are removed by the > > compiler so they don't affect performance or code size. > > I don't see how much this gains, as you'd never get identical VM > interfaces because the majority is new stuff. Unless you're proposing > that VMs implement this without having the stuff in the class library, > which seems a little strange. I hope it is clearer now, given that I've explained above that my angle is that my VM replaces all the VM* classes. Please let me know if it isn't. Regards, Jeroen _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
