InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Aspects: An Easy Tool for Annotation Handling?

Posted by Srini Penchikala on Sep 08, 2008

Sections
Development,
Architecture & Design
Topics
Java ,
AOP ,
Architecture
Tags
Annotations ,
Metadata ,
Aspect Oriented Programming ,
AOP

While many think of Aspects for cross-cutting concerns such as transaction management, caching, persistence, role based security etc, Ramnivas Laddad says another key value for them is as an enabler for Annotations for ordinary projects.

Annotations, added in Java SE 5.0 as Java Metadata facility (JSR 175), provide a way to add metadata to program elements. They are used to configure containers, describe persistence configuration, set security roles, and are defined by nearly every recent JSR standard. They also include a mechanism for adding custom annotations to the Java code, as well as providing a programmatic access to metadata annotation through reflection.

Aspect-oriented Programming (AOP) has been used to implement cross-cutting concerns ranging from simple a use case like logging to advanced use cases like application security and transaction management. Using Aspects as a way to implement annotation handlers is a different way to think of them than as the traditional architect's "cross cutting concerns" view. Ramnivas talked about leveraging Annotations with Aspects and AOP on using custom annotations to add cross-cutting behavior to Java applications. He discussed what metadata and AOP bring to each other. Metadata brings additional information to selecting join points where Pointcuts use annotations to capture join points. It also helps in creating loosely-coupled aspects in certain use cases. And AOP brings a systematic way to consume and supply annotations. Supplying metadata using AOP also gives the benefit of uncluttering code. Consuming metadata using AOP has several advantages over using Annotation Processing Tool (APT) option.

Ramnivas cautioned that the use of metadata to extend the Java language can be both powerful and dangerous. On the one hand, annotations allow us to add new features to the Java language without modifying the core language, thus making it an open language; in the best-case scenario, principled extensions could overcome some of the limitations of the host language. On the other hand, a nonstandard, ad hoc, or incoherent set of annotations could result in incomprehensible code.

One of the best practices of getting most out of AOP is to use to metadata to capture join points for cross-cutting concerns. Keep in mind that Annotations should describe what is true at the join point (condition) - not what should happen at those points (action). He also suggested that the developers use annotations that are already there (like @Entity, @Table, @WebService etc). Consider pointcut without metadata as the first choice and rely on programming elements themselves. Also, avoid implementation-specific annotations. It also heps to understand the cost and benefit of using metadata and AOP together. Metadata can be consumed in a variety of ways, and understanding these uses will help put the combination of AOP and metadata into perspective. Ramnivas covered some of the best practices as well as suggestions for developers on not going overboard with custom annotations in his AOP and metadata articles (Part 1 and Part 2).

The main design considerations in implementing custom annotations are what (metadata, behavior), when (compile time, run-time) and how (APT, Run-time Reflection, AOP) to apply the annotations in Java applications. John Heintz recently did a presentation on adding behavior to Java Annotations where he compared different design techniques to implement custom annotations in Java applications. John discussed byte code transformers, which include Aspects, as one of the three types of Annotation processing options.

  • Generators: This annotation processing option includes reading the source code and generating new source code or modifying existing source code. APT and XDoclet fall into this category.
  • Bytecode Transformers: These annotation handlers parse the class files with Annotations and emit modified classes and newly generated classes. They can also generate non-class artifacts like XML configuration files. Bytecode transformer examples include AspectJ, Spring, Hibernate, CGLib and BCEL.
  • Runtime reflection: This option uses Reflection API to programmatically inspect the objects at runtime. Runtime reflection examples are libraries like Java 5+ reflection and Commons Attributes. Testing frameworks JUnit and TestNG use runtime reflection for processing the Annotations.

InfoQ spoke with John about the role of Aspects in implementing custom Annotations. He said it's really just a balance of forces (engineering trade-offs) that should be taken into consideration when implementing custom annotations. He also mentioned that Aspect-based implementations for Annotations provide the most concise way to implement behavior for annotation and a centralized definition. But the developers must clearly document non-local semantics and the impact on the build or deployment tool-chain (compile or runtime weaving).


Srini Penchikala currently works as Security Architect and has 17 yrs of experience in software product management.

Aspect Oriented Annotations by Bill Burke Posted
Re: Aspect Oriented Annotations by Srini Penchikala Posted
annotations not meta-data by phloid domino Posted
  1. Back to top

    Aspect Oriented Annotations

    by Bill Burke

    I wrote an article in 2004 on Aspect Oriented Annotations and reached the some of same conclusions.



    Because of the fragile pointcut problem that is pervasive in most applications of AOP, I think constraining AOP to solely being an annotation enable might be a good thing.



    Bill Burke

    bill.burkecentral.com

  2. Back to top

    Re: Aspect Oriented Annotations

    by Srini Penchikala

    Hi Bill, My experience has been the same. I have been using Aspects and AOP in Java applications for various use cases for last 3 years and I prefer Aspects to implement the Annotations compared to other approaches (APT, Reflection etc). I think Aspects are relatively less intrusive and less complicated (from the implementation stand-point) design solution for Annotation handling.

    -Srini

  3. Back to top

    annotations not meta-data

    by phloid domino

    Annotations are not meta-data. Think about it. Annotations are embedded in the code, and the code must be re-compiled if changing an annotation.





    Annotations *are* meta-syntax.





    Both have their place, but being clear about the difference can avoid a lot of confusion.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.