Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)  |  Nominations
JSRs: Java Specification Requests
JSR 199: JavaTM Compiler API

Stage Access Start Finish
Maintenance Release 4 Download page 10 Sep, 2024  
Maintenance Review Ballot 7 View results 30 Jul, 2024 05 Aug, 2024
Maintenance Draft Review 7 Download page 16 Jul, 2024 29 Jul, 2024
Maintenance Release 3 Download page 15 Mar, 2022  
Maintenance Review Ballot 6 View results 25 Jan, 2022 31 Jan, 2022
Maintenance Draft Review 6 Download page 22 Dec, 2021 20 Jan, 2022
Maintenance Review Ballot 5 View results 03 Aug, 2021 09 Aug, 2021
Maintenance Draft Review 5 Download page 15 Jul, 2021 28 Jul, 2021
Maintenance Review Ballot 4 View results 19 Jan, 2021 25 Jan, 2021
Maintenance Draft Review 4 Download page 06 Jan, 2021 19 Jan, 2021
Maintenance Review Ballot 3 View results 30 Jul, 2019 05 Aug, 2019
Maintenance Draft Review 3 Download page 16 Jul, 2019 29 Jul, 2019
Maintenance Release 2 Download page 21 Sep, 2017  
Maintenance Review Ballot 2 View results 25 Apr, 2017 08 May, 2017
Maintenance Draft Review 2 Download page 09 Mar, 2017 21 Apr, 2017
Maintenance Release Download page 04 Mar, 2014  
Maintenance Review Ballot View results 10 Dec, 2013 16 Dec, 2013
Maintenance Draft Review Download page 04 Nov, 2013 04 Dec, 2013
Final Release Download page 11 Dec, 2006  
Final Approval Ballot View results 24 Oct, 2006 06 Nov, 2006
Proposed Final Draft Download page 02 Oct, 2006  
Public Review Ballot View results 18 Jul, 2006 24 Jul, 2006
Public Review Download page 19 Jun, 2006 24 Jul, 2006
Early Draft Review Download page 13 Jul, 2005 12 Aug, 2005
Expert Group Formation   10 Dec, 2002 28 Mar, 2005
JSR Review Ballot View results 26 Nov, 2002 09 Dec, 2002
Status: Active
JCP version in use: 2.11
Java Specification Participation Agreement version in use: 2.0


Description:
A service provider API that allows a Java program to select and invoke a Java Language Compiler programmatically.

Expert Group Transparency:
  Public Communications
  Issue Tracking

Team

Specification Leads
  Jan Lahoda Oracle
Expert Group
  Bityukov, Serge S.
: Serge S. Bityukov
Borland Software Corporation
: Christian Kemper
Torsten Curdt
  Google Inc.
: Neal Gafter
IBM
: Philippe Mulet
Lefevre, Olivier
: Olivier Lefevre
  Litchev, Lubomir
: Lubomir B Litchev
Oracle
: Jan Lahoda
Oracle
: Michel Trudeau
  Pramati Technologies
: Sachin Hejip
Sun Microsystems, Inc.
: Peter von der Ahe
Sun Microsystems, Inc.
: Santiago Pericas-Geertsen
  TmaxSoft, Inc.
: Changshin Lee
Contributors
       

Updates to the Original JSR

The following updates have been made to the original request.

2024.07.09
The Maintenance Lead has changed from Jonathan Gibbons to Jan Lahoda.

Maintenance Lead: Jan Lahoda

E-Mail Address: jan.lahoda@oracle.com

Telephone Number: -

Fax Number: -

2019.07.16:
The Maintenance of JSR 199 was moved to JCP 2.11.

2013.10.21:
The Maintenance of JSR 199 was moved to JCP 2.9.

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

Interested parties can submit issues at bugs.sun.com, which will be filtered into JBS, the JDK Bug System hosted at https://bugs.openjdk.java.net.

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?

The JSR 199 related issues in JBS

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.

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


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Neal Gafter

E-Mail Address: Neal.Gafter@sun.com

Telephone Number: +1 408 276 7080

Fax Number: +1 408 276 7700


Specification Lead: Neal Gafter

E-Mail Address: Neal.Gafter@sun.com

Telephone Number: +1 408 276 7080

Fax Number: +1 408 276 7700


Initial Expert Group Membership:

TBD

Supporting this JSR:

Sun Microsystems
IBM
Oracle
Borland
Sybase
IBM



Section 2: Request

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.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2SE

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.

We plan to include the RI and TCK as part of J2SE 1.5.

NOTE that this section has been updated from this original request.

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.

NOTE that this section has been updated from this original request.



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.

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.

3.2 Explanation of how these items might be used as a starting point for the work.

The expert group will consider them as a starting point for ideas on defining the specification.