.
======================================================================




It would be useful if java.lang.Throwable printStackTrace() and fillInStackTrace()
used the extra information provided by SourceDebugExtension [NOTE 1] if that
information is available.

A user writes:

  I'm investigating using SourceDebugExtension for compiling a non-java language,
  Nice: http://nice.sf.net. So far the results are promising, in that jdb reports
  files and line numbers as encoded in the SMAP my compiler generates. So far, so
  good.

  However, if a stack trace is generated, I think the jvm should also try to use
  the info in SourceDebugExtension for the default stratum if available, to report
  the line numbers of the stack locations. I found that it does not. Is there a
  plan to implement this in a future version of the JDK? Should I open a bug
  report in the bug database about this?


[NOTE 1] as implemented in JSR 45 "Debugging Support for Other Languages"
    http://jcp.org/en/jsr/detail?id=45



======================================================================

Call java.lang.throwable.getStackTrace() and post-process the results
to reflect SourceDebugExtension


======================================================================

This would require a VM change; in fact, it's solely a VM change.  It is not clear whether it's worth doing.

 xxxxx@xxxxx  2004-01-07

Note that the proposed work-around is partial: it is only
possible when the application explicitely wants to print the
strack. It won't work when the VM itself prints it, for
instance when an exception was uncaught.

Using the default stratum when printing a stack trace seems
the right thing to do. It would make developing with other
languages than Java (e.g. JSP) more friendly.

I investigate the proposed workaround consisting of calling
Throwable.getStackTrace() and post-processing the results
to reflect the SourceDebugExtension attribute. As far as I
could see, there is no public API to obtain the
SourceDebugExtension attribute of a given class in the
current JVM, nor to map a line number to relevant
information for a chosen stratum. There is an API in the
Java Debuging API to do those things, but that is only
available when debuging an application, which must be
running in a separate JVM. So this is not appropriate for
the simpler task of rewriting the stack trace information in
a normal application. 

If such an API is in fact available, I would be grateful if
sombody could point to it. Otherwise, I think a partial
answer to this request would be to provide it (it must
already be implemented in the JDI, it's just a matter of
providing the right entry point to use it outside of the
debugging mode). It would still be nice if the default
behaviour of printStackTrace was to use the information in
the default stratum.

Note that implementing these changes should not impact in
any way "normal" Java programs, which don't have a
SourceDebugExtension attribute (one only needs to discover
that the class has no such attribute, but that can be
implemented cheaply). So there should be no compatibility or
performance problem with this proposal.

I think this is critical functionality for any application that 
uses Java code generation.  Without it, it's nearly 
impossible for such an application to provide useful 
diagnostics.

Another vote for this. 

I agree the implementation is involved, but the way I see it, its better implemented in the platform than by every user of the platform.

i agree that its better to have this as a feature in VM, rather than each developer implementing it independently for stackTraces.

JSR 45 support seems to be a real poor cousin - Java is an excellent language for code generation, and JSR seems to make it even better: letting debuggers and friends cope nicely.

However, not supporting a standard classfile postprocessor (or supporting SMAP files in javac), and not using the SourceDebugExtension where ever possible seems to really cripple the spec.

Why is this good?  It doesn't sound hard to do it properly, and I haven't heard any good reasons why these changes aren't critical.

It seems to me that the JSR-045 is incomplete without this feature.

JSR-045 is quite complex and very-well made, providing a wonderfl easy way to add debug support for any language translating to Java.

It feels a bit clumsy that the JSR-045 participants understood so well the problematic of languages translating to Java and "forgot" to specify that the VM should also use the JSR-045 informations to provide useful stack traces.


Besides, as bonniot quoted in previous comments, the proposed work around does not work and is not acceptable for several reasons.

While I guess that implementing this feature in the VM itself would be quite quick and easy: all the needed informations and code are already there, they just need to be used.