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
  • Neal M Gafter
    Please, folks: when you reply to an email to this list, edit the recipient field. It defaults to javax_compiler_owner@yahoogroups.com, which means it only
    Message 1 of 8 , Jul 25, 2003
    • 0 Attachment
      Please, folks: when you reply to an email to this list, edit the
      recipient field. It defaults to javax_compiler_owner@yahoogroups.com,
      which means it only goes to me. You should reply to
      javax_compiler@yahoogroups.com. I don't know if there's anything I
      can do to fix it automagically.

      Olivier Lefevre wrote:
      >>The middle road approach suits us. The long term story should however
      >>consider existing alternate API, such as the one our Eclipse compiler
      >>provides as of today.
      >
      >
      > Do you have an URL for that API? Preferably a _design_ document, not
      > a bunch of Javadocs, please.
      >
      > How does our chair feel about taking the time to study existing compiler
      > APIs before we go beyond the "minimal" program? That might not be a bad
      > idea since in the past Sun has been the target of much bitching in similar
      > circumstances (as with, e.g., the Logging API).

      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.
      How would you feel about doing this study, proposing something else, and
      prototyping it in javac?

      >>For the middle road story, having compiler tools be able to process
      >>the command line arguments is a big improvement
      >
      >
      > If that is all you want, you can already call com.sun.tools.javac.Main.compile.
      > There are two minor problems with that: the first is that javac used not
      > to be reentrant, so you had to use a new Main every time but that has since
      > been fixed and anyway that was only a problem if you were not aware of it.
      > The second is that the class in question is not a core one, so the story
      > may be different with another vendor. The fix for that would be to pull
      > javac.Main into the core or else provide a system facility to grab it
      > (or a wrapper around it), which is just what Neal Gafter suggested, i.e.,
      > his "minimal" program. If we go with that, you won't be able to do
      > anything you couldn't already do: you will merely have an assurance that
      > it will work across platforms and not just on the Sun VM. Hardly a "big"
      > improvement... Or am I missing something?

      That's exactly right: the simple API buys you a consistent and portable
      way to run the compiler if it's present, and you don't have to worry about
      finding the right jar file at compile-time and runtime (which varies from
      platform to platform). It also supports the other tools (javah, rmic,
      javadoc, etc) if present.
    • 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 2 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 3 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 4 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 5 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.