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

Welcome to the discussion group for JSR199 (standard API for Java compilers)

Expand Messages
  • Neal M Gafter
    Welcome to the discussion group for JSR 199, which will define a standard interface for Java compilers. This Yahoo group was previously a public forum for this
    Message 1 of 8 , Jun 23, 2003
    • 0 Attachment
      Welcome to the discussion group for JSR 199, which will define
      a standard interface for Java compilers.

      This Yahoo group was previously a public forum for this topic, but
      discussion seems to have died down. The list is now moderated. All
      (and only) of the members of the JSR 199 expert group are moderators
      of this group. Only the members of JSR 199 can post messages to this
      group. We expect to carry on our discussions here, so if you're not
      on the expert group you can still listen in by remaining subscribed to
      this group. You can always send me feedback by private email.

      First, two pieces of bad news. First, the Tiger (1.5) release of J2SE
      will not include a file system API, which we were depending on.
      Second, the folks who define the Tiger release contents have decided
      not to drop JSR 199 altogether from Tiger, but to reduce its scope
      considerably. For 1.5, the Tiger team wants to have a relaiable way
      to invoke javac, without having to depend on any unsupported APIs.

      Our first decision was to have our discussion in this public forum.
      Our second decision will be whether or not we want to define this
      simplified API, or whether we want to focus our attention on the more
      complex API that is described in
      <http://www.jcp.org/en/jsr/detail?id=199>

      If we make the simplified API the goal for JSR 199, then we can
      complete our work and ship the result within the next few months and
      expect it to go into J2SE 1.5. However, the disadvantage is that we
      would have to form a brand new expert group and start a new JSR if we
      want to do the more ambitious spec, because the work of the expert
      group will have been completed. We could probably do that very easily
      with exactly the same set of members, but we would have to go through
      the JCP process of proposing a new JSR.

      On the other hand, if we focus our attention on the more ambitious
      spec, then we cannot expect our work to be included in J2SE until the
      1.6 release at the earliest, because that is the soonest we could
      expect a filesystem API to be included in J2SE; that is the next
      feature release of the platform after Tiger. However, we will be able
      to produce public prototypes of our work in the meantime.

      I suggest we take a middle road. We should state as the explicit goal
      of JSR 199 that we will produce a spec as originally planned.
      Meanwhile, we will define the simpler API as an unofficial product of
      JSR 199 and I will get it included in Tiger.

      I have attached a draft of my recommended simple API. If we go with
      something like this, I will make it work with javac, javap, javah,
      javadoc, and possibly rmic as well in Tiger.

      It's used something like this:

      import javax.shell.*;

      try {
      Command javac = Command.findTool("com.sun.tools.javac");
      PrintWriter out = new PrintWriter(System.out);
      String[] ags = {"-source", "1.5", "/tmp/Foo.java"};
      javac.run(null, out, out, args);
      } catch (CommandNotFound ex) {
      // appropriate cleanup
      }

      What do you think?
    • Neal M Gafter
      ... I think this is an excellent idea. ... This too is a good idea. However, different complers may have completely different command lines, which means a
      Message 2 of 8 , Jun 24, 2003
      • 0 Attachment
        I got the following from Jaroslav Tulach:
        > ... I have few comments to your sample code:
        >
        > 1. When finding the compiler class you should fallback to
        > Thread.getContextClassLoader, life of NetBeans will be easier then.

        I think this is an excellent idea.

        > 2. I suggest to use META-INF/services for registration of compilers. It
        > is defacto standard (specified here
        > http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Provider%20Configuration%20File
        >
        > our impl and description here http://openide.netbeans.org/lookup/) and
        > allows to abstract from the fact that one is communicating with
        > com.sun.tools.javac or fastjavac.

        This too is a good idea. However, different complers may have completely
        different command lines, which means a client may have to be aware of which
        compiler is being used.
      • pmulet2003
        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
        Message 3 of 8 , Jul 25, 2003
        • 0 Attachment
          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.

          This API isn't officially public yet, but it provides support for
          abstracting compilation units, name environments, dependency
          information and a few other aspects (like problem reporting).

          For the middle road story, having compiler tools be able to process
          the command line arguments, is a big improvement over the basic Ant
          task compiler adapter approach.

          Minor request: would it be possible to abstract the way a compiling
          tool could feed a compilation error back ? Something fairly simple
          containing a message, a file name and a text range ?
        • 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 4 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 5 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 6 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 7 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 8 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.