RFR: 8202617: javadoc generates broken links to undocumented (e.g. private) members

[Nizar Benalla]

On Thu, 31 Oct 2024 12:34:09 GMT, Hannes Wallnöfer <hannesw at openjdk.org> wrote:

>> Please review this patch to prevent links to private and package-private members to be generated.
>> The bug happens when you link to private/package-private members, and javadoc used to generated links to them (assuming they were inherited because the holder is unreachable).
>> 
>> Taking the code path I changed is very rare, as it only used by 4 anchors in 4 classes in all the JDK.
>> 
>> if (refSignature.trim().startsWith("#") &&
>>                     ! (utils.isPublic(containing) || utils.isLinkable(containing))
>> 
>> 
>> The classes that used it are `StringBuilder`/`StringBuffer` with `#append(java.lang.String)` and `ZipEntry`/`ZipOutputStream` with `#CENHDR`
>> 
>> 
>> I've expanded the test to check whether the links are created when they should be.
>> 
>> The generated documentation before and after the change are identical.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java line 253:
> 
>> 251:             if (refSignature.trim().startsWith("#") &&
>> 252:                     ! (utils.isPublic(containing) || utils.isLinkable(containing)) &&
>> 253:                     ! (utils.isPrivate(refMem) ||utils.isPackagePrivate(refMem))) {
> 
> Shouldn't this take into account whether we are running with -private or -package options? Ideally using utils.isIncluded(Element) would take care of this and give the right answer in all cases, although I haven't tried.

I will double check how this affects the `-package` option but this code path is not taken when using `-private`. I assume that's because the holder will then be accessible

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21802#discussion_r1824399996