Freely Annotating C#

Walter Cazzola, DICo - Department of Informatics and Communication, Università degli Studi di Milano, Italy
Antonio Cisternino, Department of Computer Science, Università degli Studi di Pisa, Italy
Diego Colombo, IMT - Istituzione Mercati Tecnologie, Alti Studi Lucca, Italy

ARTICLE

PDF Version

Reflective programming is becoming popular due to the increasing set of dynamic services provided by execution environments like JVM and CLR. With custom attributes Microsoft introduced an extensible model of reflection for CLR: they can be used as additional decorations on element declarations. The same notion has been introduced in Java 1.5. The annotation model, both in Java and in C#, limits annotations to classes and class members. In this paper we describe [a]C#^a, an extension of the C# programming language, that allows programmers to annotate statements and code blocks and retrieve these annotations at run-time. We show how this extension can be reduced to the existing model. A set of operations on annotated code blocks to retrieve annotations and manipulate bytecode is introduced. We also discuss how to use [a]C# to annotate programs giving hints on how to parallelize a sequential method and how it can be implemented by means of the abstractions provided by the run-time of the language. Finally, we show how our model for custom attributes has been realized.

Keywords: Reflection, Code Annotation,.NET,C#.

1 INTRODUCTION

Reflection and dynamic loading are becoming essential elements of modern programs. Their usefulness is testified, for example, by the JDBC architecture that shows how to implement a driver-based architecture exploiting the Java dynamic loading.

Although reflection can be used to inspect the structure of types, to access fields and even to invoke methods dynamically, the concept of tagging has been anticipated as an interesting application. Consider for instance the Java serialization architecture: the programmer can declare the instances of a class simply by implementing the Serializable interface, which in fact is an empty interface. Thus, two types that differ only for the implementation of the Serializable interface are indistinguishable from the execution standpoint. Besides, the serialization of the instances of non-serializable types will not be allowed by the serialization support. Java serialization taught us that the meta-data stored with the code can be used for other purposes than mere execution. Other programs may rely on the reflective abilities of inspecting the compiled types and act differently depending on what they have found.

Although widely used by Java programs, the idea of providing explicit meta-data support for annotation has been introduced first by Microsoft in the common language run-time (CLR). The virtual execution environment is part of the standard Common Language Infrastructure (CLI) [14] and a crucial element of the .NET initiative. The CLR executes code expressed in an intermediate language (IL) like the JVM bytecode, though the code is stored and distributed in the form of an assembly. A single assembly contains the definition of one or more types and may refer to other assemblies. Together with the meta-data, required by the CLR for loading and managing the types contained within an assembly, it is possible to store arbitrary information in the form of custom attributes. A custom attribute is an instance of a class that inherits from the Attribute class. A custom attribute is created by invoking one of its constructors, though all the values used to create it must be computable at compile time. Custom attributes are serialized into an assembly at compile-time and ignored by the execution system. Nevertheless, the reflection API provides a means to retrieve these attributes at run-time. For instance, let be an instance of MethodInfo (a reflective descriptor of a method). In C# we can retrieve the custom attributes associated with the method as follows:

In the CLR model attributes can be used to decorate essentially all the objects accessible through reflection: assemblies, types (delegates, value types, and classes), fields, properties, and methods.

Problem Description.

The crucial idea behind the custom annotations consists of shifting up data about the code into the executable and to render them available at run-time. Custom annotations are interpreted by programs and are used for program transformation.

Microsoft .NET provides support for implementing web services by means of custom attributes. A custom attribute named WebMethod is used to label methods that should be exposed as web services. A minimal web service written in C# that computes the sum of two integers is the following:

Once compiled, the HelloWorldWS class does not provide any web services interface. A different program - actually part of the Internet Information Server - is responsible for looking up reflection information within assemblies and generating a SOAP/WSDL interface to the method add() over HTTP.

A significant limit to the annotation model introduced by the CLI is the granularity of annotations: they can only be used on methods and not inside them to annotate code blocks. This limitation is partially bound to the provided reflective model that does not permit to reify blocks of statements. Several programs whose goal consists of administering and manipulating other programs would benefit from a finer grained model for annotations.

In this paper we present [a]C#, an extension to the C# programming language supporting custom annotations on arbitrary code blocks or statements. The language extends the syntax of the C# language to allow a more general form of annotation and provides a run-time library that extends the reflection support with operations for retrieving the information about annotations inside methods.

It might not be evident that this finer grained model for custom annotations of code can be of any use, thus we provide a detailed example of how custom annotations and [a]C# can be used to render parallel a sequential C# program. In particular, we discuss the general operations that can be used on annotated code blocks, which hide from the programmer the complexity of manipulating intermediate language instructions explicitly.

We also present the implementation of the compiler, which is realized as a source to source translator. In particular, it is interesting how the compiler reduces the extended model for custom annotations to the existing one with the help of small modications of the generated intermediate language.

2 [a]C# IN A NUTSHELL.

[a]C# extends the original language by allowing the use of custom attributes inside a method body.

In the example, we have defined two attributes, MyAnnotationAttribute and AnotherAnnotationAttribute, that we will use for annotating the method body. They inherit from ACS.CodeAttribute rather than from the System.Attribute class.

Inside the method Main() we use these two annotations and, as it is usual in C#, we omit the suffix within square brackets. Inside a method body custom attributes can be used before statements or code blocks delimited by braces.

The ability of putting custom annotations into methods is of little use without any means to retrieve the information the programmer has specified using the annotations. How can a tool retrieve annotations from an assembly? The run-time of the language (a library linked to the program resulting from the source to source transformation) provides the method GetCustomAttribute() to look at the method code for custom attributes:

Although we cannot extend the reflection library, this method should be considered as belonging to the MethodInfo class: given a method reification, it returns all the annotations associated with it (if present) by reflective inspection.

The retrieved annotations are stored into a forest. Each tree represents a group of nested annotations rooted at the outermost one, whereas each node represents and stores information about a single annotation. Nested annotated blocks are sub-trees of the node representing the outer annotation sorted as they appear.

Although, to be able to retrieve annotations related to a single method body is often enough, there are still situations where a broader view is necessary. For example, consider a tool whose aim consists of performing the static analysis of a program by means of pre and post conditions. In this case, the annotation tree of a single method can be of little use because the conditions about the program's state do not only depend on a method body but also on the methods it calls. The rec argument of GetCustomAttributes() serves this purpose: if true the returned annotation forest represents the closure of the annotations attached to the specified method body and, recursively, of the annotations attached to body of the methods it calls. In this case, the leaves at a given level epresent both nested annotations and annotations attached to the body of methods called in the scope of the annotations in the upper level.

The [a]C# run-time provides operations to manipulate the intermediate language instructions within the scope of annotations. These operations are:

Extrusion: is used to extrude the annotation by generating a new method whose body and arguments are respectively the annotated code and the free variables of the annotation;
Injection: is used to insert code immediately before and after an annotation;
Replacement: is used to replace the annotated code with the specified code.

All these operations can feed an ILGenerator that generates the body of a method. A tool can generate new methods, which are a translated version of the original ones, using these high level operations, without the need for explicitly manipulating IL instructions.

Code injection simply requires an stream that corresponds to a method m with a signature void m(). This operation is useful for tools like aspect weavers. The same can be done for replacement. A variant of injection and replacement allows the generated code to access the same variables used by the code block target of the operation.

3 CASE STUDY: TO PARALLELIZE A METHOD.

To render parallel a program provides a good example of application of our model for custom annotations of code blocks. Suppose we are interested in giving hints about how to parallelize the execution of a method. Of course, these hints can be ignored and the method is executed sequentially. On the other hand, specific tools could recognize these annotations and transform the method consequently.

We have chosen this case study because it offers a relevant application domain where the [a]C# annotations schema proves to be useful. In our case study we focus on the code manipulation aspects rather than on the techniques to render it parallel.

The Used Annotations.

With the standard model of custom attributes it is possible to specify information about a method, but there is no easy way to indicate which portions of its body can be run in parallel: in this case the information about the scope of the annotation is required. We introduce the following annotations:

These definitions must be known by the programmer who uses them to annotate the code, and by tools that understand them and behave depending on the annotations. Note that we provide a constructor that allows the user to specify some descriptive text to be included with the annotation. Note that we use the names Parallel and Process for the annotations, but this does not imply by any means that parallelism is achieved through system processes. In general it is the tool that defines the semantics of annotations by manipulating the annotated code.

Annotated Code.

A method annotated with these annotations may look like the following:

Listing 1: Hints for Parallelizing a Method

We notice that a sequential computation can be annotated by declaring portions of code that can be executed either sequentially or in parallel. If we execute the method m, as specified by the CLI virtual execution system, annotations are ignored and the code is executed sequentially. A tool capable of understanding the annotations Parallel and Process is required, as in the case of web services implementation based on the WebMethod attribute. This tool will be responsible for giving a semantics to the annotated methods.

Giving Semantics to Annotations.

In the domain of parallel execution we can even think of a JIT compiler aware of these annotations leading to better performing code. Nevertheless, an off-line approach can be also followed: a tool can read the method m in its binary form from the assembly where it lies; and it can generate a new assembly with a method whose body has been translated so that its execution will be rendered parallel according to the annotations. Our tool will give semantics to the annotations as follows:

Parallel: a block annotated with this attribute denotes a scope within the code, where the blocks annotated with are executed in parallel. When the execution control reaches the end of the block, all the processes spawned within should have finished their activity.
Process: the code within a Process block is executed by a separate execution thread. In our implementation the code is responsible for ensuring that the access to shared variables does not cause race conditions.

The transformation schema we have adopted for transforming an annotated method m in its parallel form relies on the asynchronous methods support provided by CLI through delegate objects. Given a delegate object (wrapping a method) it is possible to invoke the corresponding method by calling the method BeginInvoke(). A thread is taken from the ThreadPool to execute the method referred by the delegate and the result of the invocation is an object representing the running method. The main thread calls the method eginInvoke() for each Process block. At the end of the Parallel block a WaitAll() method call is performed to wait for all the asynchronous methods to complete, then the execution continues with the single thread.

Our tool relies on the operations provided by the [a]C# run-time for implementing this code transformation, as follows:

for each Parallel block (obtained from the GetCustomAttributes() method):
- it extrudes a method for each Process block within its scope;
- it generates a delegate type for the extruded methods;
- an asynchronous call to a delegate wrapping the extruded method replaces the corresponding Process block;
finally, it injects a call to the method WaitAll() with the references to the handlers of each extruded method.

The algorithm shows how the operations defined in [a]C# run-time are useful for transforming the code.

Unbound Process Spawning.

At first sight it may be thought that the annotations we have introduced allow only expressing a fixed number of processes to be spawned by the translated code. This is not true: in our transformation schema, if we annotate the body of a loop the main thread will spawn an asynchronous method for each execution of the body. We consider the classic example of paralleling the rendering of Mandelbrot fractals (see [9]). Our goal is to draw the fractal by using four threads, one for each fourth of the drawing area.

Of course we could repeat four times the code needed to draw a single portion and annotate the four blocks as Process. Although this approach works it requires us to replicate a portion of code. Thus, to avoid code replication, we introduce a loop that repeats four times the code that draws a region of the fractal. The resulting code is the following:

The Mandelbrot method computes the fractal given a region in the complex plane (bound by the two complexes z1 and z2). The algorithm implemented subdivides the complex plane in four regions (whose upper left corners are contained in the rects array), and performs the classic Mandelbrot algorithm on each of these. We used the Process annotation on the block of the first statement. Accordingly toour transformation schema, the block will be replaced by the invocation of an asynchronous method. Note that the code can also be executed as it is; in this case the four regions will be drawn in sequence rather than in parallel.

The spawning of asynchronous methods in the example is known (though not reading the annotation); a variant of the algorithm may determine at run-time the number of regions that should be drawn in parallel.

Final Considerations.

The annotations we used to render parallel sequential methods introduce a form of parallelism with shared memory. The variables, defined outside the scope of the Process attribute, are shared among processes (which in fact are threads) though the tool does not provide any form of automatic synchronization. The variables defined inside the scope of the Process attribute are local to the process itself.

Without our extensions the standard model for annotations would not have been enough for expressing scopes inside method bodies. However, some may wonder if the employment of different techniques would have led us to the same result.

An alternative approach to compute the Mandelbrot set in parallel could consist of employing a tool performing source to source transformations. The disadvantage of this approach is that, unless the tool implements a full parser for the C# language, a shallow parsing approach would have been more error prone than ours that simply has to detect and retrieve the annotations. Moreover, annotations in the binary code allow different languages to benefit from the tools written to use them. Finally, the decision of transforming the program or of executing it sequentially can be postponed and the transformation can be adapted to the particular machine where the program will run.

4 COMPILER IMPLEMENTATION

The [a]C# compiler has been implemented as a source to source compiler, reducing our enriched model to the standard model for code annotation. We believe that our approach in the realization of the compiler is another contribution of this paper in two ways: first of all we show how the more expressive code annotation schema proposed by [a]C# can be reduced to the existing annotation model combined with a particular coding convention schema; the transformation engine constitutes a second contribution because of its general structure based on a full parser rather than on a shallow system.

Representing Code Annotations

As already discussed, the existing model for custom annotations cannot keep track of the attributes' scope within the body of a method. Nevertheless, the execution environment already provides all the machinery to support annotations.

We have considered extending the virtual machine by modifying Rotor [15]. Although feasible, the problem of this approach is that the code generated by our compiler would have been compatible only with the modified version of the runtime. Thus, we have decided to encode information about ranges of code annotations by inserting placeholders into the bytecode. As shown in [3, 4], we used a call to a dummy method to indicate the beginning and the end of an annotated block. Annotations are lifted onto methods and indices are used to preserve the binding between dummy method calls and the relative annotations.

Consider, for instance, the [a]C# code in Listing 1. The [a]C# compiler transforms it into the C# equivalent method:

We rely on a language feature provided by custom attributes in C#: the constructor of a custom attribute allows specifying named arguments after the standard arguments. Each named argument corresponds to the assignment to a class property. In the previous example the second Process attribute is instantiated calling the parameterless constructor, and then the ACSIndex property of the instance is set to the value 3.

Classes defining code annotations must inherit from ACS.CodeAttributes class. Through this class we are able to inject the ACSIndex property into all the code annotations, allowing the transformation system to preserve the association between the attribute lifted to the method and its scope. The definition of the base class for code annotations is:

The class CodeAttribute inherits from Attribute. This allows to use its instances as custom attributes in C#. The data about the scope of the annotation are stored within the compiled IL.

The language run-time support is responsible for retrieving the information stored within the executable file in the form of custom attributes plus the Begin/End method invocation pairs.

A finite state automaton reads the method body looking for method calls to the static methods Begin() and End() of the Annotation class. When the appropriate instruction is found the automata looks for the instruction used to load the integer arguments on the arguments stack and used to relate the method call to the scope defined by an attribute.

The invocation of the GetCustomAttributes() method causes the language runtime to analyze the method body and fill the reflection objects used to describe the annotation tree. The AnnotationTree class is used to retain not only the attribute object, but also the information needed to locate the begin and the end of the intermediate language instructions within the annotation's scope.

The indices used as arguments to Begin() and End() methods are used to associate the scope with the corresponding custom attribute. It is worth noting that the annotations generated by the [a]C# compiler can be consumed by all the languages targeting the CLI execution environment.

Annotations and Run-time Execution

Our translation schema introduces method calls into annotated programs. It is natural to ask whether these calls may introduce performance hits with respect to their non-annotated versions. One of the most important assumptions of code annotations is that the execution of an annotated program should run as fast as the same program without the annotations. Besides, we rely on fake method calls to preserve the scope of annotations. Therefore, it is natural to wonder if these IL instructions may introduce inefficiencies when the container method is executed.

It is worth noting that the called methods are static and empty. A JIT compiler can easily avoid generating the call instruction by simple inlining strategies. Nevertheless, they might generate a call instruction in the code generated by the JIT compiler. As a matter of fact all the non trivial JIT compilers perform inlining and are capable of removing the method call at JIT time. This is the behavior of the Microsoft .NET JIT, and of the Mono JIT. The Rotor JIT is very trivial and emits the call instruction.

Another issue we may think of is: does the compiler eliminate the method call to optimize the generated code? The answer is negative: the compiler links the method that is already compiled in a different assembly. Thus, it does not know the actual definition of the method demanding this optimization at later stages in the execution pipeline. Moreover, it cannot change the position of the method call inside the method body because it cannot establish whether the static method will perform side effects that may lead to a different semantics. Besides, the JIT compiler will have full knowledge of the code to be executed and will perform these optimizations if possible.

We conclude that it is reliable to insert method calls and look for them in the binary output to find the boundaries of custom annotations. Moreover, in any reasonable implementation of the CLI standard the annotations would not affect the performance of annotated programs at all. Other compilers may support the same mechanism by simply adopting the same conventions when generating code and linking the [a]C# run-time library.

CoCo/R and the C# Transformation System

The [a]C# compiler transforms an annotated program into a standard C# program using the transformation schema previously illustrated. A few transformations are necessary but they require information about the program structure: attributes must be extended with the ACSIndex value, though the existing arguments should be preserved. Moreover, attributes should be lifted on the method they are used. A shallow approach to program transformation is, in this case, risky and error prone. We decided to rely on a full parser of the C# 2.0 [1] syntax. Fortunately, the CoCo/R project [18] produced a parser generator for C# and a full annotated grammar for the language.

The C# annotated grammar has been modified in order to obtain a parser that parses an C# program and rewrites it. The buffer where the output is stored provides operations to insert marks within the code, and then to insert text in a marked site. Thus, we obtained a transformation system for C# that performs full syntax parsing to implement code transformation patterns.

The [a]C# compiler has been developed by changing this transformation system (that implements the identity transformation). As an example, we include two productions of the annotated grammar (semantic actions are delimited by "(." and ".)"):

The first production defines the body of a class; we mark the output buffer ob with a label called ACS each time we encounter a member of the class. This mark is used to insert the attributes found while parsing the method body.

The second production defines a statement of the language; it has been extended with a case for statements with attribute. In the associated action we see that we inject the attribute definition where the ACS mark lies in the output buffer.

We derived the transformation system by customizing a generic C#-to-C# rewriting system based on the CoCo/R parser. The transformations needed by the [a]C# compilation strategy cannot be achieved without full understanding of the source code: the compiler needs to have information about types in order to ensure that code annotations are of types derived from CodeAttribute and that the attribute lifting process preserves the semantics of the original program. The whole annotated grammar and the whole source code of the [a]C# compiler is available as part of the CodeBricks project¹.

Programming Tools

A well-known problem with source to source tools is that the programmer manipulates a source file different from the one the compiler deals with. Fortunately, C# re-introduced (similar to the C/C++ preprocessor directive) the #line directive. Thus, we annotate the lines of the generated C# file with the reference to the line in the original source. This is important because in the process of parsing and rewriting the source code we loose the original formatting of the code.

As a consequence, the whole programming infrastructure, ranging from the compiler to the debugging tools, is capable of supporting the real source code rather than the one generated by the translator.

The command line version of the [a]C# compiler is just a front-end to the standard C# compiler: it preprocesses all the files with .acs extension and then passes all the file names of the generated files to the C# compiler. The front-end allows mixing .acs and .cs files.

We have also integrated the [a]C# compiler in Visual Studio.NET 2003. The Visual Studio programming environment includes the notion of a custom tool. A custom tool is a preprocessor that the programming environment runs before starting the compilation process. A custom tool is a COM component implementing a set of interfaces that the editor uses to manage the code generator. We developed the custom tool as a .NET library exposed as a COM component using the interoperability facilities of the execution environment. We have also added wizards to the programming environment so that the creation of attributes and [a]C# files is supported by the programming environment.

5 RELATED WORK.

Code annotation, in several different forms, is not a new idea and is largely used in several contexts. Some of the most interesting applications are related to code instrumentation, analysis and documentation. Mainly, they have been used to enhance the flexibility and the efficiency of the compiling step and to support new language features, see [10, 11, 12].

Code generation is another of the most diffuse application for code annotations. The XDoclet² tool [17] for Java has been successfully used for performing code generation tasks. The tool relies on comments similar to those used by Javadoc to annotate programs, and then the ant³ building tool is used for controlling the code generation. This approach to code annotation is based on source code manipulation: XDoclet comments are used by Java modules to generate Java source code. On the other hand, [a]C# provides operations to retrieve annotations at run-time on executable files without any need for a whole compilation infrastructure to be available at run-time.

Program manipulation with bytecode transformation is a technique that has been employed in several applications [13, 16]. There are also attempts to raise the abstraction level of this bytecode manipulation. The Javassist [6] library attempts to provide the programmer with operations that do not require knowledge on the underlying bytecode. However, the Javassist approach still focuses on the manipulation of single instructions like method calls, field accesses and so on. We are trying to build meta-programming abstractions that have coarser grain though focus more on the behavioral aspect of the code. Operations such as extrusion, injection and replacement can be type checked and provide the programmer with operations that recall the Lego bricks: "take this block of code and put it here". As a matter of fact the CodeBricks library [2,4] performs similar tasks using entire methods as the unit for code manipulation.

Code annotation is becoming more and more relevant also in the novel aspectoriented technology. Alice [7, 8] is an aspect-oriented based approach that exploits annotations to provide additional meta-information about components they are associated with. The annotations identify components' constraints and requirements that the weaver has to consider. In [5], the annotations are used to mark the join points inside the bytecode with the high-level specification to simplify the join point selection. Both examples could benefit from an annotation model that supports block-level annotations (as the one provided by [a]C#).

6 CONCLUSIONS AND FUTURE WORK

In this paper we have presented [a]C#, an extension of the C# language that allows custom annotations inside method bodies. The run-time library of the language extends the .NET reflective information by providing operators to retrieve custom annotations and to manipulate the annotated code blocks in their binary form.

We have presented a case study in the domain of code parallelism. The aim of the exercise was to show how a well-known problem can be faced by writing an external tool that manipulates a program rather than extending a programming language. We have also shown how the operations provided by the language are used to transform a method into its parallel version.

The compiler has been implemented as a source to source transformation. Nevertheless, we avoided the shallow approach by adopting a full C# parser that rewrites the program after parsing. We have been able to transform the program during parsing and reduce the extended model for code annotations to the one already present in .NET. We have encoded the annotations' scope by inserting dummy method calls at the beginning and at the end of each block.

The compiler is still in its early stage, and the run-time of the language should still evolve. The operations for manipulating bytecode still expose some of the complexity of the underlying execution environment. Moreover, we are considering the possibility of integrating the CodeBricks library [4] into the language run-time. In this way we could expose annotated code blocks as code bricks that can then be mixed to work as basics for the operations provided by the library.

We believe that code annotations can be useful to develop software that meets the always increasing demand for flexibility and dynamic adaptation. We are exploring the possibility of using code annotations to describe the behavioral aspect of components. In particular, in the embedded device domain, devices may give the code to access them (as it is in Jini) annotated with a description of the operations performed by methods.

Footnotes

^a The name[a]C# should be pronounced as annotated C sharp.

¹ See at: http://www.robotics4.net/Software/ACS.aspx

² See at: http://xdoclet.sourceforge.net/xdoclet/index.html

³ See at: http://ant.apache.org

REFERENCES

[1] Tom Archer and Andrew Whitechapel. Inside C#. Microsoft Press, second edition, 2002.

[2] Giuseppe Attardi and Antonio Cisternino. Multistage Programming Support in CLI. IEE Proceedings Software, 150(5):275-281, October 2003.

[3] Giuseppe Attardi, Antonio Cisternino, and Diego Colombo. CIL + Metadata> Executable Program. Journal of Object Technology. Special issue: .NET: The Programmer's Perspective: ECOOP Workshop 2003, Vol. 3 No. 2:19-26, 2004. http://www.jot.fm/issues/issue_2004_02/article2

[4] Giuseppe Attardi, Antonio Cisternino, and Andrew Kennedy. Code Bricks: Code Fragments as Building Blocks. In Proceedings of 2003 SIGPLAN Workshop on Partial Evaluation and Semantic-Based Program Manipulation (PEPM'03), pages 66-74, San Diego, CA, USA, 2003.

[5] Walter Cazzola, Sonia Pini, and Massimo Ancona. AOP for Software Evolution: A Design Oriented Approach. In Proceedings of the 10th Annual ACM Symposium on Applied Computing (SAC'05), pages 1356-1360, Santa Fe, New Mexico, USA, on 13th-17th of March 2005. ACM Press.

[6] Shigeru Chiba and Muga Nishizawa. An Easy-to-Use Toolkit for Efficient Java Bytecode Translators. In Frank Pfenning and Yannis Smaragdakis, editors, Proceedings of Generative Programming and Component Engineering (GPCE'03), LNCS 2830, pages 364-376, Erfurt, Germany, September 2003. Springer.

[7] Michael Eichberg. Component-Based Software Development with Aspect-Oriented Programming. Journal of Object Technology, Vol. 4 No. 3 :21-26, April 2005. http://www.jot.fm/issues/issue_2005_04/article3

[8] Michael Eichberg and Mira Mezini. Alice: Modularization of Middleware Using Aspect-Oriented Programming. In Thomas Gschwind and Cecilia Mascolo, editors, Proceedings of the 4th International Workshop on Software Engineering and Middleware (SEM04), LNCS 3437, pages 47-63, Linz, Austria, September 2004. Springer.

[9] Benoit Gennart and Roger D. Hersch. Computer-Aided Synthesis of Parallel Image Processing Applications. In Proceedings of the Conference on Parallel and Distributed Methods for Image Processing, pages 48-61, Denver, USA, 1999.

[10] Brian Grant, Markus Mock, Matthai Philipose, Craig Chambers, and Susan J. Eggers. Annotation-Directed Run-Time Specialization in C. In Proceedings of the 1997 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-based Program Manipulation (PEPM'97), pages 163-178, Amsterdam, The Netherlands, June 1997. ACM Press.

[11] Andreas Hartmann, Wolfram Amme, Jeffery von Ronne, and Michael Franz. Code Annotation for Safe and Efficient Dynamic Object Resolution. Electronic Notes in Theoretical Computer Sciences, 82(2), 2003.

[12] Raimund Kirner and Peter Puschner. Classification of Code Annotations and Discussion of Compiler-Support for Worst-Case Execution Time Analysis. In Proceedings of the 5th Euromicro International Workshop on Worst-Case Execution Time Analysis (WCET'05), Palma, Spain, July 2005.

[13] Hidehiko Masuhara and Akinori Yonezawa. Run-time Bytecode Specialization: A Portable Approach to Generating Optimized Specialized Code. In Proceedings of Programs as Data Objects, Second Symposium, PADO'01, 2001.

[14] James Miller. Common Language Infrastructure Annotated Standard. Addison-Wesley, November 2003.

[15] David Stutz, Ted Neward, and Geoff Shilling. Shared Source CLI Essentials. O'Reilly, March 2003.

[16] Éric Tanter, Marc Ségura-Devillechaise, Jacques Noyé, and José Piquer. Altering Java Semantics via Bytecode Manipulation. In Don S. Batory, Charles Consel, and Walid Taha, editors, Proceedings of Generative Programming and Component Engineering (GPCE'02), LNCS 2487, pages 283-298, Pittsburgh, PA, USA, October 2002. Springer.

[17] Craig Walls and Norman Richards. XDoclet in Action. Manning Publications, December 2003.

[18] Albrecht Wöÿ, Markus Löberbauer, and Hanspeter Mössenböck. Compiler Generation Tools for C#. IEE Proceedings Software, 150(5):323-327, October 2003.

About the authors

		Walter Cazzola (Ph.D.) is currently an assistant professor at the Department of Informatics and Communication (DICo) of the Università degli Studi di Milano, Italy. His research interests include reflection, aspect-oriented programming, programming methodologies and languages. He has written and has served as reviewer of several technical papers about reflection and aspect-oriented programming. He can be reached at cazzola@dico.unimi.it
		Antonio Cisternino is research fellow at the Dipartimento di Informatica of Università di Pisa. His current research is on run-time code generation and multi-stage programming on execution environments like JVM and CLI. He can be reached at cisterni@di.unipi.it
		Diego Colombo is PhD student at IMT Lucca. He is interested in robotics, computer vision, 3D graphics and Game Design. He can be reached at colombo@imtlucca.it

Cite this article as follows: Walter Cazzola, Antonio Cisternino and Diego Colombo, "Freely Annotating C#", in Journal of Object Technology, vol. 4, no. 10, Special Issue: OOPS Track at SAC 2005, Santa Fe USA, December 2005, pages 31-48, http://www.jot.fm/issues/issues 2005 12/article2

Previous column