Stack traces, etc.
Sun Dec 1 08:07:00 GMT 2002
On Sat, 2002-11-30 at 11:57, Andrew Haley wrote:
> 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.
Yes. The VMThrowable interface is defined so that all VMs that use GNU
Classpath can share the same implementation of Throwable.
> > 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
> 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.
That would be ideal from my point of view.
> > 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
What I meant to say was that if the VM interface classes that GNU
Classpath defines are not flexible enough for libgcj (or any other VM
that uses GNU Classpath) we should change those VM interface classes in
GNU Classpath to prevent diverging classes that can be shared between
all VMs. And if that is really not possible then the diverged class
should at least clearly document why/what changes were made.
GNU Classpath is far from having a stable VM interface API at the
moment, so suggesting changes will most likely be accepted easily.
> > > * 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.
But I now see that at least one class outside java.lang needs access
(java.securtity.AccessController), so it might not be the perfect
solution after all.
> 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
More information about the Java