United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4972961 : Use SourceDebugExtension in stack traces

Details
Type:
Enhancement
Submit Date:
2003-12-26
Status:
Open
Updated Date:
2009-06-02
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
generic
Sub-Component:
java.lang
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
5.0
Targeted Versions:

Related Reports

Sub Tasks

Description

Name: tb29552			Date: 12/26/2003


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



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

                                    

Comments
WORK AROUND



Name: tb29552			Date: 12/26/2003


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


======================================================================
                                     
2004-09-22
PUBLIC COMMENTS



Name: tb29552			Date: 12/26/2003


.
======================================================================
                                     
2004-09-22
EVALUATION

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

###@###.### 2004-01-07
                                     
2004-01-07



Hardware and Software, Engineered to Work Together