RE: [cp-patches] [generics] RFC: VM interface changes

[Andrew John Hughes]

On Sun, 2005-06-19 at 10:12 +0200, Jeroen Frijters wrote:
> Andrew John Hughes wrote:
> > On Fri, 2005-06-17 at 15:29 +0200, Jeroen Frijters wrote:
> > > Hi,
> > > 
> > > Here is the first part of my proposed VM interface changes 
> > to make the
> > > VM interface more compatible with HEAD.
> > 
> > Two main comments, the rest is pretty much what I expected:
> > 
> > * If you change the environ() return type, then please change it to an
> > array as you suggested, so it becomes more type-safe.
> 
> I was too lazy to rewrite the native code, so I backed out that change
> for the time being. I also didn't know how to deal with the character
> set conversion stuff (the current code uses NewStringUTF, that doesn't
> look right to me). IKVM doesn't use the native code, so I don't know
> much about Classpath's native code.
> 

Yeah, as I say there's also a problem that using an array means that the
native code (which uses the environ char* array) has to run over the
structure twice, once for size and once to move it to the array.  I
can't see any function that returns the number of environment variables.

As to the strings, I've tested it but my environment variables are pure
ASCII anyway, so there may be a problem there.

> > The cast to List<String> is pointless as it will check against
> > List anyway at run-time.
> 
> It isn't pointless, it allowed me to continue to use the "for (String s
> : list)" construct, but I do understand that it doesn't actually do
> anything.
> 
Yes, I meant pointless at run-time i.e. it becomes:

List<String> environ = (List) VMSystem.environ();

I do understand why you need it for the compiler, of course.  Still not
actually sure whether we should just keep this or switch to an array.

> > * The stubs seem to lose something.  Whereas before the type signature
> > handling may have been implemented by the VM, now it will always throw
> > an error even if the VM complies.  I'm okay if this is only a 
> > short-term fix; I just don't like the idea of introducing such a stub
> > for any noticeable length of time (i.e. the next thing should be to
> > implement this).  There are already lots of places in the code where
> > this is the case, and we don't really want more.
> 
> I totally agree. In this case I wanted to change the interface early on,
> to express the intent to share the signature parsing code in Classpath,
> instead of having different VMs go off and duplicate this effort.
> 
I think I was saying that just because I thought I had to! I agree with
your reasoning there.  If you want to commit this, then one of us (or
anyone else who wants to) can take a look at adding that functionality.

> Regards,
> Jeroen
> 

Thanks,
It's nice to have someone else looking at this stuff ;)
-- 
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