I think selective javadoc enables an anti-pattern that we should not
encourage. That said, we previously supported the feature, so we should
support it for some transitional period, giving downstream projects notice
of our intention to drop it (if we have such an intention), granting them a
chance
Sorry things have been hectic in my personal universe. Just a follow-up to
where this sits today.
* It doesn’t appear that there was a lot of discussion here so I’m guessing
most people don’t care?
* I missed that the patch that Owen provided does hack the API. I committed
that code change i
I'm +1 to remove the Javadoc functionality.
I'm not a fan of hacking the API. It's not a long-term solution.
In addition, personally I don't want selective javadocs. I want to look at
even @Private javadoc to develop Hadoop and its related projects.
-Akira
On Sun, Apr 10, 2022 at 11:46 AM Allen
I think we should go with the hack. At least for the projects where
I'm involved, being able to generate selective javadocs is a big
selling point for the audience annotations.
-busbey
the contents of this email should be treated as NOT A CONTRIBUTION
under the ALv2.
On Sat, Apr 9, 2022 at 9:46
Thanks to Owen, pretty much determined the only way to have feature
parity under JDK9+ is to extend an internal Java object (specifically
DocEnvImpl from jdk.javadoc.internal.tool.DocEnvImpl) . From what we can tell,
the new javadoc APIs do not provide a way (easy or otherwise) to rem
