Update Oracle livechecks

[MTCoster]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

---

Oracle has a publicly documented API for fetching information about Java releases, let's use it.

I only started digging into this because the graalvm-jdk livecheck was failing and the HTML scraping behind it appeared incredibly fragile.

I haven't touched the oracle-jdk-javadoc casks because those also require an additional hash as part of the version string which isn't available from the API. Given those casks already use a two-stage livecheck, should I replace the HTML-scraping first stage with the new API?

Am I correct in assuming the @17 variants of these casks shouldn't have a livecheck since they're marked for removal?

[MTCoster]

• graalvm-jdk runs are failing because the tarball contains a directory with the version 24.0.2+11 instead of 24.0.2+12 🤦
• oracle-jdk@21 runs are failing because I got a URL wrong, although that wasn't caught locally for some reason (perhaps I forgot to test that one with --autobump) the URL is right, no idea why that one failed.

[krehel]

Am I correct in assuming the @17 variants of these casks shouldn't have a livecheck since they're marked for removal?

Yeah, Oracle has decided to gate the downloads for 17 behind both a license acceptance and a login screen to obtain the download. No need to update them.

[samford]

JDK livecheck blocks have always been a pain, so this is much nicer. A few changes below but otherwise this makes sense to me.

[MTCoster]

@samford, do you have any thoughts on making use of these APIs for the oracle-jdk-javadoc casks?

[samford]

do you have any thoughts on making use of these APIs for the oracle-jdk-javadoc casks?

It depends on whether the documentation zip is made available at the same time as the other files (like the dmg used in oracle-jdk). If there isn't any delay between when the release is published in the currentJavaReleases endpoint and when the doc zip is available, then updating oracle-jdk-javadoc to simply use cask "oracle-jdk" (so it uses the oracle-jdk livecheck block) would be fine. If it's not clear whether that's the case or not, we can always use cask "oracle-jdk" and roll back to the existing livecheck block if it causes problems in the future.

[MTCoster]

do you have any thoughts on making use of these APIs for the oracle-jdk-javadoc casks?

It depends on whether the documentation zip is made available at the same time as the other files (like the dmg used in oracle-jdk). If there isn't any delay between when the release is published in the currentJavaReleases endpoint and when the doc zip is available, then updating oracle-jdk-javadoc to simply use cask "oracle-jdk" (so it uses the oracle-jdk livecheck block) would be fine. If it's not clear whether that's the case or not, we can always use cask "oracle-jdk" and roll back to the existing livecheck block if it causes problems in the future.

The issue here is that oracle-jdk-javadoc requires an additional hash value to build the download URL, so the livecheck is essentially two stages (get the latest version; scrape the download link for the hash).

The API for retrieving version information also provides direct download URLs (also under java.oraclecloud.com) but there don't appear to be documentation tarballs available there. I suspect there could well be delays one way or the other when updates are rolled out, but I couldn't tell you which way.

[samford]

Ahh, I was having to multitask earlier while looking through this, so apologies for missing details. It seems like the closest we could do for oracle-jdk-javadoc is to check the currentJavaReleases endpoint as the way of identifying the newest major version but we would still have to check the doc-downloads page to be able to match the hash from the URL, as you mentioned.

While it would be nice to align that check with the others, it's safest to maintain the existing livecheck block because that approach may do a better job of ensuring that the doc-downloads page exists for a given major version (as it matches the current link on the main download page). Using currentJavaReleases for the first part of oracle-jkd-javadoc may be fine but there's probably not a compelling reason to risk that being out of sync with the download page and causing the check to break (however brief). We can always revisit it in the future if/when the API provides a way of finding the newest doc zip URL, so it's fine to leave oracle-jdk-javadoc as-is for now.