Create and Read J2SE 5.0 Annotations with ASM

Discussions

News: Create and Read J2SE 5.0 Annotations with ASM

  1. Create and Read J2SE 5.0 Annotations with ASM (9 messages)

    This article is the second in the series on the ASM toolkit. This installment discusses how ASM can be used to manipulate Java 5 Annotations. We are shown the code required to create annotations on the fly, and reading them in.

    Read: Create and Read J2SE 5.0 Annotations with the ASM Bytecode Toolkit

    Threaded Messages (9)

  2. Javassist[ Go to top ]

    Javassist has similar capabilities with annotations as we use it extensively in JBoss AOP.

    The advantage Javassist has over other bytecode frameworks is its embedded java compiler. You can have Javassist compile code that is expressed as a string and overwrite an existing method, or create a class/method/constructor dynamically. Its pretty cool. Check out the tutorial at:

    http://www.javassist.org

    Bill
  3. Javassist[ Go to top ]

    Javassist has similar capabilities with annotations as we use
    >it extensively in JBoss AOP.
    >The advantage Javassist has over other bytecode frameworks is
    >its embedded java compiler.

    On the other hand that means you impose a performance penalty on your users as they wait while javassist compiles. When I had to make a choice which bytecode generator to use for (shameless plug) JDBCPersistence I choose ASM. For many reasons - small API, performance. The core of ASM is just a few classes and its size is 25K vs ~400K of javassist.

    My point is that feature can be an advantage or disadvantage depending on its application. I hope JBoss applies to the advantage of JBoss users.
  4. Javassist[ Go to top ]

    >Javassist has similar capabilities with annotations as we use>it extensively in JBoss AOP.>The advantage Javassist has over other bytecode frameworks is>its embedded java compiler. On the other hand that means you impose a performance penalty on your users as they wait while javassist compiles. When I had to make a choice which bytecode generator to use for (shameless plug) JDBCPersistence I choose ASM. For many reasons - small API, performance. The core of ASM is just a few classes and its size is 25K vs ~400K of javassist.My point is that feature can be an advantage or disadvantage depending on its application. I hope JBoss applies to the advantage of JBoss users.

    I have yet to have any of my Javassist applications be hurt by the "performance drain" you talk about and I fail to see the relevance of JAR size.

    Javassist is great because you do not have to know bytecode to do bytecode engineering. Your code is also more maintainable as your bytecode modifications are expressed in Java instead of bytecode.

    One of the coolest features is the ExprEditor. It iterates through your bytecode making callbacks to your app code that can handle method calls, constructor calls, field accesses, etc... If you're interested in modifying a call to a method you just do:

    methodCall.replace("put in your java code here") and the method invocation gets replaced with another piece of Java code compiled by Javassist. Cool as shit, and easy as pie, IMO.

    I chose Javassist for JBoss AOP because
    a) I didn't want to learn bytecode
    b) The tutorial was excellent and allowed me to learn javassist in a very short time
    c) It is extremely easy to do things
    d) Over time, it has allowed me to work directly with bytecode when I rarely needed to.

    Bill
  5. Javassist[ Go to top ]

    Bill, it seems that your points a) and d) are controversial. You still have to learn bytecode because Javassist can't handle everything. However there is no warranty that it will handle common cases efficiently. Because Java language and JVM actually using different execution model (variable-based vs. stack-based), there are lot of cases where bytecode can be more efficient (see recent obfuscation at http://today.java.net/pub/a/today/2004/10/22/obfuscation.html which has some neat examples), so it is a great challenge for high level tool to match efficiency of the similar but low level toolkit. Moreover it is more difficult because tool have to deal with all kind of crazy scriplets user can came with. That is why I've recommended to use simple comparison-based approach in my first ASM article, which work very well for me and allows to build bytecode very quick. So, you just need to write two Java classes (one before and one after transformation), compile them, run ASMifier tool on both of them (this will generate ASM-based Java code that will produce the same bytecode as an original .class) and then you just compare those Java files. Moreover Andrei Loskutov built a great plugin for Eclipse, which makes this process even easier, so you just select two Java sources and choose Compare wich each other ASM code.

    However I can see ASM disadvantages in being too lowlevel framework and that is why we have CGLIB, which provide high level abstraction for common bytecode transformations.
  6. Javassist[ Go to top ]

    Bill, it seems that your points a) and d) are controversial. You still have to learn bytecode because Javassist can't handle everything.

    Javassist handles everything I needed to do and my requirements are complex.
    However I can see ASM disadvantages in being too lowlevel framework and that is why we have CGLIB, which provide high level abstraction for common bytecode transformations.

    CGLIB does not meet any of my requirements. I need complex and advanced bytecode massaging.

    Bill

    Bill
  7. Javassist[ Go to top ]

    I have yet to have any of my Javassist applications be hurt by the "performance drain"

    Parsing is a computation intensive operation. Depending on its impact on overall performance you may care about other parts of your app more.

    >I fail to see the relevance of JAR size.

    You are correct, when it only increases size of download by 0.5 percent the size is not relevant. When increases size of download by more than 100 percent I find it relevant.

    >methodCall.replace("put in your java code here") and the method invocation gets replaced with another piece of Java code compiled by Javassist.
     
    >Cool as shit, and easy as pie, IMO.
    I'll take your word for it.

    >I chose Javassist for JBoss AOP because
    >a) I didn't want to learn bytecode
    >b) The tutorial was excellent and allowed me to learn javassist in a very short time
    >c) It is extremely easy to do things
    >d) Over time, it has allowed me to work directly with bytecode when I rarely needed to.

    I your right to have your reasons. They give context to I quote you :quote:The advantage Javassist has over other bytecode frameworks is its embedded java compiler:/quote:
  8. javassist[ Go to top ]

    I have to agree with Bill here. I am using Javassist in Chameleon mainly because I did not want to learn byte. In my particular case, my compilations are done once at startup so any overhead there is a non-issue for me. The fact that I can actually 'write' source code and have it compiled was a huge plus.

    I've also used Janino for the same reasons.
  9. Class generation[ Go to top ]

    I should probably clarify in saying that I'm not manipulating existing classes but rather I am generating new ones at runtime. Even so, I know that javassist can do manipulation.
  10. Size matters[ Go to top ]

    There are number of quite mature projects that are using ASM, but I wonder what projects are using Javassist? I know that some projects recently made an efford to remove dependency to Javassist, but really it would be interesting to hear some success stories.

    I'm sorry if it this is sound like a nasty comment, but Javasisst home page does not provide much information. Also I wasn't able to find examples how to work with Java 5 annotations using Javassist.