Stack traces, etc.

Sat Nov 30 03:21:00 GMT 2002

Mark Wielaard writes:
 > On Sat, 2002年11月30日 at 00:53, Andrew Haley wrote:
 > > The interface to StackTrace will probably change. In any case, it's
 > > only for libgcj's internal use.
 > 
 > You renamed VMThrowable to StackTrace and put it in another package,
 > this makes Throwable not in sync with Classpath anymore.
VMThrowable makes direct calls to methods that make no sense outside
libgcj, so I assume you mean that the VMThrowable interface is shared
with Classpath.
 > I am trying (very slowly) to get the public classes from Classpath
 > and libgcj as much in sync as possible. The StackTrace interface
 > expands the VMThrowable interface but still uses the same methods
 > used by the public class Throwable. 
VMThrowable is a misleading name for what the class now does -- it's
actually a means for accessing stack traces, and no longer has
anything to do with Throwable. Throwable uses it, sure, but so do
plenty of other classes. Throwable is simply one of StackTrace's
customers.
If VMThrowable is needed as a well-defined interface for compatibility
with Classpath there's no reason it could not be a thin layer on top
of stack traces. That way, Throwable.java can be brought back into
sync with Classpath.
 > So I would like to see it renamed back to VMThrowable, unless there
 > is a good argument to diverge Throwable from the Classpath version.
This is a dangerous way to argue. We surely must not get into a
situation where Classpath compatibility is a barrier to making
changes.
 > > * This implementation has a security hole, in that anyone may call
 > > StackTrace.classAt() and get the calling class. We'll have to
 > > restrict the availability of StackTrace.
 > 
 > Since these methods are only used from either classes in java.lang or
 > from friend classes written in C++ it is a good idea to make those
 > methods package private and put it in the package java.lang. That way
 > ordinary java classes cannot access it.
This makes some sense, I agree. 
I'm inclined towards a compromise whereby we maintain the existing
VMThrowable interface for Classpath compatibility, but any details of
how VMThrowable does its job must be considered to be "under the
hood."
Andrew.