Add redirect from api/latest to the Javadoc of the latest release.

[chaoren]

Also:

• Added badges for the latest and snapshot versions of Javadocs.
• Fixed the whitespaces in the generated HTML files.
• Fixed the config so that the website works on local development servers.
• Removed some unused files.
• Added a basic 404 page.

[cpovirk]

This is very cool, but I am worried that there will be undesirable effects from using a 404 for this.

Not that our current implementation is particularly principled: wget https://guava.dev/ImmutableList downloads a page that is only a redirector to the real page. (With the 404 approach, it produces no local file or meaningful output, but again, that's not much of a loss in practice—as if anyone is using wget in the first place :))

Still, I could imagine that this would upset a broken-link detector, prevent indexing of the pages that we redirect to, and maybe interfere with other thing that I wouldn't have foreseen just because it's a somewhat unusual use case.

If this is something that you want to see through, are there other ways to accomplish the main goals? I'm not sure there's any reason that we need to use md files instead of our own html pages, for example. We might also be able to have only a single source page that uses JavaScript as you've configured here (I guess with symlinks pointing there from ImmutableList/index.html or whatever), though I wonder if the JavaScript also causes problems relative to the <meta http-equiv="refresh" ...> approach that the current redirect pages also use.

To the extent that the goal is to have the redirectors point to a "latest release" page instead of a "latest snapshot" page, I am still iffy on that as a goal, but I wouldn't stand in the way if it feels worthwhile to you. If latest-jre were a symlink, and if our shortcuts redirected to pages under that symlink, would that help? (That might lead back to a discussion about whether we'd want latest-jre to redirect to 33.4.0-jre or to serve content from the original URL.)

[chaoren]

Still, I could imagine that this would upset a broken-link detector, prevent indexing of the pages that we redirect to, and maybe interfere with other thing that I wouldn't have foreseen just because it's a somewhat unusual use case.

Yeah, I think the redirect pages are tagged noindex, so the pages themselves won't be indexed, but the links contained in them will be followed. The 404 page itself won't contain any links.

If this is something that you want to see through, are there other ways to accomplish the main goals?

We could also just write our own generator plugin: https://jekyllrb.com/docs/plugins/generators/

I'm not sure there's any reason that we need to use md files instead of our own html pages, for example.

It's not necessary, but I wanted to reuse the theme of the website and that involves reusing the layout. Writing our own html would require duplicating most of the layout boilerplate.

[cpovirk]

Yeah, I think the redirect pages are tagged noindex, so the pages themselves won't be indexed, but the links contained in them will be followed. The 404 page itself won't contain any links.

I do hope that it works correctly now, though I'm not even sure how I'd go about confirming that. My expectation is that it would stop working if the page started returning a 404—and maybe even if it continued to return a 200 but used only JavaScript for the redirect. Google's docs suggest that JavaScript redirects should work, but I don't know how sophisticated the detection is, and of course Google is not the only search engine :)

We could also just write our own generator plugin: https://jekyllrb.com/docs/plugins/generators/

That might be cleanest. I'm still comfortable with how things are now (at least now that the Javadoc link on the landing page is more prominent), but that does sound promising if we want a change.

I'm not sure there's any reason that we need to use md files instead of our own html pages, for example.

It's not necessary, but I wanted to reuse the theme of the website and that involves reusing the layout. Writing our own html would require duplicating most of the layout boilerplate.

Ah, sorry, I was talking about our existing zillions of .md pages. My assumption is that the "zillions" part of that slows down the generation of our web site, whereas a zillion .html files might not so much. That's not to say that we should actually worry about it.

[chaoren]

Okay, I've removed the 404 redirect stuff. Now it's just an automatic redirect to the latest API using the existing method. I can't just set redirect_to in the front matter like the other redirects since the link is based on a variable, so I just copied the HTML file and inserted the variable. This should allow us to resolve #7600 with our own Javadoc links and badges.

[cpovirk]

I am still somewhat against having a redirect to the latest release, since I worry that it will exacerbate the problem we see with links to random old versions of Guava's Javadoc instead of to an unchanging latest/snapshot URL. From that perspective, I'd prefer if a URL like https://guava.dev/releases/latest/api/docs/ would serve the content that's currently at https://guava.dev/releases/33.4.0-jre/api/docs/ in place and then update as we release new versions. (I don't know if a symlink would accomplish that or not, but I acknowledge that even a symlink would need to be updated by our release script (though I think that's easy enough).) In the absence of a latest URL whose content updates in place, I'd steer users toward https://guava.dev/releases/snapshot-jre/api/docs/, which I might prefer over latest even if latest did exist, though the tradeoffs there are more interesting. But you've more than put in your time on this, and if it's something you believe it, I don't anti-believe in it enough that I'd want to stand in the way :)

(Separately: I had been thinking that parts of our gh-pages branch come from Piper's jcl_gh_pages for sharing with Truth, Dagger, and Flogger, but I guess that's not the case, so we're free to change them here and not care about those projects.)

Sorry for taking so long to get to this again.