Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 45: Debugging Support for Other Languages

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant: Sun Microsystems
Name of Contact Person: Gilad Bracha
E-Mail Address: gilad.bracha@sun.com
Telephone Number: +1 408 863 3116
Fax Number: +1 408 343 1797
Submitting Participant: IBM
Name of Contact Person: Arthur Ryman
E-Mail Address: ryman@ca.ibm.com
Telephone Number: +1 416 448 3077
Fax Number: +1 416 448 4414

Other Participants who endorse this JSR:

  • Allaire Corporation
  • Oracle Corporation

Section 2: Request

2.1 Please describe the proposed Specification:
A variety of languages that are being translated into the Java programming language are becoming important to the industry. Notable examples are JSP and SQLJ. It is highly desirable to debug these languages at the source level. To support this, there is a need for standardized tools for correlating Java Virtual Machine byte code to source code of languages other than the Java programming language.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
Any Java Platform that supports debugging.
2.3 What need of the Java community will be addressed by the proposed specification?
The need to debug languages other than Java compiled to the Java virtual machine at the source level.
2.4 Why isn't this need met by existing specifications?
Existing debugging support allows source level debugging of the Java programming language, but not of any other language.
2.5 Please give a short description of the underlying technology or technologies:

Debugging information to correlate source code and byte code can be stored in a class file as an attribute. Such attributes already exist and are used by most Java compilers. These include the LineNumberTable and SourceFile attributes. These attributes are used by debugging tools today.

Tools that process class files in different ways are also in widespread use.

It is possible to produce tools that support the objective of the JSR by post-processing class files and modifying these attributes so that they refer to the appropriate locations in non-Java source code.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)
Not at this time. The package that provides the implementation of the tools is yet to be determined.
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
No.
2.8 Are there any security issues that cannot be addressed by the current security model?
No.
2.9 Are there any internationalization or localization issues?
No.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
No. In particular, this proposal does not propose any changes whatsoever to the Java programming language or virtual machine specifications.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.
The class file format attributes that relate to this specification are described in the Java Virtual Machine Specification, as is the class file format as a whole.
3.2 Explanation of how these items might be used as a starting point for the work.

The details of the design and implementation are to be determined. As an illustration, we outline one possible approach:

One would be to define a standardized format for correlating source code in one language to source code in another. Preprocessors that produce Java programming language source code would then produce maps in that format. An API to allow tools to do this easily should be defined.

A class file post processor could then use these maps in conjunction with the attributes in the class file to produce a functionally equivalent class file, which differed only in some of its attributes (those related to source level debugging). In particular, the LineNumberTable attribute would reflect the composition of the mapping from Java to source and the mapping from byte code to Java.