Hi, On Thu, 2003-02-20 at 22:20, Archie Cobbs wrote: > Ideally, a JVM should "just work" with the default classpath sources, and > this seems to be an explicit goal of classpath. In particular, one should > not have to modify the Java source files for each JVM (i.e., the files in > "vm/reference" should work for most JVM's).
Everything *outside* vm/reference should work out of the box for every VM. At least if we can implement the native stuff in JNI and the VM supports JNI. The classes in vm/reference are mostly VM dependent and can not always be implemented in a way that will (efficiently) work for every VM. So in principle all a VM implementor has to do is look at the classes inside vm/reference and adapt them to their own VM. (In theory that is...) In practise a lot of code in vm/reference is still VM independent so should/could be moved outside vm/reference into the actual package with only small VM state/helper classes left inside vm/reference. The trick is to know which parts can actually be implemented (efficiently) VM indepeendent and what VM dependent interface to keep in vm/reference. (Clearly this is a work in progress and a lot of how it works now comes from when Japhar was the only VM that used GNU Classpath - that was before there was any 1.2 class support. And from before I joined the project.) > Howver, the java.lang.VMThrowable class doesn't seem to follow this rule, > because fillInStackTrace() and getStackTrace() are not native methods. > I.e., most JVM's would want to actually implement these methods, and that > means not only implementing native methods but modifying VMThrowable.java > to make the methods native in the first place. This seems to me like an > oversight. 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. > As a side note, why does VMThrowable.getStackTrace() take a Throwable > parameter? It seems unnecessary. The libgcj implementation uses that parameter to strip any throwable method calls from the actual StackTraceElements returned. It might not be necessary in every implementation though. I believe the Kissme implementation ignores it. > Apologies in advance if I'm confused :-) No, please ask. This is an area that is not documented enough and VM implementers must really give us feedback on how they actually use this stuff. See for another examples of how I think the core classes and their vm/reference counterparts should evolve the suggestion for splitting Thread into a VM independent Thread and a VM dependent VMThread class: http://mail.gnu.org/archive/html/classpath/2002-10/msg00009.html (I have not found the time/opportunity to actually implement this yet.) Cheers, Mark _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
