向前兼容的 Java 6 注释处理器和 SupportedSourceVersion [英] Forward compatible Java 6 annotation processor and SupportedSourceVersion

问题描述

我正在为一个项目尝试 Java 7，并从此类注释处理器(Bindgen 和 Hibernate JPA 模型生成)收到警告:

warning: 来自注释处理器 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' 的支持源版本 'RELEASE_6' 低于 -source '1.7'

这是由注释处理器类上的 @SupportedSourceVersion(SourceVersion.RELEASE_6) 注释引起的.由于它们是用 Java 6 编译的，因此它们可用的 SourceVersion 的最高值是 RELEASE_6.SourceVersion 的 Java 7 版本引入了 RELEASE_7.

我的问题:注解处理器应该如何处理前向兼容性?它们是否必须有单独的 jdk6 和 jdk7 二进制版本?我不明白这里的其他东西吗?

我只找到了有关此问题的以下信息:

Querdydsl 错误报告 使用了

@Overridepublic SourceVersion getSupportedSourceVersion() {返回 SourceVersion.latest();}

Oracle 博客，其中评论者建议支持最新的源版本

解决方案

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

在提到的 Oracle 博客中还有另一个条目，它提出了两个关于转发的政策兼容性:

<块引用>

• 将处理器编写为仅使用当前语言版本.
• 编写处理器以应对未知的未来结构.

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

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

<小时>

好吧，我想适当地处理未知语言结构听起来有点含糊，所以这里有一些例子.

假设您有一个处理器，可以检查已知语言结构上的自定义类型的注释(例如类的注释)，并创建一个简单的文档来说明所发现的内容.您可能可以安全地假设它也适用于较新的版本.在我看来，将其限制为特定版本并不是一个好的决定.

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

无论使用何种策略，我认为最好的方法是监控即将发生的语言变化并相应地更新处理器.例如，在 Java 7 中，project coin 引入了一些新的语言特性，这些特性很可能甚至没有对处理器可见.另一方面，Java 8 确实具有会影响处理的新构造，例如 类型注释.不过，新语言功能并不经常出现，因此您可能在很长一段时间内都不需要更改任何内容.

I am trying out Java 7 for one project and getting warnings from annotation processors (Bindgen and Hibernate JPA modelgen) of this sort:

warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7'

This is caused by the @SupportedSourceVersion(SourceVersion.RELEASE_6) annotation on the annotation processor classes. Since they are compiled with Java 6, the highest value of SourceVersion available to them is RELEASE_6. The Java 7 version of SourceVersion introduces RELEASE_7.

My questions: How are annotation processors supposed to handle forward compatibility? Will there have to be separate jdk6 and jdk7 binary versions of them? Am I not understanding something else here?

I only found the following information regarding this concern:

Querdydsl bug report which used

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

Oracle blog in which a commentor recommends supporting latest source version

解决方案

Forward compatibility is handled by processing unknown language constructs appropriately, for example by implementing ElementVisitor.visitUnknown.

There is another entry in the mentioned Oracle blog, which suggests two policies regarding forward compatibility:

• Write the processor to only work with the current language version.
• Write the processor to cope with unknown future constructs.

The second one is done by returning SourceVersion.latest() as already posted in the question.

I think it's ok to do this in most cases, when you are sure additional language elements won't break anything. Of course you shouldn't just assume that everything will be fine even with newer versions, you should test it too.

---

Ok, I guess processing unknown language constructs appropriately sounds a bit vague, so here are some examples.

Supposed you have a processor that checks for a custom type of annotations on known language constructs (annotations on a class for example) and creates a simple documentation of what it has found. You are probably safe to assume it will also work in newer versions. Restricting it to a particular version would not be a good decision in my opinion.

Supposed you have a processor that checks every element it can find and analyses the code structure to generate a graph out of it. You may get problems with newer versions. You may be able to handle unknown language constructs somehow (like by adding a unknown node to the graph) but only do this if that makes sense - and if it's worth the trouble. If the processor just wouldn't be useful any more when confronted with something unknown, it should probably stick to a particular java version.

Regardless of the policy used, the best way in my opinion would be to monitor upcoming changes to the language and update the processor accordingly. In Java 7 for example, project coin introduced some new language features, which are most likely not even visible to a processor. Java 8 on the other hand does have new constructs that will affect processing, for example type annotations. New language features don't happen that often though, so Chances are that you don't even need to change anything for a long time.

这篇关于向前兼容的 Java 6 注释处理器和 SupportedSourceVersion的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！