Loading ...
Sorry, an error occurred while loading the content.

New JSR on Java(TM) Compiler API

Expand Messages
  • Neal Gafter
    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
    Message 1 of 3 , Oct 10, 2002
    • 0 Attachment
      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.

      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:
      Neal.Gafter@...

      Contact Phone:
      408-276-7080

      Contact Fax:
      408-276-7700

      Spec Lead Name:
      Neal Gafter

      Spec Lead E-Mail:
      Neal.Gafter@...

      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)
    • jim.welch@sybase.com
      Hi Neal, We (that s the iAnywhere Solutions part of Sybase) would support your effort. If you get it through the preliminary red tape, I d personally be
      Message 2 of 3 , Oct 15, 2002
      • 0 Attachment
        Hi Neal,

        We (that's the iAnywhere Solutions part of Sybase) would support your
        effort.

        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.

        Jim Welch



        "Neal Gafter"
        <Neal.Gafter@s To: javax_compiler@yahoogroups.com
        un.com> cc:
        Subject: [javax_compiler] New JSR on Java(TM) Compiler API
        10/10/2002
        07:10 PM
        Please respond
        to
        javax_compiler





        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.

        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:
        Neal.Gafter@...

        Contact Phone:
        408-276-7080

        Contact Fax:
        408-276-7700

        Spec Lead Name:
        Neal Gafter

        Spec Lead E-Mail:
        Neal.Gafter@...

        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 from this group, send an email to:
        javax_compiler-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Neal M Gafter
        Jim- Thanks for your support. I think we will probably do all our business through email. -Neal
        Message 3 of 3 , Oct 16, 2002
        • 0 Attachment
          Jim-

          Thanks for your support. I think we will probably do all our business
          through email.

          -Neal


          jim.welch@... wrote:
          > Hi Neal,
          >
          > We (that's the iAnywhere Solutions part of Sybase) would support your
          > effort.
          >
          > 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.
          >
          > Jim Welch
          >
          >
          >
          > "Neal Gafter"
          > <Neal.Gafter@s To: javax_compiler@yahoogroups.com
          > un.com> cc:
          > Subject: [javax_compiler] New JSR on Java(TM) Compiler API
          > 10/10/2002
          > 07:10 PM
          > Please respond
          > to
          > javax_compiler
          >
          >
          >
          >
          >
          > 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.
          >
          > 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:
          > Neal.Gafter@...
          >
          > Contact Phone:
          > 408-276-7080
          >
          > Contact Fax:
          > 408-276-7700
          >
          > Spec Lead Name:
          > Neal Gafter
          >
          > Spec Lead E-Mail:
          > Neal.Gafter@...
          >
          > 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 from this group, send an email to:
          > javax_compiler-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > javax_compiler-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.