sdk list java lists the following Java versions:
| | 25.0.3.fx | librca | | 25.0.3.fx-librca
| | 25.0.2 | librca | | 25.0.2-librca
but doesn't list 25.0.3-librca
Other absent versions
8.0.492-librca11.0.31-librca17.0.19-librca21.0.11-librca
What seems to be the problem:
FoojayClient.defaultQueryParams sends latest=available to Disco. BellSoft ships two GA tarballs per slot under identical java_version / release_status / directly_downloadable / javafx_bundled / architecture / archive_type / libc_type / package_type:
bellsoft-jdk<ver>-linux-amd64.tar.gz (standard)bellsoft-jdk<ver>-linux-amd64-lite.tar.gz (lite)
Disco's AVAILABLE branch (DiscoService.java:349-401 in the foojayio/discoapi) deduplicates with Pkg.equalsExceptUpdate. That comparator covers distribution, feature/interim version, arch, OS, libc, packageType, releaseStatus, archiveType, ToS, javafxBundled, directlyDownloadable, but not filename, size, or any lite flag.
So the two tarballs are "equal except update", Stream.max(comparing(VersionNumber)) ties, and the survivor is whatever the underlying CopyOnWriteArraySet iterator hands over first. That order is undefined and was apparently stable enough to land on the standard tarball through 8u482, then flipped to lite for 8u492.
Then in this repo, JavaMigration.execute runs Package.libericaFilenameDoesNotContainLite (JavaMigration.java:53), the only result is dropped, .max() returns empty, no version request is built.
Worse — version=8.0.482&latest=available also now returns the 8.0.492 lite tarball. Disco's dedup collapses across update versions too, so even pinning the update version doesn't escape the bug.
sdk list javalists the following Java versions:but doesn't list
25.0.3-librcaOther absent versions
8.0.492-librca11.0.31-librca17.0.19-librca21.0.11-librcaWhat seems to be the problem:
FoojayClient.defaultQueryParamssendslatest=availableto Disco. BellSoft ships two GA tarballs per slot under identicaljava_version/release_status/directly_downloadable/javafx_bundled/architecture/archive_type/libc_type/package_type:bellsoft-jdk<ver>-linux-amd64.tar.gz(standard)bellsoft-jdk<ver>-linux-amd64-lite.tar.gz(lite)Disco's
AVAILABLEbranch (DiscoService.java:349-401in the foojayio/discoapi) deduplicates withPkg.equalsExceptUpdate. That comparator covers distribution, feature/interim version, arch, OS, libc, packageType, releaseStatus, archiveType, ToS, javafxBundled, directlyDownloadable, but not filename, size, or any lite flag.So the two tarballs are "equal except update",
Stream.max(comparing(VersionNumber))ties, and the survivor is whatever the underlyingCopyOnWriteArraySetiterator hands over first. That order is undefined and was apparently stable enough to land on the standard tarball through 8u482, then flipped to lite for 8u492.Then in this repo,
JavaMigration.executerunsPackage.libericaFilenameDoesNotContainLite(JavaMigration.java:53), the only result is dropped,.max()returns empty, no version request is built.Worse — version=8.0.482&latest=available also now returns the 8.0.492 lite tarball. Disco's dedup collapses across update versions too, so even pinning the update version doesn't escape the bug.