Although I've used the term compatibility several times in earlier blogs you may have noticed that I haven't been absolutely clear about its meaning. (Not good, since the conformance-testing business is all about being precise with language!)

Since we call our conformance test suites Compatibility Test Kits it should be obvious that we believe that compatibility is somehow related to conformance. (Elsewhere in the industry it's more common to talk about 'conformance testing' than 'compatibility testing'...)

In fact we use the word in at least two slightly different ways in this context:

• We use the term Compatible Implementation to refer to an implementation of a Java technology that meets all of the conformance and licensing requirements.
• We also imply that these implementations of Java technologies are compatible with each other. By this we meant that well-written applications (another fuzzy term that I'll need to define more precisely) will behave in a functionally equivalent manner when executed on different implementations.

Conformance to specifications is the foundation of compatibility. If the specs are comprehensive and unambiguous, then implementations that conform to them are likely to be compatible with each other.

Compatibility is related to, but distinct from, interoperability. (Systems are interoperable if they can exchange data and information in a mutually useful manner.) Compatibilty is a necessary precondition for interoperability but it doesn't guarantee it. Optionality in specifications - that is, allowing implementors to choose whether or not to implement certain features - can seriously damage interoperability, but this too is a topic for another day.

Finally, we use the term compatibility in a different context when referring to releases from a single vendor rather than to implementations from different vendors. (In other words, we expect all implementations of J2SE 5.0 to be compatible with each other but we also expect our own release of Java SE 6 to be compatibile with our previous release.)

In an attempt to disambiguate these overloaded terms, we sometimes call this latter form Binary Compatibility. And yes - we take it just as seriously as the othe kind of compatibility. We don't want to break your applications! You may have heard that we've recently launched a Regressions Challenge contest with some big prizes. If you haven't done so already, please check it out.

In addition to the conformance form of compatibiltiy, my team is also responsible for driving binary compatibility issues within the Java SE organization. You can expect to hear more from us on this subject in the coming weeks and months.

In an earlier post I wrote "1859726542". See how well some standards work? I didn't even need to use words. The ISBN, of course, is a standard for uniquely identifying books and similar items. As the User's Manual explains:

The International Standard Book Number (ISBN) has experienced remarkable success. In almost thirty years it has conquered the world's publishing industry, and the book trade would not be able to function without it. Ordering and distribution have gained a new quality with ISBN, and the huge amount of publications on the market can only be regulated by the ISBN-driven directories of the Books in Print type.

The ISBN is relatively short, machine-readable in the form of the Bookland EAN bar code and not just applicable to print media. It is also applicable to most non-printed book material, especially electronic publications, provided their character is monographic and stable.

By the way, the book I referenced was written by my father in 1997 when he was 81 years old. This is his second book (the first - 1856288633 - was published in 1994). He's still going strong at 90.