RE: RFC: Generics branch VM interface

[Andrew John Hughes]

On Fri, 2005-06-17 at 08:51 +0200, Jeroen Frijters wrote:
> 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.
> 

Yes, that does make more sense and I did start to get the feeling that
might have been your point about halfway through writing the last mail!

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

Yes, its a unfortunate situation and not exactly a new one.  There's
always a limit on holding on to backwards compatibility when introducing
something new.  My current feeling, however, is that the current
restrictions do make the new parametric types more complicated than they
need to be.  For example, you can't do a run-time type check because
these types don't exist then.  You then get odd situations where the
solution to one warning or error causes another different warning.  The
casts you suggest are examples of this; without a cast, you get an error
but with you then have the problem that the cast will work with the raw
type instead.

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

Yes, it does make sense and clearly it means VMs can start to have
support for the new methods without having to break compatibility with
HEAD.

> Regards,
> Jeroen
> 
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

signature.asc
Description: This is a digitally signed message part