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

NetBeans' compiler

Expand Messages
  • Svatopluk Dedic
    Hi, all, I m from NetBeans, working on basic java development support - including compilation. As you may be aware, NetBeans comes with Internal compiler ,
    Message 1 of 4 , Jul 2, 2001
    • 0 Attachment
      Hi, all,

      I'm from NetBeans, working on basic java development support - including
      compilation. As you may be aware, NetBeans comes with "Internal
      compiler", which is basically Sun's javac, but slightly hacked. Since we
      had javac (with some public classes like V8ClassReader) and NB
      FileSystem APIs, we only had to write the bridge between these two.
      Basically, we've changed some package-private methods to be protected
      and created a few classes derived from javac' ones to form a bridge of
      I/O to NetBeans IDE. So, we haven't any clean interface between javac
      and the rest of NetBeans; the only interface we have is the NetBeans
      Compiler API.
      File I/O was mapped to NB FileObjects (which have a name, timestamp, can
      create input/output streams) using a (formerly package-private) factory
      method in javac which used to create one kind of objects for .jar
      entries and another one for ordinary files. The bridge now creates only
      one kind of FileEntry - since it already works with FileObjects. Output
      was also mapped to FileObjects, while error messages were mapped to
      event objects/calls much similar to the CompilerMessage interface.

      Summary:
      - we've hacked javac through inheritance to hook into the process
      - we have a bridge, which, at this point, integrates javac with the IDE
      as whole, not only with FileSystems.
      - abstraction over java.io.File is already implemented and available as
      standalone FileSystems library

      Now what can be done ? I think, that, at least, we can provide a working
      prototype of compiler which actually exposes some API you've proposed
      here. However I am afraid that download of the binary will still require
      clicking on the license [:-\] and I'm not 100% sure if the binary form
      can be (legally) used without NetBeans installed somewhere on the
      computer (will check).
      We can (and IMO should, after the API become final) also allow
      plugging in new compilers conforming to the API to be run internally
      using full filesystem power.
      And obviously, we can comment the APIs a little, if you don't mind [:-)]

      BTW the click-and-download system on netbeans.org is mainly because the
      NetBeans distro includes third-party binaries with a special license
      conditions (like javac, ice browser...). I am almost positive that you
      don't need such thing if you could download "openide-fs.jar" alone. In
      fact, you could create a snapshot of sources, build them and place the
      result .jar in your distribution, if I understand the SPL conditions well.

      --
      Svatopluk Dedic <mailto:svatopluk.dedic@...>
      NetBeans, Java/Repository <http://www.netbeans.org>
    • Jon Skeet
      ... I suspect you ve got some valuable opinions before we get to prototype stage - namely, what s currently missing/superfluous in the current API? ...
      Message 2 of 4 , Jul 2, 2001
      • 0 Attachment
        > Now what can be done ? I think, that, at least, we can
        > provide a working prototype of compiler which actually exposes
        > some API you've proposed here.

        I suspect you've got some valuable opinions before we get to prototype
        stage - namely, what's currently missing/superfluous in the current API?
        :) One thing you've presumably got a fair amount of experience in is
        pluggable modules: what should the CompilerFactory have/do?

        > However I am afraid that download of the binary will still require
        > clicking on the license [:-\] and I'm not 100% sure if the
        > binary form can be (legally) used without NetBeans installed somewhere

        > on the computer (will check).

        Not a problem for a prototype, I'm sure.

        > We can (and IMO should, after the API become final) also allow
        > plugging in new compilers conforming to the API to be run internally
        > using full filesystem power.

        Excellent. Plugging in other compilers into IDEs was half the reason I
        wanted to start this project off. As it happens, I have very little use
        for it directly myself, but got fed up with so many people on
        comp.lang.java.* asking for documentation to the javac classes :)

        > And obviously, we can comment the APIs a little, if you don't
        > mind [:-)]

        Yup - apologies for the lack of commenting at the moment. Given the rest
        of the discussion so far, it's hopefully obvious to most people what the
        various things mean. When it's firmed up a bit more, we can go about
        sorting out the comments. Mind you, as the membership of this group has
        grown somewhat (okay, exploded), it might be worth doing it sooner
        rather than later: when I wrote it, everyone in the group had seen the
        comments from the previous version. That's far from true now, and I can
        quite understand people not wanting to go through the whole discussion
        from the web interface, so I'll see what I can do over the next few
        days. That means the earlier people speak up about problems with the
        interface, the more likely it is their suggestions will be documented in
        the near future :)

        Jon
      • Svatopluk Dedic
        ... CompilerFactory could be fine as is, as long as there s exactly one compiler provider within the system. Otherwise you need some registry that would serve
        Message 3 of 4 , Jul 3, 2001
        • 0 Attachment
          Jon Skeet wrote:

          >>Now what can be done ? I think, that, at least, we can
          >>provide a working prototype of compiler which actually exposes
          >>some API you've proposed here.
          >>
          >
          > I suspect you've got some valuable opinions before we get to prototype
          > stage - namely, what's currently missing/superfluous in the current API?

          > :) One thing you've presumably got a fair amount of experience in is
          > pluggable modules: what should the CompilerFactory have/do?
          >

          CompilerFactory could be fine as is, as long as there's exactly one
          compiler provider within the system. Otherwise you need some registry
          that would serve all available Compilers.
          BTW the Compiler interface itself is a factory - for compilation tasks.

          The typical cycle how to work with a compiler is to create the engine's
          instance (done via the Factory), do some customization for the task
          (initializing Parameters) and launch the compilation.

          The Parameters type is an interface, which means problems if the
          compiler supports more options in the future, except passing all
          additional options through the commandline-like method option(String).
          The Parameters type is implemented on client's side, which I don't
          believe is correct. As it stands now, only "option(String)" method could
          benefit from processing at the client's side. I suppose that the client
          will be required to return exactly the same values from those methods
          throughout the compilation process, or the methods will be called
          exactly once.

          I kindly disagree with Neil's previous recommendation to create
          Parameters interface. Since the set of parameters is specific to the
          compiler, I'd rather have Parameters to be non-final public class
          following Java Beans spec, so it can be easily plugged into various GUI
          configuration tools. Setting properties (like bootClassPath) to a bean,
          then passing the bean to someone as a parameter block also suggests that
          the configuration is done once - and there will be a single (base)
          implementation of the parameter bean.
          Making the Parameters a class will also allow extending the base
          definition in the future without breaking backwards compatibility.

          [more to come later]


          >> We can (and IMO should, after the API become final) also allow
          >>plugging in new compilers conforming to the API to be run internally
          >>using full filesystem power.
          >>
          >
          > Excellent. Plugging in other compilers into IDEs was half the reason I
          > wanted to start this project off. As it happens, I have very little use
          > for it directly myself, but got fed up with so many people on
          > comp.lang.java.* asking for documentation to the javac classes :)
          >

          Eh, I forgot about one MAJOR problem. Your code already uses JDK-1.4
          specific classes, which won't be available yet some time and NetBeans
          need to run on the current and the previous release of JDK.


          >
          >>And obviously, we can comment the APIs a little, if you don't
          >>mind [:-)]
          >>
          >
          > Yup - apologies for the lack of commenting at the moment. Given the rest


          I suppose my bad English caused a misunderstanding here. I meant "make
          comments on how the APIs look like". Sure we can write javadocs and send
          you patches, too :-) Sorry for the confusion.

          --
          Svatopluk Dedic <mailto:svatopluk.dedic@...>
          NetBeans, Java/Repository <http://www.netbeans.org>
        • Jon Skeet
          ... Well, there d probably be a preference system - ie you get whichever one is configured in the most important place (wherever that turns out to be). If you
          Message 4 of 4 , Jul 3, 2001
          • 0 Attachment
            > CompilerFactory could be fine as is, as long as there's exactly one
            > compiler provider within the system. Otherwise you need some registry
            > that would serve all available Compilers.

            Well, there'd probably be a preference system - ie you get whichever one
            is configured in the most important place (wherever that turns out to
            be).
            If you want a specific compiler, of course, you'd probably be able to
            instantiate it directly.

            > BTW the Compiler interface itself is a factory - for
            > compilation tasks.

            Effectively, yes.

            > The typical cycle how to work with a compiler is to create
            > the engine's
            > instance (done via the Factory), do some customization for the task
            > (initializing Parameters) and launch the compilation.

            Yup.

            > The Parameters type is an interface, which means problems if the
            > compiler supports more options in the future, except passing all
            > additional options through the commandline-like method option(String).
            > The Parameters type is implemented on client's side, which I don't
            > believe is correct. As it stands now, only "option(String)"
            > method could
            > benefit from processing at the client's side. I suppose that
            > the client
            > will be required to return exactly the same values from those methods
            > throughout the compilation process, or the methods will be called
            > exactly once.

            That's an interesting point, and potentially a restrictive one. I can
            imagine it would occasionally be nice to be able to change parameters
            based on what's being compiled (eg compile one package with debug turned
            on and one with it turned off). I'm not sure whether that would be
            useful enough to warrant a change though. We should definitely document
            intended use though.

            > I kindly disagree with Neil's previous recommendation to create
            > Parameters interface.

            I'll let you two sort that bit out - I have no strong feelings either
            way. At least, none that I haven't said before, probably.

            > Eh, I forgot about one MAJOR problem. Your code already uses JDK-1.4
            > specific classes, which won't be available yet some time and NetBeans
            > need to run on the current and the previous release of JDK.

            Hmm. Ah. Oops. Similar noises...

            I'm in two minds about this. Using the 1.4 classes and Java generics
            certainly appeals to my sense of elegance, but I can see the backwards
            compatibility arguments too. In fact, the generics part may not be a
            problem as (IIRC) you can use generically produced classes in a
            non-generic compiler, you just don't get the safety. The use of
            ByteBuffer and CharBuffer is harder. The thing is, they really *do* add
            to the elegance of it, IMO...

            (I also have personal biases, having been held at 1.1 for the last two
            years just in case the professional project I'm working on needed to be
            integrated with MS Java stuff. I'm afraid the backlash against that
            constraint may be pushing me towards new stuff more than I would
            otherwise.)

            > >>And obviously, we can comment the APIs a little, if you don't
            > >>mind [:-)]

            > > Yup - apologies for the lack of commenting at the moment.

            > I suppose my bad English caused a misunderstanding here. I
            > meant "make comments on how the APIs look like".

            Ah - yes, right :)

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