Newsletter sign-up
View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Manage your software with the Java Product Versioning Specification

An introduction to component versioning with Java

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Many of us are familiar with how to find version information in Windows-like applications. At startup, we're often greeted with a splash screen that identifies the vendor, the product name, and usually its version. Once an application has launched, similar information can generally be found under the About dialog in the Help menu.

Although not quite as ubiquitous, server-side applications tend to employ similar approaches. When server-side applications launch, product and version information usually appear on the system console or are written into a log file. Once these applications are up and running, the same kind of information can usually be found in the assortment of README, license, and contact information files that accompany server-side products.

Over time, most users seem to have become familiar with and accepted these approaches. We could define them as defacto standards.

But what about component systems, such as those falling under the widening umbrella of specifications in the Java 2 Platform, Enterprise Edition (J2EE)? In these systems, applications are often made up of components supplied by several vendors. The components themselves may be distributed across a network or a cluster of servers. How do we find the product and vendor information of such distributed components? It is not always immediately obvious where to find such information just by looking at the installation of a running, distributed component system.

Even for simple tasks, such as submitting a bug report or contacting the support group, the ability to identify the vendor of a product or component, its name, and its version is absolutely mandatory. When upgrading a component, the user needs to feel reasonably sure that introducing a new version will not adversely affect other parts of the system, or more formally, that the contract a component exposes to other parts of the system remains the same.

To address these kinds of problems, Sun Microsystems released the Java Product Versioning Specification. Using the mechanisms of packaging, combined with a little support from a selection of core classes within the Java platform, Sun has achieved a versioning model that turns out to be quite well suited to the needs of developers and users of component systems.

Note: You can download this article's source code from Resources.

The Java Product Versioning Specification

Published in 1998, the Java Product Versioning Specification describes the problems of evolution in distributed systems. It outlines various distinguishing factors of such systems, including component distribution, multivendor sourcing, and intracomponent dependencies. It also identifies the needs of various individuals involved with the production, support, administration, and use of these kinds of systems.

One of the key definitions of the Java Product Versioning Specification is the replaceable unit. To paraphrase the specification, the replaceable unit is the smallest unit in a product or system that can be identified with a specification and a supplier, be distributed and redistributed, and replaced if necessary. In Java, the specification defines the replaceable unit as the Java package.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources