Re: RFC: Generics branch VM interface

[Andrew John Hughes]

On Thu, 2005-06-16 at 12:08 +0200, Jeroen Frijters wrote:
> Hi,
> 
> I'd like to propose a fundamental change to the VM interface on the
> generics branch. In particular, I'd like the VM interface (and in this
> case I mean strictly the interface between the Foo and VMFoo classes) on
> the generics branch to be compatible with the main branch. That way a VM
> can use the same VM interface code for both branches.
> 

The VM changes on the generics branch are something I've been thinking
about myself.  In particular, I'm currently in the process of updating
the VM docs so that the new generics branch changes can be added
(something which is taking longer than I thought, due to the fact that
these seem to have been really left to die).

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.

2) I'm not sure of the benefit of dropping the type signatures, but I'm
still a bit naive as to how this works natively (I'm assuming they just
disappear, given that they only exist as optional class file sections at
run-time).  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.  

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

> Another example is that VMSystem.environ() would return a String[][]
> instead of a List<String> (as an aside, IMO, it's always better to use
> built-in types across the VM interface, e.g. manipulating an array in
> JNI is easier and more efficient than manipulating a List).
> 

Feel free to change this if you think an array works better. FWIW, I
don't think there is much difference between the two in JNI for this
because it's really just a conduit for the native information (you'd
have to do much the same to fill an array).  The stuff is split and
transformed into a map by Java code.  Note that this doesn't exist on
HEAD anyway, as it relates to System.getenv(), a 1.5 method.

> Another, possibly more contentious, case is VMClass.getTypeParameters(),
> this currently returns a TypeVariable<Class<T>>[], but I wonder if it
> wouldn't be better to simply return a string and do the signature
> decoding (which presumably is common to all VMs) in
> java/lang/Class.java.
> 

A lot of the recent additions are naive first-shot attempts; there's
definitely room for improvement and simplification.  This is part of my
reasoning behind documenting these and getting discussion going.

> Any thoughts?
> 
> 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