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

Re: [javax_compiler] Re: Welcome to the discussion group for JSR199 (standard API for Java compilers)

Expand Messages
  • Olivier Lefevre
    ... Oops, sorry. You may have said this earlier and I may have noted it but there is so little traffic on this list that I forgot ;-) ... You misunderstood me.
    Message 1 of 8 , Jul 25, 2003
    • 0 Attachment
      > Please, folks: when you reply to an email to this list, edit the
      > recipient field.

      Oops, sorry. You may have said this earlier and I may have noted it
      but there is so little traffic on this list that I forgot ;-)

      >> How does our chair feel about taking the time to study existing compiler
      >> APIs before we go beyond the "minimal" program?
      >
      > I expect to be working 60+ hours per week until Tiger code freeze, as I
      > have been since late last year. I simply cannot take on any additional
      > work.

      You misunderstood me. I wasn't suggesting that you kill yourself at work:
      we need our chairman! Rather, I meant that if we take the time to study
      existing APIs, then for sure the odds of getting anything beyond the
      "minimal program" into Tiger drop to zero.

      In addition, there's a policy issue there. The Generics JSR spec had these
      infamous and very controversial "non-goals". So, we must first decide
      what trying to accomodate existing compiler APIs shall be to us: a goal,
      a non-goal or an anti-goal? Now I, too, am feeling like a theologist ;-)
      In other words, is that something we wish to care about and how much?

      > How would you feel about doing this study, proposing something else, and
      > prototyping it in javac?

      I don't think I can do that by August 15 either but otherwise I am
      willing to try, yes.

      Regards,

      -- O.L.
    • Philippe P Mulet
      I was only mentionning alternate APIs for the long term story when we want to address this JSR. There is no existing documentation reflecting the Eclipse
      Message 2 of 8 , Aug 3, 2003
      • 0 Attachment
        I was only mentionning alternate APIs for the long term story when we want
        to address this JSR. There is no existing documentation reflecting the
        Eclipse compiler API as of today, but something could be done on this
        front.

        FYI, I am not interested in invoking com.sun.tools.javac.Main.compile, but
        rather defining an API we can all agree on and then have the Eclipse java
        compiler implement it (or did I miss something obvious wrt the purpose of
        the javac Main?). So the proposed simple story is already a good
        improvement in the sense I could feed the Eclipse compiler with its own
        specific command line arguments, without breaking the API. With the Ant
        javac task, extra arguments are not tolerated.

        Sincerly,
        Philippe Mulet




        Olivier Lefevre
        <lefevre@...> To: javax_compiler@yahoogroups.com
        cc:
        07/25/2003 10:47 Subject: Re: [javax_compiler] Re: Welcome to the discussion group for JSR199
        PM (standard API for Java compilers)
        Please respond to
        javax_compiler-ow
        ner







        > Please, folks: when you reply to an email to this list, edit the
        > recipient field.

        Oops, sorry. You may have said this earlier and I may have noted it
        but there is so little traffic on this list that I forgot ;-)

        >> How does our chair feel about taking the time to study existing compiler
        >> APIs before we go beyond the "minimal" program?
        >
        > I expect to be working 60+ hours per week until Tiger code freeze, as I
        > have been since late last year. I simply cannot take on any additional
        > work.

        You misunderstood me. I wasn't suggesting that you kill yourself at work:
        we need our chairman! Rather, I meant that if we take the time to study
        existing APIs, then for sure the odds of getting anything beyond the
        "minimal program" into Tiger drop to zero.

        In addition, there's a policy issue there. The Generics JSR spec had these
        infamous and very controversial "non-goals". So, we must first decide
        what trying to accomodate existing compiler APIs shall be to us: a goal,
        a non-goal or an anti-goal? Now I, too, am feeling like a theologist ;-)
        In other words, is that something we wish to care about and how much?

        > How would you feel about doing this study, proposing something else, and
        > prototyping it in javac?

        I don't think I can do that by August 15 either but otherwise I am
        willing to try, yes.

        Regards,

        -- O.L.

        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/
      • Olivier Lefevre
        ... That would be nice. If there is no document outlining its design philosophy, that is not very conducive to taking it into account when researching existing
        Message 3 of 8 , Aug 7, 2003
        • 0 Attachment
          > I was only mentionning alternate APIs for the long term story when we
          > want to address this JSR. There is no existing documentation reflecting
          > the Eclipse compiler API as of today, but something could be done on
          > this front.

          That would be nice. If there is no document outlining its design
          philosophy, that is not very conducive to taking it into account
          when researching existing APIs...

          > FYI, I am not interested in invoking com.sun.tools.javac.Main.compile

          Why not? The command-line arguments to compile are an API of sorts
          already. Assuming it were brought out in the open, so to speak, a priori
          I would have thought that it provides the kind of functionality required
          by IDE and Ant people. So, what do you dislike about it and what do you
          want from the new API?

          Regards,

          -- O.L.
        • Neal Gafter
          ... That is exactly right: the proposed simple tool API is little more than an abstraction of the entry point to the compiler. The little more is that you
          Message 4 of 8 , Aug 17, 2003
          • 0 Attachment
            Philippe P Mulet wrote:
            > AFAIK *.javac.Main is only the front end to Sun javac. The proposed simple
            > tool API is a simple abstraction of it, I don't see much more into it. FYI,
            > Eclipse JDT implements its own Java compiler which provide core technology
            > for other compilation aware tools (like codeassist, search, etc...).

            That is exactly right: the proposed simple tool API is little more than an
            abstraction of the entry point to the compiler. The "little more" is that
            you don't have to worry about tools.jar when compiling your application or
            when running it. Perhaps Eclipse's compiler APIs are more in line with
            what we intend for JSR199.

            > The simple tool approach however doesn't surface dependency information,
            > which is quite essential to buld an incremental compiler on top of it.

            Also correct. However, I haven't yet seen a clear specification for
            "dependency" that would be applicable to the API.

            > Talking about the Eclipse compiler API, it is fairly stable, and has been
            > in use for several years already. Its javadoc are fairly detailed, though
            > we should definitely invest more time for producing a design document. BTW,
            > where is the matching documentation for the primary candidate API ?

            I don't think we have a primary candidate yet. If what I found at

            http://www.eclipse.org/documentation/html/plugins/org.eclipse.jdt.doc.isv/doc/reference/api/org/eclipse/jdt/core/package-summary.html

            is the documentation you're talking about, I wouldn't call a single
            sentence for the documentaiton of the main package "fairly detailed."
            For the class ICompilationUnit (it seemed like a reasonable place to
            start) I found two sentences. Is there some other more detailed
            documentation?

            -Neal
          Your message has been successfully submitted and would be delivered to recipients shortly.