Patent Application
20080082974
Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
With reference to
A software component, also referred to as a module, is effectively defined by two sets of application program interfaces (APIs). An API describes the required inputs and resulting output of a software component. The API generally specifies these inputs and outputs in the form of functions, procedures, variables and data structures. The set of APIs that a module requires to execute successfully, that is its prerequisites, are known as its imports. The set of APIs that it provides for use by other modules are known as its exports. Each component has a manifest that comprises a description of the interfaces it depends upon, its imports, and the interface that it offers to other components, its exports. While various software component systems specify their imports and exports differently, in the present embodiment, the common notation used is that adopted by the Eclipse™ Java™ Development Toolkit.
An abridged example from the manifest of a software component is set out below, which implements functionality in a package namespace called ‘java.nio’:
Bundle-SymbolicName: com.ibm.nio
Import-Package: java.io; version=“[1.0.0,2.0.0)”,
java.lang; version=“[1.1.1,2.0.0)”
Export-Package: java.nio; version=“2.1.0”,
java.nio.channels; version=“2.0.0”
The lines starting “Import-Package:” and “Export-Package:” include version dependencies in the form of version numbers written in standard mathematical set notation. To satisfy these versioning dependencies this module requires other components to export APIs for java.io and java.lang packages from version 1.0.0 inclusive, up to but excluding version 2.0.0 for java.io and from version 1.1.1 to version 2.0.0 for java.lang. In turn this component exports two packages to downstream components, each with specific version numbers. The developer of this module has described their exported API for package java.nio as version 2.1.0. Modules importing this package will assume that java.nio remains compatible unless there is a change in the major revision number. Therefore the developer of this module has to be aware that changes made to the code might result in a need to update the version number if the old code is not compatible with the new updated code.
To identify changes in code between one compilation of a given software component and a subsequent compilation of that component, the AVC 203 is arranged to access an abstract syntax tree (AST) 204 produced by the compiler 202 during each compilation of a given component and extract a set of meta data 205 that describes the component's APIs. In the present embodiment, the meta data 205 for each exported API includes each accessible language element in the form of each class, interface, field, as well as each method and each such element's visibility, method return type, parameters, and throws clause. Each set of meta data identifies both the API and its version. The meta data 205 is extracted from the AST 204 each time a component is compiled, thus enabling the meta data 205 for the latest compilation (MD) to be compared to the meta data 205 for the previous compilation (MD′).
Continuing the example above, a sample of the metadata for java.nio (version=“2.1.0”) exported API is as follows:
Contains public class java.nio.ByteBuffer; and
Contains public method ByteBuffer#position with one int argument.
If, between one compilation and the next, the type ByteBuffer were removed from java.nio package, this would result in a breaking change for the importers of this API since they may be relying on the existence of that type. In this case the package export should have its version number updated to java.nio; version=“3.0.0” to denote the breaking change. If, however, the method ByteBuffer#position were to be redefined to take a ‘long’ argument rather than an ‘int’, this would not result in a breaking API change since programs written to call the int version would still work with the version defined as long. This is because the Java™ language rules allow for such a widening of the integer variable. In this case the correct modification to the module metadata would be to define it as java.nio; version=“2.2.0”, indicating that a non-breaking API change was introduced. The rules that determine whether or not a given code change is a breaking change, are referred to as compatibility or equivalence rules and are commonly an integral part of a software language. These rules determine whether or not given software structures or elements are equivalent to one another and therefore compatible. In the present embodiment these rules are in the form of the Java™ binary compatibility rules (JCR) 206.
The processing carried out by the AVC 203 will now be described further with reference to the flow chart of
If, at step 305, a previously extracted meta data (MD′) is identified, processing moves to step 306 where the new and old sets of meta data (MD & MD′) 205 are compared so as to identify any differences in the meta data for APIs having the same version numbers. Processing then moves to step 307 where the Java™ compatibility rules (JCR) 206 are applied to any identified differences in the meta data and processing moves to step 308. If at step 308, none of the rules have been broken then this fact is made available to the user via the UI 201 and processing moves to step 302 and continues as described above. If at step 308 rules have been broken then processing moves to step 309 where the changes to the code and an identification of the associated broken rule are provided to the user via the UI 201. Processing then moves to step 310 where an input from the user is awaited. The user is provided with a choice of either backing out of the offending code changes or updating the version identification of the broken API. Backing out of the change will require recompilation of the software component and reanalysis by the AVC 203. If the user chooses to update the version number there is no need to recompile the component and the new metadata is stored and processing ends.
In another embodiment, the AVC further comprises a set of version number rules, which correlate the results of the Java™ binary compatibility rules (JCR) 206 to the version numbering semantics used for the APIs. In other words, if a JCR rule is broken, in a particular case, the version number rules may automatically increment the major version number for the associated API. Similarly, if a less significant compatibility rule is broken, the version number rules may automatically increment the minor version number. The processing carried out by the AVC 203 is the same as in the above embodiment from steps 301 to 308 as shown in
In another embodiment, the AVC is arranged to identify any differences in the meta data and to inform the user of those differences. It is then up to the user to determine if those changes break any compatibility rules and to update any associated version number if necessary. In a further embodiment, the version numbering updates provided by the AVC are compulsory. In another embodiment, the version numbering update suggested by the AVC are advisory and may be ignored or over-ridded by a user.
In a further embodiment, the meta data is extracted from the source code by a means other than the AST, such as a separate code parser which extracts code constructs. The AVC may operate prior to compilation. In another embodiment, the metadata is stored as a binary or XML representation of the exported or imported APIs.
In a further embodiment, all of the software components of a software system that is being assembled are checked by the AVC at compile time so that interdependent components all have their dependencies checked. In another embodiment, the functions of the AVC are performed at component link time. In a further embodiment the component dependency information is preserved at runtime, and the AVC functions are performed at runtime rather than development time.
In another embodiment, the AVC checks import version identification compatibility. Where the version number being imported is made explicit, existing tooling will ensure that the import is satisfied by an available component export. However, where no version is dictated then any export will suffice and the meta data for the exporter may be used to determine any breaking API from the importer. In practice this means that breaking an exported API may also break a number of unqualified import dependencies. This is especially useful where the exporter is not participating in the componentisation framework, for example, the imported component is sourced from a third-party library.
As will be understood by those skilled in the art, the above technology may be applied to software components written in other languages that provide for componentisation and APIs or equivalent functions.
It will be understood by those skilled in the art that the apparatus that embodies a part or all of the present invention may be a general purpose device having software arranged to provide a part or all of an embodiment of the invention. The device could be single device or a group of devices and the software could be a single program or a set of programs. Furthermore, any or all of the software used to implement the invention can be communicated via any suitable transmission or storage means so that the software can be loaded onto one or more devices.
While the present invention has been illustrated by the description of the embodiments thereof, and while the embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details of representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departure from the spirit or scope of applicant's general inventive concept.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0619147.2 | Sep 2006 | GB | national |
