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

问题描述

我想了Java 7的一个项目，让这种距离的注解处理器警告（定义BindGen和Hibernate JPA modelgen）：

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'

这是由 @SupportedSourceVersion（SourceVersion.RELEASE_6）标注上标注处理器类引起的。由于它们与Java 6中， SourceVersion 的最高值提供给他们编为 RELEASE_6 。在Java 7版本 SourceVersion 引入的 RELEASE_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.

我的问题：如何标注处理程序应该处理向前兼容？会不会有必须是独立的JDK6，其中JDK7二进制版本？难道我不理解别的东西吗？

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报告它使用

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

甲骨文博客其中的评注建议支持最新的源代码版本

Oracle blog in which a commentor recommends supporting latest source version

推荐答案

向前兼容性是通过处理未知的语言处理构建适当的，例如通过实施<一个href=\"http://download.oracle.com/javase/6/docs/api/javax/lang/model/element/ElementVisitor.html#visitUnknown%28javax.lang.model.element.Element,%20P%29\"相对=nofollow> ElementVisitor.visitUnknown 。

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:

  
• 写处理器只能使用当前的语言版本的工作。

  
• 写的处理器，以应对未知的未来结构。

  

第二个是通过返回完成 SourceVersion.latest（）如已经张贴在的问题。

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.

假定用户拥有，检查每一个元素，它可以找到并分析了code结构，生成图表出它的处理器。你可能会在新版本中的问题。您可能能够处理未知的语言（通过添加的未知的节点图等），但只有这样做，如果是有道理不知何故构建 - 如果它是值得的麻烦。如果在使用了未知的东西所面临的处理器就不会成为有用的多，这或许应该坚持一个特定的Java版本。

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.

无论使用何种政策，在我看来，最好的办法是监测的语言即将发生的变化，并相应地更新处理器。在Java 7例如，项目硬币引入了一些新的语言功能，这是最有可能甚至没有可见的处理器。另一方面的Java 8确实有新的构造，这将影响处理，例如类型注释。新的语言功能不发生，经常的，所以有机会，你甚至不需要改变任何东西很长一段时间。

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屋！