我应该如何维护JDK7项目，以便它们可以自动降级为JDK6？

Question

我几乎没有自己的API，大约有2000个类。其中一些使用JDK7中的新Path API。但是，大多数其他类不依赖于任何新的JDK API或新的语言功能。所以大多数类都可以在JDK6环境中使用（我打算这样做）。我们假设，我使用@Java7Only注释了所有仅限JDK7的类。

我现在需要的是一种在所有项目中创建一个或多或少自动的JDK6子集的方法，而不会引入新的版本分支或产品线（太复杂了保持）。

所有项目都是使用Netbeans创建的，因此使用Ant。许多项目依赖于其他项目。

请帮我评估，根据我的问题哪些想法最合适。每个想法都会出现哪些问题？

所有想法的共同第一步

• 让注释处理器搜索@Java7Only - 带注释的类，并将列表存储到properties文件中。

创意1（具体）

• 编写一个工具，使用properties文件递归复制整个项目，但仅限JDK7文件。
• 通过调用ant使用JDK6构建复制的项目，从而获得符合JDK6标准的jar。

创意2（具体）

• 编写第二个注释处理器，它将使用properties文件将除JDK7之外的所有文件传递给JavaCompiler实例。
• 使用Java API构建jar或使用Ant API。

（这将是一个只有Java的想法，但可能太复杂了）

Idea X（摘要）

• 以某种方式影响Ant构建过程（通过覆盖一些目标？）和每个符合JDK6的类：让Ant编译它的两个版本（一次使用JDK6编译器，另一次使用JDK7编译器）。
• （仅JDK7类只编译一次，当然使用JDK7编译器）
• 将每一包装到一个单独的罐子里。

这些想法可能存在的常见问题

• 某些项目依赖于其他项目，因此某些操作（例如打包）应考虑这一点。
• 请记住：JDK7编译器生成向下的不兼容的类文件，这就是为什么每个可能的想法都必须在源级别上发生（在构建过程之前或期间，而不是之后）。

Answer 1

这只是部分适用，但我想我还是会提到它。

使用-source 1.6 -target 1.6选项进行验证的问题是，在使用JDK 7编译时仍然可以使用Java 7 API。

我现在已经将Animal Sniffer Maven Plugin用于了一些项目，事实证明它非常有用。此插件扫描类的字节代码以用于JDK API。也就是说，如果您在定位JDK 6时尝试使用JDK 7 API，则可以告诉它失败构建。这对于根据需要分离类很有帮助，但它可以作为最终验证步骤结合使用 - source 1.6 -target 1.6编译器选项。

还有一个动物嗅探器Ant插件，如Animal Sniffer main page所述。

Answer 2

我对想法2的看法：

本质上，这是在编译器中调用编译器。注释处理器作为编译的一部分运行。这可以安全地完成吗？ Sun的javac中是否存在可能导致问题的静态。 （我不知道答案，但是从内存中可能会有一些静态，可能会导致这种情况出现问题）。

创意1对我来说似乎更简单，更好。

但退后一步，是否有可能将所有JDK 7特定的东西分离到一个单独的模块中并单独编译成另一个JAR？

• 拥有使用JDK 6编译的'main'项目（JDK 7在阅读时没有问题，因为它是向后兼容的）
• JDK 7特定模块的源位于不同的目录中，其中包含编译类路径中的“主”JAR，可以单独构建，必要时使用不同的build.xml。