Abstract:
One embodiment of the present invention provides a system for associating metadata attributes with program elements. During operation, the system receives source code containing syntactic elements that specify metadata attributes for program elements, wherein the metadata attributes do not affect program execution. The system then parses the source code to obtain the metadata attributes. Next, the system associates the metadata attributes with corresponding program elements and determines values associated with the metadata attributes. Finally, the system incorporates the metadata attributes, including identifiers for the associated values and the associated program elements, into object code for the program, thereby allowing the metadata attributes to be accessed from the object code. Another embodiment of the present invention provides a system for accessing metadata attributes for program elements from object code through an application programming interface (API).

Description:
BACKGROUND  
         [0001]    1. Field of the Invention  
           [0002]    The present invention relates to the design of programming languages for computer systems and associated development tools. More specifically, the present invention relates to a method and an apparatus for associating metadata attributes that do not affect program execution with program elements.  
           [0003]    2. Related Art  
           [0004]    It is often desirable for programmers to annotate program elements, such as fields, methods, and classes, as having particular attributes that indicate that they should be processed in special ways by development tools, deployment tools, or run-time libraries. We call such annotations “metadata.” Ideally, this metadata should be easily accessible at development time, deployment time, and run time.  
           [0005]    Metadata has many uses. Custom tools may use metadata to generate auxiliary source files to be used in conjunction with the source file containing the annotation. For example, a stub generator can generate remote procedure call stubs based on annotations indicating that certain methods are designed for remote use.  
           [0006]    A number of existing mechanisms presently allow programmers to associate metadata with programs. For example, the C++ programming language has a preprocessor directive called “#pragma” that affects the actions of the compiler as it compiles the program. Some uses of this directive associate metadata with the program. For example, this directive&#39;s COPYRIGHT function associates a copyright string with a program. The copyright string is then embedded in the object code where it can be read with the Unix strings utility. However, the C++#pragma directive does not allow the programmer to associate arbitrary metadata, does not allow metadata to be associated with particular program elements, and does not allow metadata to be read at run time.  
           [0007]    JAVA&#39;s doclet API has been used to associate metadata with program elements by various tools such as ejbdoclet, webdoclet, ejbgen, and icontract. Although this usage does allow the programmer to associate arbitrary metadata with particular program elements, it does not allow metadata to be read at run time, nor does it provide a mechanism to manage the namespace of metadata attributes.  
           [0008]    Hence, what is needed is a facility that allows programmers to associate arbitrary metadata with arbitrary program elements in a manner that allows the metadata to be accessed by development tools, deployment tools, and programmatically at runtime without the limitations of the mechanisms described above.  
         SUMMARY  
         [0009]    One embodiment of the present invention provides a system for associating metadata attributes with program elements. During operation, the system receives source code containing syntactic elements that specify metadata attributes for program elements, wherein the metadata attributes do not affect program execution. The system then parses the source code to obtain the metadata attributes. Next, the system associates the metadata attributes with corresponding program elements and determines values associated with the metadata attributes. Finally, the system incorporates the metadata attributes, including identifiers for the associated values and the associated program elements, into object code for the program, thereby allowing the metadata attributes to be accessed from the object code.  
           [0010]    In a variation on this embodiment, a metadata attribute for a program element is expressed in the source code as a modifier for a declaration for the program element.  
           [0011]    In a variation on this embodiment, a given metadata attribute can contain nested metadata attributes.  
           [0012]    In a variation on this embodiment, a given metadata attribute is defined by a corresponding class for the given metadata attribute.  
           [0013]    In a variation on this embodiment, the corresponding class for the given metadata attribute is located in a package named according to a unique package naming convention. This allows parties to define their own metadata attributes that are guaranteed not to interfere with attributes defined by other parties.  
           [0014]    In a variation on this embodiment, the system additionally validates a given metadata attribute using validation criteria from an object file for a class associated with the given metadata attribute.  
           [0015]    In a variation on this embodiment, determining values associated with the metadata attributes involves evaluating constant expressions.  
           [0016]    In a variation on this embodiment, the object code for the program includes one or more class files for the program.  
           [0017]    In a variation on this embodiment, a program element can include, a method, a class, and or a field.  
           [0018]    One embodiment of the present invention provides a system for accessing metadata attributes associated with program elements. During operation, the system receives object code for a program, wherein the object code contains metadata attributes for program elements; these the metadata attributes do not affect program execution. Next, the system stores the object code in a memory buffer without loading the object code for program execution. The system then accesses the metadata attributes for the program elements from the object code through an application programming interface (API).  
           [0019]    In a variation on this embodiment, the API includes: a method that returns a specified attribute of a specified element; a method that returns all attributes of a specified element; a method that returns all elements having a specified attribute; and a method that returns all elements having a specified attribute-value pair. 
       
    
    
     BRIEF DESCRIPTION OF THE FIGURES  
       [0020]    [0020]FIG. 1 illustrates a computer system in accordance with an embodiment of the present invention.  
         [0021]    [0021]FIG. 2 illustrates the structure of a compiler in accordance with an embodiment of the present invention.  
         [0022]    [0022]FIG. 3 is a flow chart illustrating the process of incorporating metadata attributes for program elements into object code in accordance with an embodiment of the present invention.  
         [0023]    [0023]FIG. 4 is a flow chart of the process of accessing metadata attributes associated with program elements in accordance with an embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0024]    The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.  
         [0025]    The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.  
       Computer System  
       [0026]    [0026]FIG. 1 illustrates a computer system  100  in accordance with an embodiment of the present invention. As illustrated in FIG. 1, computer system  100  includes processor  102 , which is coupled to a memory  112  and to peripheral bus  110  through bridge  106 . Bridge  106  can generally include any type of circuitry for coupling components of computer system  100  together.  
         [0027]    Processor  102  can include any type of processor, including, but not limited to, a microprocessor, a mainframe computer, a digital signal processor, a personal organizer, a device controller and a computational engine within an appliance. Processor  102  includes a cache  104  that stores code and data for execution by processor  102 .  
         [0028]    Processor  102  communicates with storage device  108  through bridge  106  and peripheral bus  110 . Storage device  108  can include any type of non-volatile storage device that can be coupled to a computer system. This includes, but is not limited to, magnetic, optical, and magneto-optical storage devices, as well as storage devices based on flash memory and/or battery-backed up memory.  
         [0029]    Processor  102  communicates with memory  112  through bridge  106 . Memory  112  can include any type of memory that can store code and data for execution by processor  102 .  
         [0030]    As illustrated in FIG. 1, memory  112  contains compiler  116 . Compiler  116  converts source code  114  into object code  118 . In doing so, compiler  116  incorporates metadata attributes that are specified by syntactic elements within source code  114  into object code  118 . This process is described in more detail below with reference to FIG. 3.  
         [0031]    Incorporating metadata into object code enables development tool  120  to access the metadata attributes from object code  118  through an API. This process is described in more detail below with reference to FIG. 4.  
         [0032]    Note that although the present invention is described in the context of computer system  100  illustrated in FIG. 1, the present invention can generally operate on any type of computing device. Hence, the present invention is not limited to the specific implementation of computer system  100  illustrated in FIG. 1.  
       Compiler  
       [0033]    [0033]FIG. 2 illustrates the structure of compiler  116  in accordance with an embodiment of the present invention. Compiler  116  takes as input source code  114  and outputs object code  118 . Note that source code  114  may include any computer program written in a high-level programming language, such as the JAVA programming language. Object code  118  includes executable instructions for a specific virtual machine or a specific processor architecture.  
         [0034]    Compiler  116  includes a number of components, including front end  202  and back end  206 . Front end  202  takes in source code  114  and parses source code  114  to produce intermediate representation  204 .  
         [0035]    Intermediate representation  204  feeds into back end  206 , which produces object code  118 . Within backend  206 , intermediate representation  204  feeds through optimizer  208 , and the resulting optimized intermediate representation  209  feeds though code generator  210  which produces object code  118 .  
         [0036]    During this process, compiler  116  incorporates metadata attributes into object code  118  as is described below with reference to FIG. 3.  
       Process of Incorporating Metadata Into Object Code  
       [0037]    [0037]FIG. 3 is a flow chart illustrating the process of incorporating metadata attributes for program elements in object code in accordance with an embodiment of the present invention. The system starts by receiving source code for a program, wherein the source code contains syntactic elements that specify metadata attributes for program elements (step  302 ). Note that the metadata attributes do not effect program execution.  
         [0038]    The program elements can include methods, classes or fields that can be associated with attributes. For example, a method can be associated with attributes, such as: (1) a remote attribute that specifies whether the method is a remote method or a local method; (2) a precondition attribute and a postcondition attribute that collectively facilitate “design by contract;” (3) a deprecated attribute which indicates that a given method is supported, but should no longer be used; or (4) a query attribute that facilitates forming a database query for an accessor method.  
         [0039]    A class can be associated with attributes, such as: (1) an author attribute that identifies the author of the class; (2) a deprecated attribute, which indicates that the class is supported, but should no longer be used; and (3) a framework membership attribute that signifies that the class participates in a framework.  
         [0040]    A field can have attributes, such as a persistence attribute, which indicates whether or not the field is persistent. Note that this persistence attribute can be a boolean attribute, or alternatively a multi-valued attribute that specifies a type of persistence.  
         [0041]    Next, the system parses the source code to obtain metadata attributes (step  304 ). In one embodiment of the present invention, a metadata attribute is expressed in the source code as a modifier associated with a declaration for a program element. In this embodiment, each attribute is declared as a class. For example, an interface for a class associated with “deprecated” attribute can have the form,  
                                                                       interface @deprecated extends                Java.lang.BooleanAttribute{                }.                      
 
         [0042]    The deprecated attribute is associated with a program element as a modifier for a declaration for the program element. For example, a class can be associated with both the deprecated attribute and the author “Mickey Mouse” in the following way,  
                                                   @deprecated       @author(“Mickey Mouse”) public static final class Foo extends Bar {                public static final void main {           }            }.                  
 
         [0043]    Note that in the above example, a modifier associated with an attribute can be easily identified by “@” symbol. Also note that multiple attribute modifiers can be associated with a given declaration.  
         [0044]    Attributes can also be nested. For example, a “remote” attribute for a class can the specified as follows,  
                                                                       @remote(                @comstyle(“Corba”),           @timeout(10),                ) &lt;&lt;method declaration&gt;&gt;.                      
 
         [0045]    This nested remote attribute specifies that the communication style for the remote method is “Corba” and that the timeout period for the remote method is 10 seconds. Note that this information can be used by a programming tool to build a stub for the remote method.  
         [0046]    An interface for a class that defines the nested “remote” attribute can have the form,  
                                                                                                               public interface @remote extends CompoundAttribute {                public interface @comstyle                extends java.lang.StringAttribute{ }                public interface @timeout                extends java.lang.IntAttribute{ }                . . .                 }                      
 
         [0047]    Note that by placing the classes that define the attributes in packages named according to a unique package naming convention like the one described in Section 7.7 of the Java(tm) Language specification, Second Edition (Gosling, Joy, Steele, Bracha; Addison-Wesley 2000), the present invention can leverage off the existing namespace management features enabled by the convention. Hence, unrelated parties can define their own classes for their own attributes, and these classes can be located within their own portions of the package namespace. This allows unrelated parties to define different attributes using the same name without interfering with each other.  
         [0048]    Next, the system determines values associated with the metadata attributes, which may involve evaluating constant expressions (step  306 ). After or during the parsing process, the system can validate the metadata attributes (step  308 ). In one embodiment of the present invention, this involves using validation criteria retrieved from an object file for a class that defines a given metadata attribute to validate the given metadata attribute.  
         [0049]    The system then associates metadata attributes with corresponding program elements (step  310 ). The system then incorporates the metadata attributes, including identifiers for associated values and associated program elements, into object code (class files) for the program (step  312 ). In one embodiment of the present invention, the metadata attributes are stored as “class file attributes” in a JAVA class.  
       Process of Accessing Metadata Attributes From Object Code  
       [0050]    [0050]FIG. 4 is a flow chart of the process of accessing metadata attributes associated with program elements in accordance with an embodiment of the present invention. This process can take place either at run time (while the class is loaded), or at design time (while the class is not loaded).  
         [0051]    If the process takes place during run time, one embodiment of the present invention adds an accessor method to class Class for each primitive type attribute. For example, we can add the following accessor methods to class Class,  
         [0052]    String getStringAttribute(name of attribute), and  
         [0053]    int getlntAttribute(name of attribute).  
         [0054]    These accessor methods can be used to retrieve a string and an integer, respectively. For example, “Foo.class.getStringAttribute@author.class)” returns a string for the attribute “author” during run time. However, note that in order to do this the class literal “Foo.class” must be evaluated, which requires loading the class.  
         [0055]    If the process takes place during design time, one embodiment of the present invention provides an application programming interface (API) to obtain metadata associated without program elements without having the load the class.  
         [0056]    The process operates as follows. Upon receiving object code for a program (step  402 ), the process loads the object code into a memory buffer—without performing the time-consuming verification operations involved in loading the class into a virtual machine (step  404 ). Next, the process accesses metadata attributes for program elements through an API (step  406 ).  
         [0057]    Note that API can be defined as a class. For example, the class can include methods to: (1) return a specified attribute of a specified element; (2) return all attributes of a specified element; (3) return all elements having a specified attribute; (4) return all elements having a specified attribute-value pair; (5) return a specified sub-attribute of a complex attribute; and (6) to return all sub-attributes of a complex attribute.  
         [0058]    The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended