4

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.

Community
  • 1
  • 1
phatmanace
  • 4,671
  • 3
  • 24
  • 29
  • 2
    there is a [previous SO answer](http://stackoverflow.com/a/4526352/1904979) that suggests using the replace task in ant to do implementation of IFDEF blocks within the classes. This might be less hacky than swapping out full class files. – Peter Elliott Jan 14 '13 at 21:42
  • This looks really promising - do you want to add as an answer so that I can accept if it works? – phatmanace Jan 14 '13 at 21:48

4 Answers4

4

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).

Mel Nicholson
  • 3,225
  • 14
  • 24
3

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."

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
3

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)

Community
  • 1
  • 1
Peter Elliott
  • 3,273
  • 16
  • 30
  • 1
    +1. I am having c preprocessor horror story flashbacks, though, so I suggest revisiting the no-branch policy as a way out of the mess. – Mel Nicholson Jan 14 '13 at 21:54
  • I think this is the best solution for our needs. Noted mel's points, but hopefully this is a temporary solution until we get what we need done – phatmanace Jan 14 '13 at 22:56