Repository navigation
Add support for multiple distributions via the Disco API #142
Description
Description:
Add support for a new, optional "distro" property, and use the Foojay Disco API to locate JDK/JRE binaries for the requested distro, such that any distro supported by Disco (now or in the future) will automatically be enabled in actions/setup-java with no breaking changes to existing workflows needed.
Justification:
The ability to specify an OpenJDK distribution other than the default is often requested, and can be reflected in e.g. #13, #68, #69, #70, #71, #72 .
The Foojay Disco API was formed to provide a common, level-playing-field, community driven means of locating OpenJDK distribution binaries. It is specifically formulated to support semver-based version specification (in a way that is compatible with how java-version is specified in actions/setup-java) and provide a normalized way to translate a specification of a Java version spec and java package type to a URI pointing to matching OpenJDK distro binary if one exists. Using Disco will greatly simplify setup-java logic, and remove significant work (scanning CDNs or paginating through per-distro APIs in search of semver-satisfying matches in lists of possible binaries). It will also allow any new distros (once knowledge about them is added to Disco) to be immediately used in actions/setup-java with no change to the action code itself. The Disco project is committed to providing good coverage of OpenJDK and Java distros, and is already covering 9+ existing OpenJDK distributions in a way that is ready to tap here.
While some incremental work towards supporting the multitude of OpenJDK distributions has been contemplated and prototyped in v2.x, there are still some significant controversies around the form that support will take: E.g. will it be a breaking change, or an added [optional] property such that existing v1.x workflows will be able to move to v2.x without syntax modification or serious behavioral change?
Adding an optional property to v1.x, which will immediately and directly address (#13, #68, #69, #70, #71, #72), without creating a breaking change or incompatibility to any of the 60K+ workflows using actions/setup-java right now, is quite straightforward. I propose that we move ahead with that while the choices around stuff debated for v2.x get worked out in time.
A PR that achieves this goal will be submitted shortly.
Activity
joschi commentedon Mar 20, 2021
It would be great if we could address the user-tracking aspect in the foojay Disco API.
foojayio/discoapi#20
maxim-lobanov commentedon Mar 20, 2021
Thank you for your proposal but as @konradpabjan mentioned earlier and according to ADR, we would like to proceed with current approach in setup-java@v2 and use distributions API directly.
konradpabjan commentedon Mar 22, 2021
Down the road I'm open to using any API to expand support. That being said with V2 I would like to reiterate that the core goal was to initially add support for
adoptsince that was the first and most popular request and to introduce some of the breaking changes needed to support that: #13With a PR, to do things in phases I would recommend to first add support for new distributions via the Disco API and leave the distributions that are currently supported in the v2-preview as they are (
adoptandzulu). If the Disco API works well for newer distributions, then we could switch overadoptandzuluto use those as well.I do have have some security concerns too that might make this a blocker (following up on this). Using the Disco API introduces a single point of failure that if compromised could for example lead to malicious binaries being downloaded. Given that the Disco API is outside of the control of GitHub and the attack surface this could be very concerning for a lot of our customers (Enterprise in particular). The API is also fairly new (~3 months).
brunoborges commentedon Jun 23, 2026
Tracked under the epic #1049 (install multiple JDK distributions in one step). This issue stays open as a specific sub-request/approach.
brunoborges commentedon Jun 23, 2026
Thank you @giltene for this proposal, and to everyone who has weighed in over the years. After re-evaluating the current landscape, we've decided to close this as not planned. Here's our reasoning.
The original justification has largely been addressed. The core ask in 2021 was first-class support for distributions beyond the default (#13, #68–#72).
setup-javanow natively supports 12 distributions — Adopt/Temurin, Corretto, Dragonwell, GraalVM, JetBrains, Liberica, Microsoft, Oracle, SapMachine, Semeru, and Zulu — covering essentially all of the high-demand distros that motivated this request. The marginal benefit of routing through the Disco API today is mostly long-tail distributions.Per-distribution installers let us handle vendor-specific nuances. Each native installer can adapt to a vendor's own metadata API and quirks (for example, the recent Azul Metadata API work and its explicit
javafx_bundledhandling). A single generic resolver is less able to capture these details correctly.The architectural concerns raised when this was first reviewed still stand. To be clear, this is not a judgment on the quality of the Disco API, which is healthy, broad, and actively maintained (now at v3.0). The concerns are structural:
setup-javadoes not currently verify download checksums — so the transport would be the only integrity guarantee for a binary that becomes thejavaused by the rest of a workflow.If demand grows for a specific distribution that Disco covers and we don't, the most likely path forward is adding a dedicated native installer for it (tracked individually), rather than adopting Disco as a general resolver. Broader "install multiple distributions" work is tracked in #1049.
We're grateful for the proposal and the prototype work that went into it — it genuinely helped shape how distribution support evolved. Closing as not planned; happy to keep the conversation going if circumstances change.