我正在为一个项目尝试Java 7并从这种注释处理器（Bindgen和Hibernate JPA modelgen）获得警告：
warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7'
这是由注释处理器类上的@SupportedSourceVersion(SourceVersion.RELEASE_6)注释引起的。由于它们是使用Java 6编译的，因此SourceVersion可用的最高值为RELEASE_6。 {7}的Java 7版本引入了SourceVersion。
我的问题：注释处理器如何处理前向兼容性？是否必须有单独的jdk6和jdk7二进制版本？我在这里不理解其他什么吗？
我只发现了有关此问题的以下信息：
使用的RELEASE_7Oracle blog评论员建议支持最新的源版本
答案 0 :(得分：13)
通过适当处理未知语言结构来处理向前兼容性，例如通过实施ElementVisitor.visitUnknown。
上述Oracle blog中还有另一个条目，它提出了两个有关向前兼容性的政策：
- 将处理器写入仅使用当前语言版本。
- 编写处理器以应对未知的未来构造。
第二个是通过返回问题中已发布的SourceVersion.latest()来完成的。
我认为在大多数情况下这样做是可以的，当你确定其他语言元素不会破坏任何东西时。当然，你不应该只是假设即使使用较新的版本，一切都会很好，你也应该测试它。
好吧，我猜正确处理未知语言结构听起来有点模糊，所以这里有一些例子。
假设您有一个处理器，它检查已知语言结构上的自定义注释类型（例如类上的注释），并创建一个简单的文档，说明它找到了什么。您可以安全地假设它也适用于较新的版本。在我看来，将其限制为特定版本并不是一个好的决定。
假设您有一个处理器，它检查它可以找到的每个元素，并分析代码结构以生成一个图形。您可能会遇到较新版本的问题。您可能能够以某种方式处理未知的语言结构（例如通过向图中添加未知节点），但只有在有意义的情况下才能执行此操作 - 并且如果它值得麻烦。如果处理器在面对未知的东西时不再有用，那么它应该坚持使用特定的java版本。
无论使用何种策略，我认为最好的方法是监控即将发生的语言更改并相应地更新处理器。例如，在Java 7中，project coin引入了一些新的语言功能，这些功能很可能甚至对处理器不可见。另一方面，Java 8确实有新的结构会影响处理，例如type annotations。新的语言功能通常不会发生，所以很有可能你甚至不需要长时间改变任何东西。