| 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. |
| 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.
|
