Originally reported via @wilkinsona

On https://docs.spring.io/spring-security/site/docs/5.7.0-SNAPSHOT/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html, if I search for WebSecurityConfigurerAdapter and click on the only result in the Types section, I takes me to https://docs.spring.io/spring-security/site/docs/5.7.0-SNAPSHOT/api/undefined/org/springframework/security/config/annotation/web/configuration/WebSecurityConfigurerAdapter.htmlwhich 404s.

It appears to be related to https://bugs.openjdk.java.net/browse/JDK-8215291 which was fixed in JDK 12. This seems to be confirmed by the fact that https://docs.spring.io/spring-security/site/docs/5.7.0-SNAPSHOT/api/org/springframework/security/config/annotation/web/builders/HttpSecurity.html works properly and is using JDK 17.

There are reports that adding --no-module-directories will fix the links, but it also breaks links to classes and interfaces that are in modules (i.e. JDK classes/interfaces).

Comment From: sjohnr

@rwinch I've tested in SAS that adding options.addBooleanOption("-no-module-directories", true); (single dash) works. (See https://stackoverflow.com/a/53732633/15835039). We can add it to JavadocOptionsPlugin.

Is this something we want to do for 5.6/5.7 or are there places where I could check whether links would break?

Comment From: rwinch

@sjohnr Thanks for looking into this. Can you confirm that links to things like the Servlet APIs and standard JDK classes still work? Right now it appears that the links to things like String do not work in SAS. For example ProviderContext#getIssuer() does not link to the JDK's String Javadoc. However, if you look at Spring Security's ConfigAttribute#getAttribute() it does link to the JDK Javadoc. Based on the reports I have seen the no-module-directories option is what broke these links for others.

Comment From: sjohnr

It looks like it wasn't working beforehand either. If you see ConfigAttribute.html#getAttribute() on 5.6.3, String also doesn't have a link. So perhaps the linking was another part of what was fixed after JDK 11, and we just live with it?

Comment From: rwinch

Can you try the changes in Spring Security main and ensure it is still linking to the JDK and servlet APIs? If it is, then yes please make the change.

Comment From: sjohnr

Looks like it completely fails the build because it's an invalid flag in JDK 17. ☹️ The buildSrc integration tests catch it prior to running the build.

Comment From: sjohnr

It's not great, but we could check the Jvm.current().javaVersion before applying the option.

Comment From: rwinch

Will that help given that we build with JDK 17 in main?

Comment From: sjohnr

Can you try the changes in Spring Security main and ensure it is still linking to the JDK and servlet APIs?

I got confused, sorry. I thought you meant we wanted to keep main, 5.7.x, etc. consistent with each other. Since links and search are not broken in main and this change is not needed on JDK 17, I'm wondering if we can just make a change in non-main branches? In that case, ignore my comment above.

Comment From: rwinch

Yes I think we can change the branches differently to fix the problem