Re: API clean up patch

[Archie Cobbs]

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 Field.java and Method.java, 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.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com