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
  • 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 1 of 8 , Aug 3 12:29 AM
    • 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 2 of 8 , Aug 7 2:04 AM
      • 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 3 of 8 , Aug 17 3:40 PM
        • 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.