Java conditional compilation to support 1.4/1.6 simultaneously

Question

I'm working on a large legacy codebase that currently only compiles with java 1.4. One of the things that I need to do is to get it working with 1.6 (well probably 1.7 now).

The head build doesn't currently compile with 1.6. This is for lots of reasons - most are easy to fix, like using enum as a keyword, but we're struggling with Oracle/Sun updating the JDBC (Connection interface) to support types that are not available in java 1.4. This means if I make the changes to work with 1.6, the main production builds break as classes like NClob break as they aren't in the 1.4 release; if I don't make the changes, I can't compile with the 1.6 compiler.

Are there any patterns to support conditional compilation/build in java? My only plan I've thus far come up with was to fiddle with the ant build to conditionally swap in/out classes depending on the build. This feels pretty horrible, hence asking the community here for thoughts.

Again, the boundaries on the problem are:

• Need to be able to continue to compile HEAD on 1.4 (no 1.6 with 1.4 compatibility mode I'm afraid)
• Also need a separate head build that compiles with 1.6 - the assumption is that this will take some time (as it's a large codebase), hence the first bullet point to allow others to continue to work and deliver other changes while we prepare the head build for 1.6 compatibility.
• it's one massive code tree; this means none of our code is a library dependancy, and we can't easily make it so (remember: legacy code base :( )
• We don't allow branching (for reason's I won't go into unless I Really have to)

Many Thanks in advance.

• For those that are curious as to why we need to do this, our situation is somewhat similar to this : Mixing Java 1.4 and 1.6 bytecode in a class hierarchy

Answer 1

This is why makefiles/pom.xml/build.xml get checked in. Use your revision control system to create a branch. In one branch, make all the changes needed for 1.6 compatibility. In the other branches, don't. Any given branch will either safely compile for 1.4 or safely compile for 1.6, with no frankenbranches that try to do both at once, which is a Bad Idea(tm).

Answer 2

There is a previous SO answer that covers this, essentially using ant's replace task to make a quick and dirty version of IFDEF blocks. That would probably be easier than swapping out whole class files, and would make it easier to go full 1.6 whenever you can (just remove all of the 1.4 IFDEF blocks)