Add support for multiple distributions via the Disco API

[giltene]

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. https://github.com/actions/setup-java/issues/13, https://github.com/actions/setup-java/issues/68, https://github.com/actions/setup-java/issues/69, https://github.com/actions/setup-java/issues/70, https://github.com/actions/setup-java/issues/71, https://github.com/actions/setup-java/issues/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 (https://github.com/actions/setup-java/issues/13, https://github.com/actions/setup-java/issues/68, https://github.com/actions/setup-java/issues/69, https://github.com/actions/setup-java/issues/70, https://github.com/actions/setup-java/issues/71, https://github.com/actions/setup-java/issues/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.

[joschi]

It would be great if we could address the user-tracking aspect in the foojay Disco API. https://github.com/foojay2020/discoapi/issues/20

[maxim-lobanov]

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]

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 adopt since that was the first and most popular request and to introduce some of the breaking changes needed to support that: https://github.com/actions/setup-java/issues/13

With 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 (adopt and zulu). If the Disco API works well for newer distributions, then we could switch over adopt and zulu to 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).