Re: VMThrowable.java

[Archie Cobbs]

Mark Wielaard wrote:
> > Howver, the java.lang.VMThrowable class doesn't seem to follow this rule,
> > because fillInStackTrace() and getStackTrace() are not native methods.
> 
> I didn't know how to implement VMThrowable in a VM independent manner so
> I just implemented it in a way that always works but doesn't do anything
> usefull. There are actual implementations of this class for libgcj and
> Kissme, but I don't believe that they can be made general enough to work
> out of the box on every VM.

I guess what I'm saying is, why not make them native? In my case
this would mean I could obtain the goal of "no modifciations to the
reference VM classes needed" because all the other reference classes
don't need to be changed (at least, so far.. I haven't completely
digested them all).

Moreover, making these two methods native doesn't make life any
harder for any other VM's, because if another VM doesn't want to
change the VMThrowable.java file, then they just have to add two
trivial native method implementations (one that returns null and
another that returns a zero length array)).

I can't imagine a lot of VM's can be satisfied with the default
VMThrowable.java because that means you'll never be able to see
exception stack traces (right?).

Finally, it still seems to me like VMThrowable is "different" from
the other VM reference classes. The other classes try to define a
framework for doing something, and then leave the VM part of the
job to native methods. VMThrowable instead defines a framework for
doing something and then provides an implementation that simply
does nothing.

As always, I could be completely misunderstanding things..

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com