[Top][All Lists]

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

Re: API clean up patch

From: Archie Cobbs
Subject: Re: API clean up patch
Date: Wed, 18 May 2005 09:41:31 -0500
User-agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129

David Holmes wrote:
Who wants a VM that's incapable of generating stack traces??

Probably noone, but I'd love to be able to NOT have the stacktrace always
filled in automatically upon construction.

OK.. though that seems like an orthogonal issue. VM implementors are
welcome to change the API of course.

Just to reiterate: I'm not trying to decide what the API should be.
I'm just trying to pick one that isn't inherently inconsistent and
broken a priori and doesn't *require* the VM implementor to change it.

Summary of changes:

  - Add a "vmdata" field to ClassLoader, VMThread, and VMThrowable.
    Seems to me that every VM will require these (am I wrong?)

Did you mean ClassLoader or VMClassLoader?

ClassLoader. AFAICT, VMClassLoader is never instantiated, so there's
no point in adding instance fields to it.

While every VM may need VM specific data fields I don't see how adding these
really helps because you can't know how the VM needs to use them.

OK.. but does it really hurt either? At least with the new field added,
a VM has a remote chance of being able to use this class unmodified.

On the other hand, can you show me a VM that doesn't modify this class
but properly supports user-defined class loaders? I can't imagine how,
because the VM is required to keep internal state associated with all
class loaders that define classes.

  - Constructor.getParameterTypes() and getExceptionTypes() become
    native methods, to align with and, and
    because nowhere is the code that sets these fields anyway.

Shouldn't there be VMConstructor, VMField, and VMMethod  classes that are
deferred to rather than making these native? Or is the expectation that a VM
will have to modify these classes regardless? (I don't think there is much
VM independent code that can really go in these classes, so expecting the VM
to modify Constructor et al directly is not unreasonable.

That's a different question from the one I'm trying to address, which
is simply to make the API self-consistent.

However, it would be fine by me if someone wanted to move the native
methods into VMFoo classes.


Archie Cobbs      *        CTO, Awarix        *

reply via email to

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