New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inheriting Javadoc from the JDK _and_ linking to the JDK broke at some point #6790
Comments
I can reproduce this locally with |
Yes, I can fix it by removing the I could believe that the problem is somehow related to modules. Roughly, the JDK sources might be "hidden" by the JDK modules? I briefly tried messing with the path we pass to Javadoc, passing I tried removing our exclusion of the JDK's
So it's possible that things would go better if Guava were a real module (#2970). (Presumably Javadoc would be willing to inherit Javadoc across module boundaries.) I could probably "fix" this by setting the Javadoc source version back to 8 for JDK 11 (where we know that it works). But we know that it doesn't work for JDK 17, so this would be only a temporary fix. |
I guess I'm somewhat pessimistic about that, given that the sources probably are being hidden entirely. But I could believe that we could do something with I'm not excited about trying to get this to work, but if anyone wants to try to wire it up, either the temporary solution of using |
Oh, and in all this, I've been forgetting about the problem linking to the JDK. I would guess (but haven't checked) that that problem is a result of the same commit as the other problem. It may be related to how we still link (well, try to link) to JDK 9, which of course supports the module system but does not yet include the module name in the path of the Javadoc it produces. |
It looks like #7087 fixes linking in snapshot Javadoc by switching to Java 21 for snapshot-Javadoc generation. If we want to make things work for our releases, then we can do that by using Java 21 for our releases, too. (Now, I've always been in the habit of using snapshot Javadoc, myself. But I don't know what most users do.) If we switch to Java 21, we'll have to be careful to continue to generate bytecode that works under older versions (which |
(Snapshot docs are built by a different workflow task/whatever than snapshots themselves, so we could also use Java 21 for one but not the other. Releases currently use the same Java version for each.) |
Drops the JDK source steps involved with Javadoc builds, as suggested in #7089. There will be some build warnings related to Javadoc until subsequent PRs are merged. Signed-off-by: Sam Gammon <sam@elide.ventures> Gives up on the "inherting" half of #6790. Fixes #7092 RELNOTES=n/a PiperOrigin-RevId: 614681928
Drops the JDK source steps involved with Javadoc builds, as suggested in #7089. There will be some build warnings related to Javadoc until subsequent PRs are merged. Signed-off-by: Sam Gammon <sam@elide.ventures> Gives up on the "inherting" half of #6790. Fixes #7092 RELNOTES=n/a PiperOrigin-RevId: 614693592
Wait, no, #7087 (aka #7102 aka f2b8c4f) causes Javadoc generation to fail?
I had tested something locally, but I guess it wasn't that. For now, I'll roll back to JDK 11. |
(i.e., roll back a small portion of cl/615151162) It turns out that Javadoc snapshots [fail when using Java 21](#6790 (comment)). RELNOTES=n/a PiperOrigin-RevId: 615518606
(i.e., roll back a small portion of cl/615151162) It turns out that Javadoc snapshots [fail when using Java 21](#6790 (comment)). RELNOTES=n/a PiperOrigin-RevId: 615532809
Linking to the JDK works with a Java 21 (and perhaps earlier versions), so that's a reason to generate docs with a newer version once we can. (We'd want to think about both what we do for snapshots and what we do for releases.) Inheriting docs from the JDK doesn't work automatically, so I'd probably continue not to worry about it. The only javadoc-21 blocker I remember offhand is JDiff, which I'm assuming is responsible for the error reported just above. |
e.g., https://guava.dev/BiMap has blank descriptions for
put
,putAll
, andvalues
, and it has no links for types likejava.lang.Object
andjava.util.Map
The text was updated successfully, but these errors were encountered: