向前兼容的Java 6注释处理器和SupportedSourceVersion
我正在为一个项目尝试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 。 SourceVersion的Java 7版本引入了RELEASE_7 。
我的问题：注释处理器如何处理前向兼容性？ 是否必须有单独的jdk6和jdk7二进制版本？ 我在这里不理解其他什么吗？
我只发现了有关此问题的以下信息：
使用的Querdydsl错误报告
@Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latest(); }
Oracle博客 ，其中评论员建议支持最新的源版本
通过适当地处理未知语言结构来处理向前兼容性，例如通过实现ElementVisitor.visitUnknown 。
在上述Oracle博客中还有另一个条目，它提出了两个有关向前兼容性的政策：
- 将处理器写入仅使用当前语言版本。
- 编写处理器以应对未知的未来构造。
第二个是通过返回已在问题中发布的SourceVersion.latest()来完成的。
我认为在大多数情况下这样做是可以的，当你确定其他语言元素不会破坏任何东西时。 当然，你不应该只是假设即使使用较新的版本，一切都会很好，你也应该测试一下。
好吧，我觉得处理未知的语言结构听起来有点模糊，所以这里有一些例子。
假设您有一个处理器，它检查已知语言结构上的自定义注释类型（例如，类上的注释），并创建一个简单的文档，说明它找到了什么。 你可以安全地假设它也适用于较新的版本。 在我看来，将它限制在特定版本并不是一个好的决定。
假设您有一个处理器，它检查它可以找到的每个元素，并分析代码结构以生成一个图形。 您可能会遇到较新版本的问题。 您可能能够以某种方式处理未知的语言结构（例如通过向图表添加未知节点），但只有在有意义的情况下才能执行此操作 – 并且如果它值得麻烦。 如果处理器在面对未知的东西时不再有用，它可能应该坚持特定的Java版本。
无论使用何种策略，我认为最好的方法是监控即将发生的语言更改并相应地更新处理器。 例如，在Java 7中， 项目硬币引入了一些新的语言function，这些function很可能甚至对处理器不可见。 另一方面，Java 8确实有新的结构会影响处理，例如类型注释 。 新的语言function通常不会发生，所以很有可能你甚至不需要长时间改变任何东西。