[I am resending this due the Mozilla's munging of the attachment on the previous try]
Tomcat developers-
I am starting up a new JSR on an API for invoking a Java Language compiler from within
a Java program. A draft of the JSR proposal is enclosed. This API would be very
useful
anywhere a Java program will want to invoke the Java Compiler, for example ANT
rebuilds,
Java Server Pages, or anywhere an application wants to turn a small snippet of Java
code
into a Class efficiently. In addition, this API calls for the compiler to provide
dependency information after compiling, which would help support incremental rebuilds.
I am in the process of gathering support for this JSR to help it along the initial
stages
of the Java Community Process. Your comments are most welcome.
Regards,
Neal Gafter
JSR Proposal
Title:
Java(TM) Compiler API
Summary:
A service provider API that allows a Java program to select
and invoke a Java Language Compiler programmatically.
Submitter:
Sun Microsystems
Contact Name:
Neal Gafter
Contact E-Mail:
[EMAIL PROTECTED]
Contact Phone:
408-276-7080
Contact Fax:
408-276-7700
Spec Lead Name:
Neal Gafter
Spec Lead E-Mail:
[EMAIL PROTECTED]
Spec Lead Phone:
408-276-7080
Spec Lead Fax:
408-276-7700
Initial Group Membership:
TBD
Supporting this JSR:
Sun Microsystems
Section 2.1: (Description of the proposed Specification)
The Java Compiler API is a set of interfaces that describes
the functions provided by a Java Language Compiler, and a
service provider framework so vendors can provide
implementations of these interfaces.
The interfaces abstract the way a compiler interacts with its
environment. While the existing command-line versions of
compiler receive their inputs from the file systems and
deposit their outputs there, reporting errors in a single
output stream, the new compiler API will allow a compiler to
interact with an abstraction of the file system. This
abstraction will likely be provided by an extension of the NIO
facilities in Tiger (1.5), and allow users to provide source
and class files (and paths) to the compiler in the file
system, in jar files, or in memory, and allowing the compiler
to deposit its output similarly. Diagnostics will be returned
from a compiler as structured data, with both pre- and
post-localization messages available.
In addition, the new API should provide a facility for a
compiler to report dependency information among compilation
units. Such information can assist an integrated development
environment in reducing the scope of future recompilations.
Future versions of this API might expose more of the structure
of the program, for example the declaration structure of the
program (ala the javadoc API), program annotations (JSR 175)
or even the code itself (ASTs: Abstract Sytntax Trees). These
are not goals of the initial version of this specifications.
Section 2.2: (The target Java platform)
J2SE
Section 2.3: (What need of the Java community will be addressed by the spec)
The main initial audiences are
(1) JSP implementations, which must invoke a Java
Language compiler on generated Java code
(2) IDE (Integrated Development Environments) which
must process user-written source code
(3) Some internal Java facilities are simplified
by the ability to generate class files efficiently
through generation of source files.
Section 2.4: (Why isn't this met by existing specifications?)
There simply isn't anything like this in the platform.
Section 2.5: (Description of the underlying technologies)
The reference implementation will likely be built on Sun's javac.
Section 2.6: (Proposed package name for the API spec)
javax.compiler
Section 2.7: (Are there any dependencies on OS/CPU/devices?)
No
Section 2.8: (Are there any new security issues?)
No
Section 2.9: (Are there internationalization of localization issues?)
These will be explicitly addressed by the specification.
Section 2.10: (Will any existring specs become obsolete?)
No
Section 2.11: (What is the anticipated schedule for this spec?)
We hope to have the specification completed in time to be
included in the next major revision of the Java platform
(Tiger).
Section 2.12: (What is the working model for the expert group?)
Sun will lead the specification and implementation work, with
experts contributing to the API specification.
Section 3.1: (What existing documents, specs, or implementations
describe the technology?)
See http://groups.yahoo.com/group/javax_compiler for some very
early thoughts.
Sun's javac will likely form the basis of the reference
implementation.
Section 3.2: (How will these be used as a starting point?)
The expert group will consider them as a starting point for
ideas on defining the specification.
Section 4.1: (Additional Information)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
