You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Andriy Redko <dr...@gmail.com> on 2019/07/11 02:29:05 UTC
The need for multi-release JAR(s)
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
Re: The need for multi-release JAR(s)
Posted by Andriy Redko <dr...@gmail.com>.
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 <dr...@gmail.com> 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
Re: The need for multi-release JAR(s)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <dr...@gmail.com> 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
>
>
>
Re: The need for multi-release JAR(s)
Posted by Freeman Fang <fr...@gmail.com>.
Hi Andriy,
multi-release JAR makes sense for this scenario IMO. I’d say we were lucky we didn’t have to do this early, but eventually the API change in JDK add more complication in our build.
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
> On Jul 10, 2019, at 10:29 PM, Andriy Redko <dr...@gmail.com> wrote:
>
> 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
>
>