Patent Application
20090172648
The invention relates generally to program code analysis, and, more specifically, to analyzing byte code.
Interpreted programming languages such as Java™ provide Application Programming Interfaces (hereinafter “APIs”) for identifying and manipulating code level metadata at runtime. Using such APIs, software developers can inspect classes and identify the methods, members, annotations, and so on contained in classes. An API to serve such use cases is provided by the Java™ Platform, Standard Edition. However, the use of this API has certain limitations that make it unsuitable for certain scenarios. For example, for this API to be used to analyze the metadata in a class, the class has to be loaded in the Java™ Virtual Machine (JVM), that is, the class has to be initialized. Another limitation associated with the use of this API is that it can be used on classes only and certain use cases demand complete application archives to be analyzed.
Application servers based on the Java™ Platform, Enterprise Edition 5 (hereinafter “Java™ EE” or “Java™ EE 5”) host and provide services to Java™ enterprise applications (also referred to as “Java™ EE applications”). Such applications are deployed on the server as binary components. The server has to analyze binary components at deploy time so that the components can be deployed and initialized properly. Analyzing binary components is required by Java™ EE 5 because the Java™ EE 5 specification introduces an approach to define metadata directly in components via the use of annotations. Prior to Java™ EE 5, configuration data could only be specified in dedicated extensible Markup Language (XML) files supplied with the application archives. Because Java™ EE 5 permits metadata to be specified in both XML deployment descriptors and annotations, an application server needs to access and analyze both the deployment descriptors and annotations at deploy time. Moreover, the server has to analyze complete application archives to deploy them properly.
A method and system to analyze byte code is described. The method identifies metadata in byte code and constructs a meta model of the analyzed metadata for later reference.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
An embodiment of the present invention is a standalone library able to query class metadata without prior loading of classes in the JVM. The library analyzes source code compiled to binary format, that is, the library analyzes byte code from a number of sources such as application archives, class files, or file system folders. It creates a meta model of the analyzed byte code and after the model is complete, it creates an object to access the created model.
Referring to
The system can also retrieve elements of the model that satisfy given criteria by using filtering, as shown on
Elements in the created model are grouped according to their type and their source. For example, an Enterprise Application Archive (hereinafter “EAR”), contains one or more application modules, such as web modules, web services modules, Enterprise JavaBeans (hereinafter “EJB”) modules, and so on. Each of the application modules is an archive of the respective type. Each archive contains application logic compiled to class files and encapsulated in Java™ Application Archives (hereinafter “JARs”). Consequently, the created meta model models the hierarchy of the EAR, as shown on
Once the model is created, the system can query the model for a specific element using its identifier via the access module 440, or retrieve a number of elements of a given type using the filter module 450. The access module 440 has components to access all types of elements processed by the system, such as methods, constructors, fields, and so on.
In an application server environment, each type of application is hosted and managed by a dedicated container. At deploy time, each container is only interested in the metadata pertaining to the application type it manages so that it can configure and initialize the application. To enable this processing, the embodiment of the invention provides the filter module 450 enabling each container to filter out the metadata it is interested in. For example, the web container filters the meta model for metadata from WARs and uses this metadata to configure and initialize web applications. The configuration information is also used at runtime to provide the desired functionality of the application. The filter module 450 can also provide a subset of the configuration information and is used in both positive and negative semantic. A positive filter retrieves all elements from the meta model that comply with a given condition, for example all elements from a given class. A negative filter retrieves all elements except for ones that satisfy a given condition, for example, all classes from all archives, except for classes from JARs. As the filtering logic is provided centrally, it can be used by any container in an application server without the need for complex custom implementations. This in turn improves system performance and container productivity. Without the filter module 450, a container would have to store all configuration information that is supplied with the deployed component and then implement custom logic to filter out the information it does not need. Such an approach would result in bad code quality and performance drawbacks because of the additional resources each container would need to allocate to deal with filtering.
Components deployed on an application server often contain references to other components or classes that are not part of the components currently being deployed. To initialize the current component correctly, a container needs to access these external components.
To deploy components with dependencies to external components, the system uses a class finder module 660 to load the needed classes on demand. If the class finder 660 module is not present in the system, application developers would have to package all components, dependent components, and external libraries in one package and provide it for deployment. This violates good developments practices and makes applications harder to maintain. Such an approach would result in huge application archives to be processed by containers at deploy time thus decreasing container performance. Also, this would imply providing the same content in many archives thus using more storage resources.
When a client 670 requests the deployed component, it has to be constructed dynamically at runtime. However, if the component has dependencies on classes not found in its archive the object cannot be constructed. To enable the proper functioning of components at runtime, the system uses an object factory 650. The object factory 650 first loads the needed classes on demand using the class finder 660 and only after all needed classes are available attempts to construct the object and pass an instance of it to the client 670.
Systems implementing some embodiments of the present invention are distributed as standalone libraries. As such, they can be used by a variety of components in a variety of use cases. In addition to the use cases noted above, embodiments of the invention can be used to analyze input on a file system. This may be needed in a maintenance scenario where content is obtained and downloaded to a location on a file system prior to being applied to an environment. In such a case, a maintenance tool can use the standalone library to check the obtained content for completeness and dependencies and estimate if all content necessary for the successful execution of the maintenance procedure is available.
Elements of embodiments may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cares, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
