My earliest start of JavaOne 2010 so far was on Tuesday morning to attend Hamlet D'Arcy's "Code Generation on the JVM" presentation. Several attendees arrived late, indicating the early hour was a surprise for a few. One of Hamlet's colleagues (Andres Almiray I believe) presented in his place. He started by saying that Groovy would be used during the presentation (one of the reasons I wanted to attend!) and asked if anyone didn't know what Groovy is. No one in this relatively full room raised their hand.
The speaker listed some longer term examples of code generation: CORBA stub generation, bean generation, and WSDL artifacts generation. He mentioned modern code generation tools such as Groovy, Project Lombok, Boo (.NET), Spring Roo, and LISP.
The first code generation product covered in detail was Project Lombok. This library has been featured by the Java Posse and is used to reduce JavaBean boilerplate code. Lombok can be used with Eclipse IDE, but can also be used in conjunction with command-line javac. Lombok works with the javac compiler to modify byte code. The speaker demonstrated the generated JavaBean boilerplate methods (such as "get" and "set" methods) using javap -p (-p to show private fields).
The speaker moved from Project Lombok to Groovy. He showed how little code is needed to create a basic class in Groovy. He showed the equivalent Java code. He then moved onto even more advanced examples, demonstrating Groovy's AST Transformation-based @Delegate annotation, @Lazy annotation (lazy initalization), @Immutable annotation (immutable objects), @Newify (new object without new keyword), @Category (new methods at runtime), @PackageScope (use of protected modifier for Groovy), @Grab (specify dependencies' locations). "One of Hamlet's babies" (@Log) should be available with Groovy 1.8. Other Groovy 1.8 AST Transformation annotations include @Synchronized.
The gcontract project works in Groovy and supports design by contract and uses annotations to specify expected conditions and results. An attendee asked what the difference between this approach and asserts is. The speaker responded that this does use asserts, but I must admit that I think the annotations are more readable and less invasive than using the assertions directly in the code. I prefer to have the annotations regarding method entry and exit contract outside of (before) the actual method itself. The speaker stated that this uses Groovy's 1.7 Power Asserts. Interestingly, this same power assert concept was discussed by Mark Reinhold in conjunction with traditional Java's future in Reinhold's presentation JDK 7 and Java SE 7.
CodeNarc was described as a type of FindBugs for Groovy. The Groovy-based testing and specification framework Spock was introduced. A slide appropriately titled "Java Perversions" demonstrated using Spock to create a Groovy method with a name that includes spaces (a similar example is on the main Spock page). Because it's Groovy, it can be used to analyze/test Groovy and Java applications. Spock assumes assert statements. All of this is possible thanks to Groovy's AST Transformations.
The speaker recommended that AST Transformation not be written by hand. He also differentiated between Local AST Transformations (require annotation to tell compiler) and Global AST Transformations (apply to all). He demonstrated the "Groovy AST Browser" that is part of the Groovy Console. [Note: There is also a web version of AST Browser.]
The ANTLR parser generator was discussed and its use in Groovy was described. See D'Arcy's Groovy ANTLR Plugins for Better DSLs for details.
The original author of the slides and the speaker who delivered the slides both inserted humor into this presentation. For example, I liked the speaker's great quote, "I hope you're not afraid of simple text editors like vi, the only powerful text editor you need." I do like my IDEs, but I also find myself in vim or derivative quite often for certain tasks. I also appreciated the visual reference to the classic Atari 2600 Pitfall game when describing Groovy AST Transformation pitfalls. That was a nice piece of nostalgia for me that served as a great memory device for the subject at hand. I couldn't help but wonder, however, how many of the attendees are too young to be aware of that game.
This was an excellent presentation. If he had not told us, it would have been difficult to realize that the speaker wasn't the presentation's author. This is an advantage of having an experienced speaker as a substitute. The mix of strong content, humor, stories, and cultural photographs made it an engaging and informative experience. This presentation was recorded, so it is likely that it will be available in the near future for viewing.
No comments:
Post a Comment