[patch] java run-time stack trace

Andrew Haley aph@redhat.com
Fri Feb 9 02:41:00 GMT 2001

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > > Per Bothner writes:
 > >  > Bryce McKinlay <bryce@albatross.co.nz> writes:
 > >  >
 > >  > > Actually, I'd like to have CNI functions mangled in C++ style. This is
 > >  > > how they are written in the source code (think copy/search/paste), and it
 > >  > > can help to make it very obvious when the stack trace goes through native
 > >  > > code. Also, this is consistent with GDB.
 > >  >
 > >  > What about library functions?  Having (say) ClassLoader.defineClass
 > >  > should up in C++ style is *not* what most users want or expect.
 > Why not? If ClassLoader.defineClass is showing up in a stack trace, then
 > presumably there is a bug somewhere. The user wants to understand what is going
 > on in order to fix that bug, so will go looking for the implementation.

That's an implementers point of view, and is not appropriate for everyone.

 > That implementation is written in C++ style, so surely it makes
 > sense to demangle it in C++ style. We don't _want_ to hide
 > implementation details in a stack trace!

I disagree very strongly.  Having a method change its name because it
happens to be native is unnecessarily confusing and makes gcj look
like less of a real java system than javac.  Better demangle Java
style if possible, *especially* for anything that is defined as a part
of the Standard Java API.  This is IMO an important "look and feel"

 > > I'm sure this is right.  What bothers me is how java demangling can
 > > possibly cope with things like array<int>.
 > Well, it should cope fine - it doesn't touch anything it isn't aware of

I don't think that producing a name that isn't legal in either
language is "coping just fine", but this is less important than
producing correct Java names.


More information about the Java mailing list