You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by GitBox <gi...@apache.org> on 2019/07/11 02:17:41 UTC

[GitHub] [cxf] reta opened a new pull request #566: CXF-8066: Support Doclet API (JDK13+)

reta opened a new pull request #566: CXF-8066: Support Doclet API (JDK13+)
URL: https://github.com/apache/cxf/pull/566
 
 
   The problem
   ===
   Our `java2wadl` plugin uses some part of Javadoc API to extract the documentation pieces from the
   Java classes / methods / parameters. Since OpenJDK13, this API has been removed completely [2], [3]. To support JDK13 and above, we essentially have to rewrite the implementation completely. However, we would face another blocker here: how to support JDK8-11 and JDK13+ at the same time?
   
   The solution
   ===
   Use multi-release JAR. This is exactly the use case this feature has been designed for. So what it means 
   is that `java2wadl` has additional source folder `src/main/java13` with JDK13 implementation. It would be it however there is another subtle complication. 
   
   The complication 
   ===
   For multi-release JAR, the java2wadl has to be build with 2 JDKs (ideally), pre-JDK13 and JDK13, or 
   alternatively by latest JDK13 twice, once for `src/main/java` (using `--release 8`) and once for `src/main/java13` (equivalent to `--release 13`). The issue is that Javadoc-related API comes from `tools.jar`, which is not in scope of javac's `--release` flag, it really needs to be built by JDK8. As the workaround, we could used `--release 9` to mitigate this issue (since `tools.jar` was merged into JDK9+). This is not ideal (see please the next paragraph) but we get JDK13 builds back on track.
   
   The impact
   ===
   As of now, since our release jobs are using JDK8, there is no impact on release artifacts BUT `java2wadl` 
   will fail when used with JDK13+ea builds. When JDK13 is out, we could rely on toolchain plugin to build `java2wadl` with 2 JDKs (`JDK8` and `JDK13`).
   
   I think this is the first real precedent when we have to deal with large features / API removal from JDK, whereas reflection served as very well before. But this is certainly not the last one. 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services