 |
-- Main.mcconnell - 19 Apr 2005
JSR 294 and JSR 277 are two processes set to change the Java landscape. JSR 294 is defining module metadata - a solution to the API visibility problem - and a framework within which tools will be able to generate metadata that strictly controls what is in and what is not in a given API. JSR 277 is defining a module deployment model based on 294 that leverages information about the dependent modules. The contract between a given module and its dependencies is expressed as a module-name and version constraint. The javac compiler under SE7 (assuming 294 adoption) will generate information about the published APIs (in a form that is cleaner than anything per SE7) and a list of versioned dependencies. The 277 iniative aims to fold these development phases resources into runtime artifacts (namely classloader chains built from module definitions).
For the developer - JSR 294 has the potential to introduce a formal criteria concerning version management. We have the potential for products (modules) to be published under a specific major, minor, and micro version. The version under which a module is published will determine the potential computational inclusion of the module in a classloader chain. However - there is a big question out there - "what version does a developer apply to a new release". Technically speaking we can assume that any new published jam (or jar) can be assigned a version 1.0.0. But the really interesting things happen in a subsequent release. Does the modification of a method signature, a static variable with a primitive value, or a semantic change to a method implementation on a published interface or class change my published API at a micro major, minor or micro level? The answer (in principal) should be resolvable to three boolean value relative to a prior publication.
Given a jar file (or jam file - on that basis that this is a subset) we have a set of historical classes that we can compare with a current (non published) set of classes - and from these two resources we should be able to determine the following:
- is the new resource equal to the old resource
- otherwise, does the new resource represent a major version increment relative to the old resource
- or does the new resource represent a minor version increment relative to the old resource
- or does the new resource represent a micro version increment relative to the old resource
The resolution of this information is a function of the Java language and as such the question of source and binary is also a computational function. The output of that function from the point of view of a module developer (from respective source and binary perspectives) is one of the enumerations "EQUAL", "MICRO", "MINOR", or "MAJOR". Assuming that a tool was provided with a baseline jar (or jam file) and that said tool generated a version change result for source an binary impact ... then higher level tools would be able to evaluate build and runtime requirements on consumer projects.
Relative to current practices the determination of a version change on consumer projects is non-trivial. Aside from classic changes such as interface or class changes there is also the potential impact of inlined values. In addition the usage of a given API by a consumer has a direct impact on the impact version of a consumer development codebase. This subject is further conplicated if we consider version ranges (e.g. 2.X versus 2.1.X) declared by dependent projects. Given metadata about source and binary changes of a provider API - the potential impact on downstream projects (consumers) is potentially assessable. I.e. does the upstream change imply a version change on consumer given the consumers version dependency contract?
Dealing with this subject requires two tools:
- one tool dealing with absolute change to a produced api relative to a prior published artifact
- another tool dealing with impact assessment given a collection of input resources (jar or jam) of a target source module
The open questions relative to the openjdk project concern the appropriate process for the establishment of such a project and the framework for integration of initial and ongoing results from the respective JSR 294 and JSR 277 projects.
Related Links
|