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

【问题标题】：Java conditional compilation to support 1.4/1.6 simultaneouslyJava条件编译同时支持1.4/1.6
【发布时间】：2012-12-28 22:19:24
【问题描述】：

我正在开发一个大型遗留代码库，目前只能使用 java 1.4 进行编译。我需要做的一件事是让它与 1.6（现在可能是 1.7）一起工作。

head build 当前无法使用 1.6 进行编译。这有很多原因——大多数都很容易修复，比如使用enum 作为关键字，但我们正在努力与 Oracle/Sun 更新 JDBC（连接接口）以支持 java 1.4 中不可用的类型。这意味着如果我对 1.6 进行更改，主要生产构建会中断，因为像 NClob 这样的类会中断，因为它们不在 1.4 版本中；如果我不进行更改，我将无法使用 1.6 编译器进行编译。

在 java 中有没有支持条件编译/构建的模式？到目前为止，我提出的唯一计划是摆弄 ant 构建，以根据构建有条件地换入/换出类。这感觉很可怕，因此在这里向社区征求意见。

同样，问题的界限是：

需要能够在 1.4 上继续编译 HEAD（恐怕没有 1.6 和 1.4 兼容模式）
还需要使用 1.6 编译的单独的头构建 - 假设这需要一些时间（因为它是一个大型代码库），因此第一个要点是允许其他人在我们准备时继续工作并交付其他更改用于 1.6 兼容性的头部构建。
这是一棵巨大的代码树；这意味着我们的代码都不是库依赖，而且我们不能轻易做到这一点（记住：遗留代码库:(）
我们不允许分支（原因是我不会进入，除非我真的必须这样做）

非常感谢。

对于那些对我们为什么需要这样做感到好奇的人，我们的情况与此有些相似：Mixing Java 1.4 and 1.6 bytecode in a class hierarchy

【问题讨论】：

有一个previous SO answer 建议在ant 中使用replace 任务来实现类中的IFDEF 块。这可能比换出完整的类文件更简单。
这看起来很有希望 - 你想添加一个答案，以便我可以接受它是否有效？

标签： java ant legacy jdk1.4

【解决方案1】：

这就是 makefiles/pom.xml/build.xml 被签入的原因。使用您的修订控制系统来创建一个分支。在一个分支中，进行 1.6 兼容性所需的所有更改。在其他分支，不要。任何给定的分支都可以安全地编译为 1.4 或安全地编译为 1.6，没有分支尝试同时执行这两种操作，这是一个坏主意（tm）。

【讨论】：

唉，我们不允许分支 - 将编辑问题以明确这一点。我的错。
交换源文件是一个自己动手的分支功能实现。使用具有大量测试优势的真正的分支功能实现，您可能会更开心。
是的——公平点。感谢您的 cmets，感谢您的回复。

【解决方案2】：

有一个 previous SO answer 涵盖了这一点，本质上是使用 ant 的 replace 任务来制作一个快速而肮脏的 IFDEF 块版本。这可能比换掉整个类文件更容易，并且尽可能更容易进入 1.6（只需删除所有 1.4 IFDEF 块）

【讨论】：

+1。不过，我有 c 预处理器的恐怖故事闪回，所以我建议重新审视无分支政策，以摆脱混乱。
我认为这是满足我们需求的最佳解决方案。注意到 mel 的观点，但希望这是一个临时解决方案，直到我们完成所需的工作

【解决方案3】：

我使用 Maven，我将拥有定义两个版本共享的接口的模块。然后你有两个模块，一个带有 1.4 代码，一个带有 Java 6（或 7 或 8）版本。这样您就可以同时构建它们并选择适当的实现在运行时。

【讨论】：

【解决方案4】：

使用相同的类和相同的方法创建port14.jar 和port16.jar，但实现不同。并进行两个单独的构建。

这意味着双重工作，但您可以同时使用相同的代码基础。并且差异是相对的“次要”。

【讨论】：