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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
