Make the Adoptopenjdk package type look at the Temurin repo first for latest assets#522
Conversation
|
I'm wondering whether we could add an annotation the pipeline to alert users to the fact that they should switch to temurin as their distro if the version they have requested is matched in temurin. |
|
@ IvanZosimov can I get your thoughts on this PR please. |
|
Hi, @johnoliver and @gdams 👋 Actually, we have a piece of documentation about this problem: https://github.com/actions/setup-java#supported-distributions. Frankly speaking, we'd better wait for the official announcement of the full deprecation of the AdoptOpenJDK; after that, we could make an announcement for our customers. Given that many customers are aware of the deprecation but continue to use the outdated versions, the warning option also doesn't seem to be the best as it could create a lot of noise. |
@IvanZosimov If you're looking for an official deprecation you can consider this blog post exactly that: https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/. The challenge here is that there are several Java versions that we released at AdoptOpenJDK that we don't release at Adoptium (e.g JDK 12-15 and 9-10). The idea of this change is that it will preserve functionality for those specific users but get the majority of users onto the newer API. As a side note, we should have a discussion with the dependabot team at some point to work out a plan for updating people's workflows. |
|
@IvanZosimov what are your thoughts here? We'd love to find a solution to take some of the requests off our old API |
|
@johnoliver looks like you need to run prettier and generate the |
|
ping @IvanZosimov it would be good to make some progress here |
|
Hi, @gdams and @johnoliver 👋 I apologize for taking so long to respond, we are overwhelmed at the moment! We discussed the idea of PR, and it seems acceptable to us. I think you can convert this PR to the real one, and we will take a look at it as we have time. |
|
I have just noticed that the tests need fixing, will get on updating this |
|
Tests are fixed |
|
@IvanZosimov this is good for review now |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
@aparnajyothi-y any update here please? |
johnoliver
force-pushed
the
update-adoptopenjdk
branch
from
5321a4d to
bf12c83
Compare
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR updates the AdoptOpenJDK installer to preferentially resolve Hotspot downloads via Eclipse Temurin (with notices guiding users to switch), while keeping an internal fallback to the legacy AdoptOpenJDK flow.
Changes:
- Exposes Temurin’s package-resolution method so it can be used by other distributions.
- Adds Temurin-backed resolution for Adopt/Hotspot with user notices and a fallback to the old AdoptOpenJDK lookup.
- Refactors the prior Adopt lookup into a separate private method.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| src/distributions/temurin/installer.ts | Makes Temurin package lookup callable from outside the class (visibility change). |
| src/distributions/adopt/installer.ts | Adds Temurin fallback for Adopt Hotspot; retains old Adopt lookup behind a private method. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Use strict equality (===, !==) instead of loose equality (==, !=) for all comparisons
- Properly handle caught errors with instanceof type narrowing before accessing properties
- Only fall back to legacy AdoptOpenJDK for specific version-not-found errors
- Rethrow unexpected errors to avoid masking real issues (network failures, rate limits, etc.)
- Fix error message check to match actual error text ('No matching version found')
- Remove unnecessary undefined check since method return type is never undefined
- Add @internal JSDoc annotation to TemurinDistribution.findPackageForDownload()
- Update tests to properly mock Temurin lookup failures for fallback behavior testing
- Rebuild dist files
- Change error handling to gracefully fall back for all errors, not just version-not-found - Log version-not-found errors as notices with migration guidance - Log other Temurin failures as debug messages for troubleshooting - Improves resilience: users always get a result even if Temurin API has issues - Maintains visibility: failures are still logged for debugging
We are looking to move people off of the old deprecated Adoptopenjdk API to the Temurin API for Hotspot builds.
For the vast majority of binaries, the Temurin API will contain the one you want, the outlier cases are:
In both cases it means that they are using very old builds.
In order to move to the new API, this PR is proposing that requests to AdoptDistribution, are requested against TemurinDistribution first, if they cannot be satisfied by Temurin, then continue the existing unchanged AdoptOpenJDK logic. For the VAST majority of requests, they will be satisfied by Temurin, for the few remaining outliers described above, they will make a second request to the old AdoptOpenJDK API.
I am submitting this as a draft to ask if this approach is acceptable in principle.