Hey Romain,
Thanks a lot for the advice, I will give it try. Alhough I afraid it may not
work
in this particular case, for two reasons: we are not in control of common
interface
or/and classloader. Essentially, the class is passed to javadoc util as an
argument:
javadoc -doclet <class>
The pre-JDK13 javadoc doclet is just a class with a static method 'start',
since JDK13
it must implement the Doclet interface.
But I think the tecnique is interesting and may fit to more common cases, I
will explore that.
Thank you!
Best Regards,
Andriy Redko
RMB> Hi Andriy,
RMB> Think it makes sense but wanted to mention another option:
RMB> 1. At dev time you do what you did + use ASMifer to generate
CXFJavaNxxxxxASMGenerator classes
RMB> 2. You package them all normally
RMB> 3. At run time you pick the right one depending java.version value,
generate the bytecode and load it through a
RMB> new dedicated classloader. Then, if you ensure you implemented a common
interface you just call it
RMB> 4. Still requires toolchain to test on breaking java version (surefire)
RMB> Hope it makes sense
RMB> Le jeu. 11 juil. 2019 à 04:29, Andriy Redko <[email protected]> a écrit :
RMB> Hey guys,
RMB> It's been a few weeks I have noticed that out builds against OpenJDK 13
started to fail, suddenly,
RMB> right after it entered the rampdown phase. So I started to look at the
cause and opened the Pandora
RMB> box. There are quite a few details squeezed into this message, but I
would really appreciate the feedback
RMB> for the approach being explored [1].
RMB> The problem: our java2wadl plugin uses some part of Javadoc API to
extract the documentation pieces from the
RMB> Java classes / methods / parameters. Since OpenJDK13, this API has been
removed completely [2], [3]. To support
RMB> JDK13 and above, we essentially have to rewrite the implementation
completely. However, we would face another blocker
RMB> here: how to support JDK8-11 and JDK13+ at the same time?
RMB> The solution: use multi-release JAR. This is exactly the use case this
feature has been designed for. So what it means
RMB> is that java2wadl has additional source folder 'src/main/java13' with
JDK13 implementation. It would be it however there
RMB> is another subtle complication.
RMB> The complication: for multi-release JAR, the java2wadl has to be build
with 2 JDKs (ideally), pre-JDK13 and JDK13, or
RMB> alternatively by latest JDK13 twice, once for 'src/main/java' (using
--release 8) and once for 'src/main/java13'
RMB> (equivalent to --release 13). The issue is that Javadoc-related API comes
from tools.jar, which is not in scope
RMB> of javac's --release flag [4], it really needs to be built by JDK8. As
the workaround, we could used --release 9 to
RMB> mitigate this issue (since tools.jar was merged into JDK9+). This is not
ideal (see please the next paragraph) but
RMB> we get JDK13 builds back on track, the PR is out [1].
RMB> The impact: as of now, since our release jobs are using JDK8, there is no
impact on release artifacts BUT java2wadl
RMB> will fail when used with JDK13+ea builds. When JDK13 is out, we could
rely on toolchain plugin to build java2wadl with
RMB> 2 JDKs (JDK8 and JDK13).
RMB> I think this is the first real precedent when we have to deal with large
features / API removal from JDK, whereas
RMB> reflection served as very well before. But this is certainly not the last
one. The tests I have done so far have
RMB> shown that the approach works really well, depending on the JDK project
uses, the right implementation is being
RMB> picked up. What do you think guys, does it make sense? Any other options
to consider?
RMB> Thanks a lot!
RMB> [1] https://github.com/apache/cxf/pull/566
RMB> [2] https://bugs.openjdk.java.net/browse/JDK-8215608
RMB> [3] https://jdk.java.net/13/release-notes
RMB> [4] https://bugs.openjdk.java.net/browse/JDK-8199325
RMB> Best Regards,
RMB> Andriy Redko
