Java条件编译同时支持1.4 / 1.6

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

Make a port14.jar and port16.jar with same classes, and same methods, but different implementations. And make two separate builds.

This means double work, but you can use the same code basis at the same time. And the differences are relative "minor."

Answer 3

I use Maven and I would have module which defines the interfaces that both versions share. Then you have two modules, one with the 1.4 code and one with the version Java 6 (or 7 or 8). This way you can build them both and select the appropriate implementation at runtime.

Answer 4

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)