Archie Cobbs <[EMAIL PROTECTED]> writes: > 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..
I think you are correct that most others leave the heavy lifting to a native method and here it is a noop java method. In reality, you will want to copy the reference classes and change them to native or java as suits your JVM. Jikes RVM for instance provides a Java API for all needed native functionality so they don't really want any native methods and hence we sort of need to move anything that has a native method into the vm/reference tree. But there is a different between the stuff you can change and the stuff you absolutely must change and this is one of those areas where I think a good JVM Integration Guide would help. As you're going through this now Archie it would be of tremendous help if you could take a stab at updating the current documentation if needed. Brian -- Brian Jones <[EMAIL PROTECTED]> _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
