We (that's the iAnywhere Solutions part of Sybase) would support your
If you get it through the preliminary red tape, I'd personally be available
to review documents, etc. I'd have a hard time justifying trips to
California for face-to-face meetings.
Our interest is in facilitating builds, which is similar but not identical
to the IDE problem.
<Neal.Gafter@s To: firstname.lastname@example.org
Subject: [javax_compiler] New JSR on Java(TM) Compiler API
I am starting up a new JSR on an API for invoking a Java Language
compiler from within a Java program. That was the original purpose
for the existence of this group. A draft of the JSR proposal is
enclosed. The history of the discussion within this group is listed
as a reference for the definition of the JSR. As you probably know,
this API will be very useful in implementations of an IDE and for JSP
implementations, and it will make it possible for programs to compile
small snippets of Java source code very efficiently.
I'm currently at the stage of gathering support and endorsement to help
this proposal over the initial stages of the JSR process, most
hopefully from large influential Java licensees. Suggestions and
and offers of support are most welcome.
Java(TM) Compiler API
A service provider API that allows a Java program to select
and invoke a Java Language Compiler programmatically.
Spec Lead Name:
Spec Lead E-Mail:
Spec Lead Phone:
Spec Lead Fax:
Initial Group Membership:
Supporting this JSR:
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)
Section 2.3: (What need of the Java community will be addressed by the
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)
Section 2.7: (Are there any dependencies on OS/CPU/devices?)
Section 2.8: (Are there any new security issues?)
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?)
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
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?)
for some very
Sun's javac will likely form the basis of the reference
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 from this group, send an email to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/