Question

This is for an Android application but I’m broadening the question to Java as I don’t know how this is usually implemented.

Assuming you have a project that targets a specific SDK version. A new release of the SDK is backward incompatible and requires changing three lines in one class.

How is this managed in Java without duplicating any code(or by duplicating the least amount)?
I don’t want to create two projects for only 3 lines that are different.

What I’m trying to achieve in the end is a single executable that’ll work for both versions. In C/C++, you’d have a #define based on the version. How do I achieve the same thing in Java?

Edit: after reading the comments about the #define, I realized there were two issues I was merging into one:

• So first issue is, how do I not
  duplicate code ? What construct is there that is the equivalent of a
  #define in C.
• The second one is: is it possible
  to bundle everything in the same
  executable? (this is less of a
  concern as the first one).

Answer 1

It depends heavily on the incompatibility. If it is simply behavior, you can check the java.version system property and branch the code accordingly (for three lines, something as simple as an if statement).

If, however, it is a lack of a class or something similar that will throw an error when the class is loaded or when the code gets closer to execution (not necessarily something you can void reasonably by checking before calling), then the solution gets a lot harder. The notion of having a separate version is the cleanest from a code point of view, but it does mean you have to distribute two versions.

Another solution is reflection. Don’t reference the class directly, call it via reflection (test for the methods or classes to determine what environment you are currently running in and execute the methods). This is probably the “official” approach in that reflection exists to deal with classes that you don’t have or don’t know you will have at compile time. It is just being applied to libraries within the JDK. It gets very ugly very fast, however. For three lines of code, it’s ok, but doing anything extensive is going to get bad.

The last thing I can think of is to write common denominator code – that is code that gets the job done in both, finding another way to do it that doesn’t trigger the problematic class or method.