Hi Andriy, Think it makes sense but wanted to mention another option:
1. At dev time you do what you did + use ASMifer to generate CXFJavaNxxxxxASMGenerator classes 2. You package them all normally 3. At run time you pick the right one depending java.version value, generate the bytecode and load it through a new dedicated classloader. Then, if you ensure you implemented a common interface you just call it 4. Still requires toolchain to test on breaking java version (surefire) Hope it makes sense Le jeu. 11 juil. 2019 à 04:29, Andriy Redko <[email protected]> a écrit : > Hey guys, > > It's been a few weeks I have noticed that out builds against OpenJDK 13 > started to fail, suddenly, > right after it entered the rampdown phase. So I started to look at the > cause and opened the Pandora > box. There are quite a few details squeezed into this message, but I would > really appreciate the feedback > for the approach being explored [1]. > > 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 [4], 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 PR is out [1]. > > 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. The tests I have done so far have > shown that the approach works really well, depending on the JDK project > uses, the right implementation is being > picked up. What do you think guys, does it make sense? Any other options > to consider? > > Thanks a lot! > > [1] https://github.com/apache/cxf/pull/566 > [2] https://bugs.openjdk.java.net/browse/JDK-8215608 > [3] https://jdk.java.net/13/release-notes > [4] https://bugs.openjdk.java.net/browse/JDK-8199325 > > Best Regards, > Andriy Redko > > >
