我想为标准Java API中存在的类，其方法和枚举值绘制出Java版本，因为这些版本。例如，自Java 1.0和 String :: strip（）方法以来，标准类字符串自Java 11以来存在。类和该方法都具有@由于在其Javadocs中使用适当的Java版本标记，这就是我要编程扫描的标签。
也许还有另一种方式，与Javadoc无关？例如，由于Java 9，编译器支持 -Release 参数，除其他外，还可以检查使用的API与所选版本的Java版本的兼容性。如果是 -Release 10 和带有 String :: strip :: strip（）的代码>汇编错误。编译器如何做？它是在每次汇编过程中扫描 src.zip javadocs还是使用更智能的技术？
I want to make a map of Java versions to classes, their methods and enum values that exist in the standard Java API since those versions. For example the standard class String exists since Java 1.0 and the String::strip() method exists since Java 11. Both the class and the method have the @since tag with the appropriate Java version in their javadocs and this is what I want to scan programmatically.
Maybe there is another way, not related to javadoc? For example since Java 9 the compiler supports the -release argument that among other things checks the compatibility of the used APIs with the chosen version of Java release. In case of -release 10 and a code with String::strip() a compilation error is thrown. How does the compiler do it? Does it scan the src.zip for javadocs during every compilation or use a smarter technique?
发布评论
评论（1）
解析
@since可能是错误的，因为有一些陷阱：string.startswith（string）有@since 1.0但 没有@since标记href =“ https://bugs.openjdk.java.java.net/browse/jdk-8260561” rel =“ nofollow noreferrer”> jdk 可以查看“ nofollow noreferrer”>“新” tab 该文档的在Java 17中添加 jdk-8265055 （这是基于
@since信息）。- 版本javac的选项使用jdk安装中的文件lib/ct.sym，它存储了先前版本的公共API的信息。请参阅sun.misc.unsafe但是，有第三方工具可让您生成或比较Java API签名：
Parsing
@sincemight be error-prone because there are some pitfalls:String.startsWith(String)has@since 1.0butString.endsWith(String)has no@sincetagIf you as developer just want to know which new API was added, you can have a look at the "New" tab of the documentation, added in Java 17 by JDK-8265055 (this is based on the
@sinceinformation).The
--releaseoption ofjavacuses the filelib/ct.symfrom the JDK installation which stores information about the public API of previous versions. See the "Implementation" section of JEP 247. There are however some pitfalls with this as well:sun.misc.UnsafeThere are however third-party tools which allow you to generate or compare the Java API signatures: