If you work or had worked for a mid-size to large company then I’m sure you would have gotten into those heated discussions on whether to be backward compatible or not. Many a times, this backward compatibility plays spoilsport and kills new ideas or shuns newer implementation. “Well, this feature looks cool … but it needs version X of the software … But that would break the compatibility. I’m sorry … we can include this feature … may be in future …” are some of those sentences that echo the walls of product companies.

We had a similar situation in hand. But we had a way out as well. The technique is nothing new. Quite age-old. But I would still present it here. May be it is useful for someone out there.

We had this piece of software, lets call it Comp.X. Comp.X was written in java version 1.4. It runs on 1.4 as well as 1.5 though it is not “Officially” support 1.5. Oh well … this “official support” thingy annoys me a lot. Though they dont have to change a single line of code, there is hell lot of bureaucracy in getting this “official support” tag. Let me not digress further .. So this Comp.X is one elegant piece of code written in Java 1.4. Good.

Now, additional enhancements were needed. Comp.Y came into existence. Comp.Y depended on other stuff that ran only in Java 1.5. So this new kid on the block Comp.Y was a java 1.5 only kid. But Comp.Y isnt a standalone component. It is an addon to Comp.X. So we opened up Comp.X and used the APIs of Comp.Y and completed the integration. In this process, Comp.X was no longer compiling on java 1.4. My team raised a cry … “look, if you want the features of Comp.Y, you better move to Java 1.5”. We mistakenly took the silence for an approval !

When the day came when we had to checkin all the integrated code into version control, we heard a shrieking voice “waaaaaiiiittttttttttt” …. cant break compatibility. Comp.X will be supported for two more years on Java 1.4.”
“Grrr … we already told you it wont work in Java 1.4” – this were my folks. Well we had to sort this out now.

One option was to create a branch for Comp.X and maintain a java 1.4 compliant version and java 1.5 compliant version. But this means double maintenance. Too heavy a price to pay.

After little thought and consultation, we found this way out.
First, we modified Comp.X code in such a way that
if ( JDK_VERSION == 1.5){
use the Comp.Y APIs
Second, we created a ICompY.jar that contained *only* the interfaces. This interface only component compiled in JDK1.4. This worked for us because we did not use generics or such JDK1.5 specific stuff in our interface methods.
Third, we compiled Comp.X against ICompY.jar and it compiled fine in BOTH Java 1.4 and 1.5 enviroments.
At runtime, if it is Java 1.5 runtime, then CompY.jar is placed in the classpath and the functionality is available. In the case of Java 1.4 runtime, there are guards in the code that guarantee safe execution even in the absence of Comp.Y jar.

A neat way to get the best of both worlds! best of all, no double maintenance.