2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Since JSR 199 is in maintenance, there is no expert group.

2011.12.02
The Maintenance Lead has changed from Peter von der Ahe to Jonathan Gibbons.

Maintenance Lead: Jonathan Gibbons

E-Mail Address: jonathan.gibbons@oracle.com

Telephone Number: +1 408 276 7432

Fax Number: -

2006.10.24

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Sun will license the RI binary for this JSR free of charge.

This JSR will be included in the Java SE 6 platform release. The JSR TCK will thus be licensed as part of the Java SE 6 TCK under the terms described in the JSR-270 business terms.

Sun will license the standalone TCK for this JSR for a flat fee of $50 K. In addition, Sun will make the standalone TCK available for no charge to Java SE TCK licensees, qualified individuals and not for profit organizations.

2006.10.12:

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

We plan to include the RI and TCK as part of Java SE 6 as well as making the TCK available standalone.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

2.1 Please describe the proposed Specification:

The JavaTM Compiler API is a set of interfaces that describes
the functions provided by a JavaTM 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.

2.3 What need of the Java community will be addressed by the proposed specification?

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.

2.4 Why isn't this need met by existing specifications?

There simply isn't anything like this in the platform.

2.5 Please give a short description of the underlying technology or technologies:

The reference implementation will likely be built on Sun's javac.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.compiler

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?

These will be explicitly addressed by the specification.

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

2.11 Please describe the anticipated schedule for the development of this
specification.

We hope to have the specification completed in time to be
included in the next major revision of the JavaTM platform
(Tiger). Note that while this API would be part of Tiger,
it would not be a required part of the JRE.

2.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.

Sun will lead the specification and implementation work, with
experts contributing to the API specification.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

Not applicable.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The terms will be the same as those for J2SE 1.5, which are
broadly the same as J2SE 1.4.