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

Byte code compiler assembler and manipulator

Expand Messages
  • Cyrille Morvan by way of Cyrille Morvan
    All - I just read the JSR description (199), and it only speaks about source code compilation. Do you think it s possible to add to the specification a byte
    Message 1 of 4 , Dec 3, 2002
    • 0 Attachment
      All -

      I just read the JSR description (199), and it only speaks about source code
      compilation.

      Do you think it's possible to add to the specification a byte code assembler
      and/or an API to give to the users a convenient possibility to analyze,
      create, and manipulate (binary) Java class files ?

      Preprocessor, aspect oriented framework could use that kind of tool.

      There is already a bytecode manipulator in MS.dotNet, and Java developers
      have to some external products (opensource or not).
      But in my opinion, a bytecode manipulator and/or assembler should be part of
      the Java API, some developers and big companies are afraid to use tools that
      are not part of the specification.

      Do you know if there is already a group working on that specification, do you
      think it should be part of this JSR ?


      BCEL :
      http://jakarta.apache.org/bcel/

      Jasmin Assembler :
      http://www.cat.nyu.edu/meyer/jasmin/

      Jikes BT
      http://www.alphaworks.ibm.com/tech/jikesbt


      Regards,

      --
      Cyrille Morvan
      IT Student / Orsay / France
      (+1) 713-689-5489
    • Neal Gafter
      ... I don t think such an API would have anything at all in common with a Javac compiler API, so I don t think there would be any value in adding this to
      Message 2 of 4 , Dec 4, 2002
      • 0 Attachment
        --- In javax_compiler@y..., Cyrille Morvan <cmorvan@h...> wrote:
        > Do you think it's possible to add to the specification
        > a byte code assembler and/or an API to give to the users a
        > convenient possibility to analyze, create, and manipulate
        > (binary) Java class files ?

        I don't think such an API would have anything at all in common with
        a Javac compiler API, so I don't think there would be any value in
        adding this to JSR#199.
      • Chris Smith
        ... code ... assembler ... Before an assembler could be provided, you d need a standard for JVM bytecode assembler format. Perhaps the Jasmin format could be
        Message 3 of 4 , Dec 4, 2002
        • 0 Attachment
          > I just read the JSR description (199), and it only speaks about source
          code
          > compilation.
          >
          > Do you think it's possible to add to the specification a byte code
          assembler
          > and/or an API to give to the users a convenient possibility to analyze,
          > create, and manipulate (binary) Java class files ?

          Before an assembler could be provided, you'd need a standard for JVM
          bytecode assembler format. Perhaps the Jasmin format could be adopted, but
          there would need to be some official consensus on defining that language.
          There hasn't been, of yet.

          There is already at least one tool (BCEL, which you mentioned) to do the
          latter bit. Perhaps that could become part of the language, too. Again,
          though, it's not really related to a language compiler. It might be used in
          the implementation of such a language compiler, but I see no connection in
          terms of the API.

          > There is already a bytecode manipulator in MS.dotNet, and Java developers
          > have to some external products (opensource or not).
          > But in my opinion, a bytecode manipulator and/or assembler should be part
          of
          > the Java API, some developers and big companies are afraid to use tools
          that
          > are not part of the specification.

          That's a very poor reason to expand the core API. If any such companies
          truly exist (ie, ones that won't use code only because it's outside the core
          API), then they will die soon and be replaced by companies with more
          reasonable approaches on licensing and applying third-party code. Efforts
          to stop this natural evolution of matters are misguided.

          > Do you know if there is already a group working on that specification, do
          you
          > think it should be part of this JSR ?

          Not part of this JSR. If you think that the BCEL is useful enough to become
          part of the core API, propose it as a new JSR.

          --
          www.designacourse.com
          The Easiest Way to Train Anyone... Anywhere.

          Chris Smith - Lead Software Developer/Technical Trainer
          MindIQ Corporation
        • Cyrille Morvan
          ... In JSR# 198 ( A Standard Extension API for Integrated Development Environments), they want to do a source code meta model : Data Model - The addin will
          Message 4 of 4 , Dec 5, 2002
          • 0 Attachment
            On Wednesday 04 December 2002 17:32, Neal Gafter wrote:
            > --- In javax_compiler@y..., Cyrille Morvan <cmorvan@h...> wrote:
            > > Do you think it's possible to add to the specification
            > > a byte code assembler and/or an API to give to the users a
            > > convenient possibility to analyze, create, and manipulate
            > > (binary) Java class files ?
            >
            > I don't think such an API would have anything at all in common with
            > a Javac compiler API, so I don't think there would be any value in
            > adding this to JSR#199.

            In JSR# 198 ( A Standard Extension API for Integrated Development
            Environments), they want to do a source code meta model :

            " Data Model - The addin will have access to the metadata model for a source
            file (Class, method, members, etc.) "

            Do you will support this ? To compile the datamodel or create the DataModel ?
            A default implementation could just serialize the datamodel into a buffer and
            compile it. A more performant implementation could not.

            The same, we could have a bytecode datamodel. and the compiler API would be
            able to compile everything : bytecode and source code...

            Am I stupid ?

            javax.compiler.*
            javax.compiler.source.*
            javax.compiler.bytecode.*


            If you don't see any value in adding this to JSR# 199, do you think it
            has no value ? Is there anybody who is already working on that ?

            --
            Cyrille Morvan
            IT Student, Orsay, France
          Your message has been successfully submitted and would be delivered to recipients shortly.