I took a pass through jenkins-infra/jenkins.io and found the following content that references Java 8 that needs updating:

• content/doc/administration/requirements/java.adoc states "Java 8 or Java 11 are required for running modern versions of Jenkins." When we begin requiring Java 11, this will need to change to "Java 11 is required for running modern versions of Jenkins."
• content/doc/administration/requirements/jenkins-on-java-11.adoc was originally the home of special instructions for Java 11. We now have an equivalent Java 17 page with special instructions for Java 17. The "Running Jenkins on Java 11" page is now redundant and obsolete. The entire page can be deleted, along with all references to it.
• content/doc/administration/requirements/upgrade-java-guidelines.adoc explains what to do "if you need to remain with Java 8 in a Docker container." When we require Java 11, this will be unsupported, so this text should be deleted. Since the preceding sentence only serves to create a contrast with the sentence that is to be deleted, it should also be deleted (or at the minimum rephrased to not create a contrast).
• content/doc/book/installing/_jenkins-command-parameters.adoc contains a section for "Java 11, Java 8u252, and later" and a separate section for "Java 8u242 and earlier". With the requirement of Java 11, the latter section can be deleted entirely, and the former section can be renamed to just "Java 11". Having renamed the former section and deleted the latter section, there remains a single "Java 11" subsection beneath "Using HTTP/2" in the document heading hierarchy. This no longer makes sense, since the only reason for having two sections in the first place was to contrast the two versions of Java. So the hypothetical remaining "Java 11" subsection is unnecessary and should be inlined into the main "Using HTTP/2" section.
• content/doc/pipeline/tour/getting-started.adoc contains a prerequisite of "Java 8 or 11". With the requirement of Java 11, this prerequisite should be changed to "Java 11".

Note that a perennial issue with documentation for major changes is that jenkins.io covers both weekly and LTS releases. This makes for an awkward period when the major change has landed in weekly but not yet in LTS. Choices are:

• Revise the documentation to describe both weekly and LTS, then revise it again when the major change ships in LTS. (Ideal, but the most work.)
• Revise the documentation to describe the major change when it has shipped in a weekly, accepting that the documentation will be off for LTS users for a few months. (Not ideal, but probably good enough in many cases.)