gpt4 book ai didi

java - 向前兼容 Java 6 注释处理器和 SupportedSourceVersion

转载 作者:IT老高 更新时间:2023-10-28 20:42:04 26 4
gpt4 key购买 nike

我正在为一个项目试用 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_6SourceVersion的Java 7版本引入了RELEASE_7

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

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

Querdydsl bug report其中使用了

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

Oracle blog其中评论者建议支持最新的源代码版本

最佳答案

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

在提到的 Oracle blog 中还有另一个条目,这提出了两个关于前向兼容性的政策:

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

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

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


好的,我想适本地处理未知语言结构听起来有点模糊,所以这里有一些例子。

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

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

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

关于java - 向前兼容 Java 6 注释处理器和 SupportedSourceVersion,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8185331/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com