向前兼容Java6批注处理器和SupportedSourceVersion

Question

我正在为一个项目试用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)批注引起的。因为它们是用Java6编译的，所以它们可用的最高SourceVersion值是RELEASE_6。SourceVersion的Java7版本引入了RELEASE_7。

我的问题是:注释处理器应该如何处理前向兼容性？是否必须有独立的jdk6和jdk7二进制版本？我是不是还不明白什么呢？

关于这个问题，我只找到了以下信息：

使用的Querdydsl bug report

@Override
public SourceVersion getSupportedSourceVersion() {
    return SourceVersion.latest();
}

评论员推荐支持最新源码版本的Oracle blog

Answer 1

前向兼容性是通过适当地处理未知语言构造来处理的，例如通过实现ElementVisitor.visitUnknown。

在提到的Oracle blog中还有另一个条目，它建议了两个关于前向兼容性的策略：

• 编写处理器以仅使用当前语言版本。
• 编写处理器以处理未知的未来构造。

第二个是通过返回问题中已经发布的SourceVersion.latest()来完成的。

我认为在大多数情况下，当你确定额外的语言元素不会破坏任何东西时，这样做是可以的。当然，您不应该仅仅假设即使使用较新的版本也会一切正常，您也应该对其进行测试。

好吧，我想处理未知的语言构造听起来有点模糊，所以这里有一些例子。

假设您有一个处理器，它检查已知语言构造上的自定义类型的批注(例如，类上的批注)，并为所找到的内容创建一个简单的文档。您可能可以放心地假设它在较新的版本中也可以工作。在我看来，把它限制在一个特定的版本上不是一个好的决定。

假设您有一个处理器，它检查它能找到的每个元素，并分析代码结构以生成一个图。使用较新的版本可能会遇到问题。您也许能够以某种方式处理未知的语言构造(比如向图中添加一个未知节点)，但只有在这样做有意义的情况下才这样做-并且值得这么做。如果处理器在遇到未知的东西时不再有用，那么它可能应该坚持使用特定的java版本。

不管使用哪种策略，在我看来，最好的方法是监控即将到来的语言更改，并相应地更新处理器。例如，在Java7中，project coin引入了一些新的语言特性，这些特性很可能对于处理器来说是不可见的。另一方面，Java8确实有影响处理的新构造，例如type annotations。然而，新的语言特性并不经常出现，所以很有可能在很长一段时间内你都不需要改变任何东西。