Geek Answers Handbook

Java conditional compilation to support 1.4 / 1.6 at the same time

I am working on a large old code base that currently only compiles with java 1.4. One of the things I need to do is get it to work with 1.6 (probably 1.7 now).

The head assembly is not currently compiled with 1.6. There are many reasons for this - most of them are easy to fix, for example, using enum as a keyword, but we are struggling with Oracle / Sun updating JDBC (connection interface) to support types not available in java 1.4. This means that if I make changes to work with 1.6, the main production assemblies are broken down into classes such as NClob break, because they are not in version 1.4; if I do not make changes, I cannot compile with the 1.6 compiler.

Are there templates to support conditional compilation / assembly in java? My only plan I have come up with so far is to mess around with the ant construct for conditionally replacing I / O classes depending on the assembly. It feels pretty awful, so the community asks about it here.

Again, the boundaries of the problem are:

  • You need to be able to continue compiling HEAD on 1.4 (there is no version 1.6 with 1.4 compatibility modes, I'm afraid)
  • We also need a separate head assembly, which compiles with 1.6 - the assumption is that it will take some time (since this is a large code base), therefore, the first point of the marker will allow others to continue working and deliver other changes during preparation. The head is built for compatibility since 1.6.
  • This is one massive tree of code; this means that none of our codes is library dependent, and we cannot do it this way (remember: the base code base :( )
  • We do not allow branching (for the reason I will not go into it if I really do not have to)

Thank you very much in advance.

+4
source share
4 answers

There is a previous SO answer that covers this, essentially using the ant replace task to make a quick and dirty version of IFDEF blocks. This would probably be simpler than sharing files of the entire class, and would simplify the execution of just 1.6 whenever you can (just delete all 1.4 IFDEF blocks)

+3
source

This is why makefiles / pom.xml / build.xml get validated. Use your version control system to create a branch. In one branch, make the necessary changes for compatibility with 1.6. No other branches. Any single branch will either safely compile for 1.4, or compile safely for 1.6, without any frankenbranches trying to do both at once, which is a Bad Idea (tm).

+3
source

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

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

+3
source

I use Maven and I will have a module that defines the interfaces that both versions share. Then you have two modules: one with code 1.4 and one with Java version 6 (or 7 or 8). This way you can create them and choose the appropriate implementation at runtime.

+3
source

More articles:


All Articles