classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Generics branch VM interface


From: Andrew John Hughes
Subject: Re: RFC: Generics branch VM interface
Date: Tue, 13 Sep 2005 20:49:58 +0100
User-agent: Mutt/1.5.9i

On Thu, Jun 16, 2005 at 12:08:18PM +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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> Any thoughts?
> 
> Regards,
> Jeroen
> 

Has there been any movement on this?  I haven't seen any of it being applied to 
the branch.

Cheers,
-- 
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 { ... }

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]