adoptopenjdk / openjdk-api-v3 Goto Github PK

AdoptOpenJDK API V3 🚀

Home Page: https://api.adoptopenjdk.net/swagger-ui

License: Apache License 2.0

Shell 0.60% Kotlin 98.18% CSS 0.38% HTML 0.46% Dockerfile 0.38%

openjdk-api-v3's Introduction

NOTE: This repo is now deprecated/archived as github.com/adoptium/api.adoptium.net runs both api.adoptium.net and api.adoptopenjdk.net using vendor properties as a filter to do the correct thing on each domain.

AdoptOpenJDK API

NOTICE: AdoptOpenJDK API v1 has now been removed. If you are using v1 please move to the latest version (documented below) as soon as possible.

NOTICE: AdoptOpenJDK API v2 has been deprecated and will be removed. If you are using v2 please move to the latest version (documented below) as soon as possible.

Overview

The AdoptOpenJDK API provides a way to consume JSON information about the AdoptOpenJDK releases and nightly builds.
Sign up to the mailing list where major API updates will be announced, and visit adoptopenjdk.net to find out more about the community.

To learn more about how we build & run the API, check out CONTRIBUTING.md and the FAQs.

Usage

The API is documented via swagger. The swagger documentation can be viewed at: swagger-ui. The open api definition for this can be viewed at openapi.

For more information, including example queries, please look at STRUCTURE.md

Who's using the AdoptOpenJDK API?

The AdoptOpenJDK API has served over 200 million downloads by a wide variety consumers, from individuals to organisations.

Check the Download Statistics Dashboard for the latest numbers.

The following list highlights a small subset of consumers and their use-cases:

AdoptOpenJDK Website - the API drives the release listings on the AdoptOpenJDK website allowing individuals to download the JDK distribution of their choice
AdoptOpenJDK Docker Images - the API is used during the creation of the various official & unofficial Docker images
Gradle - the Gradle project defaults to use the API for its toolchains feature
Update Watcher for AdoptOpenJDK - uses the API to automatically manage the JDK installations on an individual's machine

openjdk-api-v3's People

Contributors

Stargazers

Watchers

openjdk-api-v3's Issues

Add Linux/riscv to the platforms available through the API (and website!)

These are available from the main pipelines at https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-riscv64-openj9/ but are not currently being published on the nightlies page at https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmVariant=openj9

Note; We've had to fake up java -version output due to cross compiling on this platform (https://github.com/AdoptOpenJDK/openjdk-build/pull/1762/files). This may have an impact on how the the API deals with this platform (If it's a problem we'll need a solution to adoptium/temurin-build#1773 first)

Integrate ktlint with Maven build lifecycle

I spotted that we're using ktlint for linting of our Kotlin code. It's currently executed as part of the CI build via a GitHub action but I wondered whether it's worth integrating this with the Maven build as per their docs or maybe via this dedicated Maven plugin?

The main benefit here is tying the linting into the standard Maven build life-cycle so we get faster and simpler (i.e. local setup) feedback rather than finding out we've broken a linting rule after pushing and waiting for CI to complete.

ongoing issue with website/v3api not showing latest openj9 releases

Seem this problem persists, the jdk-11.0.7+10_openj9-0.20.0 MacOSXL build that was publish last night, was still not visible midday today.... George had to manually update the API...
I think we need to get to the bottom of this issue?
Is it anything to do with github rate limiting?

Stripping HTTPS from Invalid URL

While playing around with the API, I made a invalid request to:

https://api.adoptopenjdk.net/v3/binary/jdk-14+36/linux/s390x/jdk/hotspot/normal/adoptopenjdk?project=jdk

The error message is slightly messed up:

RESTEASY003210: Could not find resource for full path: http://api.adoptopenjdk.net/v3/binary/jdk-14+36/linux/s390x/jdk/hotspot/normal/adoptopenjdk?project=jdk

Even though the invalid request was to a HTTPS link, the error message states that the request is to a HTTP link.

Add V3 examples to the documentation in addition to just the swagger UI

Examples will make it easier for people to easily migrate to the V3 API

Typos in the persistence module

🆕🐥🐶 First Timers Only

This issue is reserved for people who never contributed to Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

Spotted a couple of typos, not a big deal but would be nice to clean up at some point.

It must be checked where the folders are referenced in the repository and such places need to be fixed, too.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. You can join our community chat at Slack. Next to this you can find a general manual about open source contributions here.

Make configure_arguments available in the API

See adoptium/temurin-build#11

This may also be an api issue but we are now adding the bash configure output to the metadata from the builds. Assuming this will now automatically appear in the API, please provide this output on the download so users who are curious can see how exactly our binaries are built

/binary/latest API URL returns stale binaries

The /binary/latest endpoint suggests that the API should return actually the latest release for the given os/arch combination, but it doesn't:

$ curl -v https://api.adoptopenjdk.net/v3/binary/latest/8/ga/linux/x64/jdk/hotspot/normal/adoptopenjdk
*   Trying 104.17.158.60:443...
* TCP_NODELAY set
* Connected to api.adoptopenjdk.net (104.17.158.60) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=adoptopenjdk.net
*  start date: Apr 19 00:00:00 2019 GMT
*  expire date: Apr 19 12:00:00 2020 GMT
*  subjectAltName: host "api.adoptopenjdk.net" matched cert's "*.adoptopenjdk.net"
*  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5607a2696a40)
> GET /v3/binary/latest/8/ga/linux/x64/jdk/hotspot/normal/adoptopenjdk HTTP/2
> Host: api.adoptopenjdk.net
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 307 
< date: Tue, 05 Nov 2019 09:42:59 GMT
< content-length: 0
< set-cookie: __cfduid=d1455b5626fee0cf69e710690ce11e92b1572946979; expires=Wed, 04-Nov-20 09:42:59 GMT; path=/; domain=.adoptopenjdk.net; HttpOnly
< access-control-allow-origin: *
< location: https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u222b10.tar.gz
< set-cookie: cc44dc39b3169e71a02f8ff6e4f0d88c=d2bc38372eb6d12dfec8f23f7703d72e; path=/; HttpOnly; Secure
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 530de17aea6fcba8-VIE
< 
* Connection #0 to host api.adoptopenjdk.net left intact

So it redirects to OpenJDK8U-jdk_x64_linux_hotspot_8u222b10.tar.gz which is one security patch level behind. 8u232-b09 is latest.

Add the capability to track how many V2 request we're getting so we can plan deprecation

Nightly releases do not contain a single version

The current schema assumes that a given release contains releases of the same version. In fact we have a mix of versions inside nightlies.

Solution 1

Break api and move the version from the high level release object and onto the individual binary object. This is not great in general breaking backwards compatibility and would also probably complicate peoples handling logic.

Solution 2

Group binaries by version and return a release for each group, i.e if a release contains versions 11.0.7+1, 11.0.7+2 and 11.0.7+3. It would return 3 release objects one for each version.

Main issue with this is probably the id field that is on the Release people may have assumed that this would be a unique id, if we were to return 3 releases one for each version, all of them would have the same id. I doubt this would be a problem as I am not sure people will have treated the id in this way. Solution to the id problem would be either just have duplicate ids or remove the id field completely, between those I think I would go for having duplicate ids.

Use Chronological Order to Display Builds

The ordering of builds by date need some improvement since they aren't in chronological order as shown in the screenshot below.

Create new stats routes

Proposed Changes:

Back End

Store the following data every day:

total cumulative downloads
total cumulative downloads per version (e.g 8)
total cumulative docker pulls
total cumulative docker pulls per repo (official, openjdk11-openj9, openjdk8-hotspot etc)
daily downloads (total downloads today subtract yesterdays total)
daily downloads per version
daily docker pulls
daily docker pulls per repo (official, openjdk11-openj9, openjdk8-hotspot etc)

Front End

The proposed routes would look like this:

/v3/stats/downloads/total

[
  {
    "total": {
      "downloads": 7800000,
      "docker": 260000
     },
     "versions": {
       "downloads": {
         "8": 2900000,
         "9": 12000,
         "10": 12233,
         ...
      },
      "docker": {
        "official": 1200000,
        "openjdk8-hotspot": 21000,
        "openjdk8-openj9": 7600000,
        ...
      }  
    }
  }
]

/v3/stats/downloads/total/{version} // where version is a major version (e.g 8)

[
  {
    "jdk8u212-b03": 78000,
    "jdk8u242-b01": 32000,
    ...
  }
]

/v3/stats/downloads/total/{version}/{tag} // where tag is a release tag

[
  {
    "total": 670000,
    "platforms": {
      "linux-x64-hotspot": 323000,
      "linux-x64-XL-hotspot": 21000,
      "linux-s390x-openj9": 323000,
      ...
    }
  }
]

/v3/stats/downloads/tracking?days=365 // default to 30 days

[
  {
    "date1": {
      "total": 780000,
      "daily": 1200,
     },
    "date2": {
      "total": 780000,
      "daily": 1200,
     },
    ...
  }
]

/v3/stats/downloads/tracking/{source}?days=365 // where source is github or docker Optionally add ?version to filter by version or docker repo.

[
  {
    "date1": {
      "total": 780000,
      "daily": 1200,
     },
    "date2": {
      "total": 780000,
      "daily": 1200,
     },
    ...
  }
]

Add tip_version to the API

I have included there the 2 new fields most_recent_feature_version and tip_version that I would propose to address this issue

Originally posted by @johnoliver in #212 (comment)

Ability to request EA binaries the same as regular GA binaries without additional requests

I have the usecase that I want to download the latest available JDK for a specific Java version. Using the current APIs, I always need to do additional requests to properly feed the API:

Example: I want to download the latest JDK 15 for mac:

/v3/binary/latest/{feature_version}/{release_type}/{os}/{arch}/{image_type}/{jvm_impl}/{heap_size}/{vendor}

becomes:

/v3/binary/latest/15/{release_type}/mac/x64/jdk/hotspot/large/adoptopenjdk

This means I manually need to query release_type from some of the other APIs and those URLs are going to change the moment 15 GAs. Maybe a default that is automatically infered from the version number is enough.

Additionally, the heap_size option doesn't seem to be available in all combinations:

https://api.adoptopenjdk.net/v3/binary/latest/14/ga/mac/x64/jdk/hotspot/large/adoptopenjdk

The above query fails due to large heap size. This works:

https://api.adoptopenjdk.net/v3/binary/latest/14/ga/mac/x64/jdk/hotspot/normal/adoptopenjdk

Not sure if I can query this information somewhere or if it should properly downgrade if large is not available.

/info/available_releases includes 15, but the API returns 404 when using 15

Since today,

https://api.adoptopenjdk.net/v3/info/available_releases

includes 15, but the API returns 404 for other operations for 15, for example for

https://api.adoptopenjdk.net/v3/assets/feature_releases/15/ga

Add pretty print library

We should pretty-print the JSON responses from the API

Maybe we could have a flag that removes the pretty print if needed

Typos in

Track user-agent in API requests so we know how people are using it

I've mentioned this before but apparently haven't opened an issue on it. If possible it would be very useful to track how many requests are coming into the API via browsers, command line tools such as wget or other automatic install toolks like Chocolaty etc.

If we could have logs of the user-agent on each API download call that would be useful to see how many of our downloads are automated tools that people are using and how many are people just downloading using a browser.

[RFE] Provide a way to retrieve source tarball artifacts for a certain release

Being able to retrieve source tarball artefacts via the API would be needed so as to properly automate upstream testing which is currently done via this pipeline script:

https://github.com/AdoptOpenJDK/openjdk-tests/blob/master/buildenv/jenkins/upstream_openjdk_tests

In particular, there is no way to tell the testing system where/how to download the JDK sources from. It would be a problem for (upstream?) OpenJDK regression tests, only, but could be useful - if properly synthesized - for the adoptopenjdk provider as well.

I'm thinking something along the lines of:

/v3/sources/latest/{version}/{release_type}/{jvm_impl}/{vendor}
/v3/sources/{release}/{version}/{release_type}/{jvm_impl}/{vendor}

For the openjdk provider those queries would redirect to _sources* artifacts in the releases, for the adoptopenjdk provider it could perhaps redirect to a github archive url of the relevant sources.

Thoughts?

Inconsistent availability of "checksum" and "checksum_link"

It looks like the .[].binaries[].package.checksum_link attribute in the AdoptOpenJDK API v3 is inconsistently used.

For example in the list of AdoptOpenJDK 11 GA releases for Linux x64, only a little more than half of the releases have a valid checksum_link attribute:

# curl --silent 'https://api.adoptopenjdk.net/v3/assets/feature_releases/11/ga?architecture=x64&os=linux&image_type=jdk&page=0&page_size=100&project=jdk&sort_order=ASC&vendor=adoptopenjdk' | jq '.[].binaries[].package.checksum_link'
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11%2B28/OpenJDK11-jdk_x64_linux_hotspot_11_28.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11%2B28/OpenJDK11-jdk_x64_linux_openj9_11_28.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11%2B28/OpenJDK11-jdk_x64_linux_openj9_linuxXL_11_28.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.1%2B13/OpenJDK11U-jdk_x64_linux_hotspot_11.0.1_13.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.1%2B13/OpenJDK11U-jdk_x64_linux_openj9_jdk-11.0.1_13_openj9-0.11.0_11.0.1_13.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.1%2B13/OpenJDK11U-jdk_x64_linux_openj9_linuxXL-jdk-11.0.1_13_openj9-0.11.0_11.0.1_13.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.2_7.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B9/OpenJDK11U-jdk_x64_linux_hotspot_11.0.2_9.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B9/OpenJDK11U-jdk_x64_linux_openj9_linuxXL_11.0.2_9-openj9-0.12.0.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B9/OpenJDK11U-jdk_x64_linux_openj9_11.0.2_9_openj9-0.12.0.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B9_openj9-0.12.1/OpenJDK11U-jdk_x64_linux_openj9_11.0.2_9_openj9-0.12.1_openj9-0.12.1.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.2%2B9_openj9-0.12.1/OpenJDK11U-jdk_x64_linux_openj9_linuxXL_11.0.2_9_openj9-0.12.1-openj9-0.12.1.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.3%2B7_openj9-0.14.0/OpenJDK11U-jdk_x64_linux_openj9_11.0.3_7_openj9-0.14.0.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.3%2B7_openj9-0.14.0/OpenJDK11U-jdk_x64_linux_openj9_linuxXL_11.0.3_7_openj9-0.14.0.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.3%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.3_7.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.3%2B7_openj9-0.14.3/OpenJDK11U-jdk_x64_linux_openj9_11.0.3_7_openj9-0.14.3.tar.gz.sha256.txt"
"https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.3%2B7_openj9-0.14.3/OpenJDK11U-jdk_x64_linux_openj9_linuxXL_11.0.3_7_openj9-0.14.3.tar.gz.sha256.txt"
null
null
null
null
null
null
null
null
null
null
null

In the same selection, all of them have a valid checksum attribute:

# curl --silent 'https://api.adoptopenjdk.net/v3/assets/feature_releases/11/ga?architecture=x64&os=linux&image_type=jdk&page=0&page_size=100&project=jdk&sort_order=ASC&vendor=adoptopenjdk' | jq '.[].binaries[].package.checksum'
"e1e18fc9ce2917473da3e0acb5a771bc651f600c0195a3cb40ef6f22f21660af"
"fd77f22eb74078bcf974415abd888296284d2ceb81dbaca6ff32f59416ebc57f"
"c693342ffddb3e6107ac5e388a6d6d18e6da2c710d9c67224afdfa43813d0e05"
"22bd2f1a2e0cb6e4075967bfeda4a960b0325879305aa739a0ba2d6e5cd4c3e2"
"ef9bf07cba79082285a9d426ea4eb3e8df57561ce2afe07cc5f299a8fa203279"
"cac1fe096ea161613d5afe8a04ce3294dc1b535f5f4ea1a4235ce425b2610678"
"d89304a971e5186e80b6a48a9415e49583b7a5a9315ba5552d373be7782fc528"
"d02089d834f7702ac1a9776d8d0d13ee174d0656cf036c6b68b9ffb71a6f610e"
"7c1708106c03578603a71eec5cc8e45ab2d8d5753972303876043eeea27d2076"
"02de51ebe86897081f7998dd2f256e33fb8b15c70cf26715020795326cc50511"
"a9b298391dc0baf49e935683fb13b1b18ef5fd5b1d0e1a1318c8e425ffdbcbcd"
"05dae3fe24511b56aae061c99cc4a25e4b0e78782468bf5e432afb7ee3c4e7bc"
"7012edd56fc958070bc4747073de14ea08eb43081eb6ea19bdbf4763186e2d17"
"3b00b9c224f1fd32461ea73bd6e572808c63d318257bfd4c9d355a9df78fac7e"
"23cded2b43261016f0f246c85c8948d4a9b7f2d44988f75dad69723a7a526094"
"bb8396b3fbaa160bf2173eadbc83cce50bcd5a0879dc24b4122efb7411370d12"
"e656327540d6b2d012c0d18669d6cbb2750e07d5289d44bc8cf28eb4bb937cc0"
"90c33cf3f2ed0bd773f648815de7347e69cfbb3416ef3bf41616ab1c4aa0f5a8"
"b1099cccc80a3f434728c9bc3b8a90395793b625f4680ca05267cf635143d64d"
"bdcf87938c18f3b0c4e1bbd01edbaa995100432eb23d87db238e95bdb1f9496e"
"6ead0515aecb24c6a8f5f3800a070b7d20a66c8f26cba5dad137824da590a532"
"6535c074e2e80d7461441492a6c07c19decb129dc495e3c63d72201856b8eb81"
"6dd0c9c8a740e6c19149e98034fba8e368fd9aa16ab417aa636854d40db1a161"
"330d19a2eaa07ed02757d7a785a77bab49f5ee710ea03b4ee2fa220ddd0feffc"
"e9b36d476dc9da8797bad6497e96f30c85ff6880e930a2ab31e34fbba87d0498"
"16a020218f25d24bcacee816668bea8852792b16aae86977bc8212659f894ba5"
"1530172ee98edd129954fcdca1bf725f7b30c8bfc3cdc381c88de96b7d19e690"
"6524d85d2ce334c955a4347015567326067ef15fe5f6a805714b25cace256f40"

Refs halcyon/asdf-java#71

API returns an occasional 404 error

I work on open source buildpacks for Google, which uses AdoptOpenJDK to install the JDK onto a builder container, which build's an application into an executable container image. The most common way we fetch the jdk is with curl --head -w %{http_code} -o /dev/null --silent --location --retry 3 https://api.adoptopenjdk.net/v3/assets/feature_releases/11/ga?architecture=x64&heap_size=normal&image_type=jdk&jvm_impl=hotspot&os=linux&page=0&page_size=1&project=jdk&sort_order=DESC&vendor=adoptopenjdk. This occasionally returns 404s. For context, most of the times we are seeing this 404 is when we run this command several times in a span of minutes, so perhaps it may be ddos protection? Please let me know if I can provide any more useful information.

Test suite currently takes ~40 mins to run

@johnoliver and I were discussing this yesterday and having started working with codebase it feels like it would be good to resolve the issue to improve the development feedback loop.

At present when each test class is executed there is an initial hit of between 1 and 2 minutes depending on the test. This acunulates to an overall time of ~40 mins to run the front-end test suite.

This is because the tests use the @QuarkusTest annotation which initialises the full app including the code that creates connections to Mongo. The default connect timeout for Mongo is 30000 milliseconds so every time a connection is attempted we get this hit.

We see these errors in the logs:

ERROR: Failed to read db
com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting for a server that matches ReadPreferenceServerSelector{readPreference=primary}. Client view of cluster state is {type=UNKNOWN, servers=[{address=localhost:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused}}]
	at com.mongodb.internal.connection.BaseCluster.createTimeoutException(BaseCluster.java:403)
	at com.mongodb.internal.connection.BaseCluster.handleServerSelectionRequest(BaseCluster.java:311)
	at com.mongodb.internal.connection.BaseCluster.access$800(BaseCluster.java:62)
	at com.mongodb.internal.connection.BaseCluster$WaitQueueHandler.run(BaseCluster.java:474)
	at java.base/java.lang.Thread.run(Thread.java:834)

As a simple test for a fix I've modified the fallback localhost connection string that's used by the tests here to this:

"mongodb://$host:$port?connectTimeoutMS=100"

The full test suite now runs in ~8 mins with the front-end tests reduced to ~5/6 mins:

[INFO] Reactor Summary for adoptopenjdk-api-v3 3.0.0-SNAPSHOT:
[INFO] 
[INFO] adoptopenjdk-api-v3 ................................ SUCCESS [  2.351 s]
[INFO] adoptopenjdk-api-v3-models ......................... SUCCESS [ 11.861 s]
[INFO] adoptopenjdk-api-v3-persistance .................... SUCCESS [  2.875 s]
[INFO] adoptopenjdk-api-v3-updater ........................ SUCCESS [02:41 min]
[INFO] adoptopenjdk-api-v3-frontend ....................... SUCCESS [05:29 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  08:28 min
[INFO] Finished at: 2020-07-16T08:30:57+01:00
[INFO] ------------------------------------------------------------------------

We could probably reduce this more but that's as far as I've gone for now, thought it was worth getting some feedback first.

I think as a quick win this could be a good change to improve the speed of the test run improving the feedback loop.

Please let me know if you're happy for me to create a PR for this?

As the tests are using an in memory database controlled by the tests, longer term it may be worth thinking about how we either change the Mongo connection code to occur later in the application life-cycle so the database is already available. Or alternatively, and maybe preferably, change how we use Mongo in the tests so it's available before the Mongo client is created. Maybe something like test containers could help here, or even using docker-compose to wrap the test execution and spin up Mongo as a dependency.

Additional note:

It's possible we'd want to apply a more aggressive timeout more generally than just the tests but that decision probably requires a bit more thought. In production waiting 30000ms for Mongo to notify that connection has failed might be too long, if we can fail faster then that might be a good thing. (I don't have much context yet on how this runs in prod).

Create BOT that contacts all GitHub projects using V2 API

Should be a case of crawling all repos that are returned in https://github.com/search?p=1&q=https%3A%2F%2Fapi.adoptopenjdk.net%2Fv2&type=Code

JFR and JRE builds included in response in upstream EA builds

Request URL: https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ea?jvm_impl=hotspot&heap_size=normal&os=windows&architecture=x64&image_type=jdk&project=jdk&vendor=openjdk&page_size=1&sort_order=DESC

Response:

[
    {
        "binaries": [
            {
                "architecture": "x64",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "hotspot",
                "os": "windows",
                "package": {
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jdk-jfr_x64_windows_8u262b01_ea.zip",
                    "name": "OpenJDK8U-jdk-jfr_x64_windows_8u262b01_ea.zip",
                    "signature_link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jdk-jfr_x64_windows_8u262b01_ea.zip.sign",
                    "size": 104665503
                },
                "project": "jdk",
                "updated_at": "2020-04-29T18:41:28Z"
            },
            {
                "architecture": "x64",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "hotspot",
                "os": "windows",
                "package": {
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jdk_x64_windows_8u262b01_ea.zip",
                    "name": "OpenJDK8U-jdk_x64_windows_8u262b01_ea.zip",
                    "signature_link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jdk_x64_windows_8u262b01_ea.zip.sign",
                    "size": 104183697
                },
                "project": "jdk",
                "updated_at": "2020-04-29T18:52:00Z"
            },
            {
                "architecture": "x64",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "hotspot",
                "os": "windows",
                "package": {
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jre-jfr_x64_windows_8u262b01_ea.zip",
                    "name": "OpenJDK8U-jre-jfr_x64_windows_8u262b01_ea.zip",
                    "signature_link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-jre-jfr_x64_windows_8u262b01_ea.zip.sign",
                    "size": 37787141
                },
                "project": "jdk",
                "updated_at": "2020-04-29T18:58:49Z"
            }
        ],
        "download_count": 0,
        "id": "MDc6UmVsZWFzZTI2MDE4MTEy",
        "release_link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b01",
        "release_name": "OpenJDK 8u262-b01 EA build",
        "release_type": "ea",
        "source": {
            "link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b01/OpenJDK8U-sources_8u262b01_ea.tar.gz",
            "name": "OpenJDK8U-sources_8u262b01_ea.tar.gz",
            "size": 88173533
        },
        "timestamp": "2020-04-29T19:15:42Z",
        "updated_at": "2020-04-29T19:15:42Z",
        "vendor": "openjdk",
        "version_data": {
            "build": 1,
            "major": 8,
            "minor": 0,
            "openjdk_version": "8u262-b01",
            "security": 262,
            "semver": "8.0.262+1"
        }
    }
]

Add GitHub issue templates

To help contributors to create good quality feature requests/bug reports we should add the GitHub templates to support this.

See: https://docs.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates#issue-templates

Multiple match for openjdk upstream 11u artefacts

curl -v https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk
*   Trying 104.17.158.60:443...
* TCP_NODELAY set
* Connected to api.adoptopenjdk.net (104.17.158.60) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; CN=adoptopenjdk.net
*  start date: Mar 19 00:00:00 2020 GMT
*  expire date: Oct  9 12:00:00 2020 GMT
*  subjectAltName: host "api.adoptopenjdk.net" matched cert's "*.adoptopenjdk.net"
*  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x563029f2fa00)
> GET /v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk HTTP/2
> Host: api.adoptopenjdk.net
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 400 
< date: Thu, 30 Apr 2020 12:19:59 GMT
< content-type: application/octet-stream
< content-length: 150
< set-cookie: __cfduid=d6415cde398016c04350fda1208d259391588249199; expires=Sat, 30-May-20 12:19:59 GMT; path=/; domain=.adoptopenjdk.net; HttpOnly; SameSite=Lax
< access-control-allow-origin: *
< set-cookie: b7b892882bae631693e1ea44963ef628=262a5780929c0750267ffcad1ee2cf91; path=/; HttpOnly; Secure
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 58c136d808688cc2-VIE
< alt-svc: h3-27=":443"; ma=86400, h3-25=":443"; ma=86400, h3-24=":443"; ma=86400, h3-23=":443"; ma=86400
< cf-request-id: 026ca09b0000008cc24f0b2200000001
< 
* Connection #0 to host api.adoptopenjdk.net left intact
{"errorMessage":"Multiple binaries match request: [OpenJDK11U-jdk_x64_linux_11.0.8_1_ea.tar.gz, OpenJDK11U-static-libs_x64_linux_11.0.8_1_ea.tar.gz]"}

With the 11.0.8+1 EA release we've added static-libs support in order to make it easier for folks to build Graal VM from source. This seems to confuse the API. Ideally, the static-libs artefact would be available for download via a static-libs image type like so:

$ curl https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/static-libs/hotspot/normal/openjdk

New OpenJ9 vs Hotspot endpoints

As part of the work for AdoptOpenJDK/openjdk-dashboard-v2#6, we will require new endpoints in the v3 api.

/stats/monthly endpoint which will return total download counts for each month (inc. current month) eg.

{ "Dec-2019": 1096,
  "Jan-2020": 562,
  "Feb-2020": 1372, ... }

In the front end displaying the last 6 months would suffice, so the endpoint could be limited if that would be easier.

/stats/monthly?{jvmImpl} or /stats/monthly/{jvmImpl} endpoint which would result the exact same format, just filtered to the given jvmImpl.
Adding a jvmImpl parameter to the /tracking endpoint, which would allow you to filter by jvmImpl. I understand there are some difficulties with the docker api, so if this was limited to just github searches, similar to how feature_version is handled, then that would be okay.

I think both me and @M-Davies are keen to help with API support, but would need help in getting started.
There may also be some limitations in the database that I'm not aware of. For example, it looks like data collected daily is deleted after 30 days/not reachable by the api, which may limit 3).

Latest JDK14 nightly builds are from May 8

Looking at https://adoptopenjdk.net/nightly.html?variant=openjdk14&jvmVariant=openj9 the latest nightly builds are from May 8. Same with hotspot.

Available releases should not list early access versions as most recent feature release

The available releases endpoint lists java 15 as most recent feature release:

INFORMATION: 1 * Sending client request on thread main
1 > GET https://api.adoptopenjdk.net/v3/info/available_releases

INFORMATION: 1 * Client response received on thread main
1 < 200
{
   ...
    "most_recent_feature_release": 15,
    "most_recent_lts": 11
}

When trying to access this feature release through the assets endpoint, no binaries are found:

INFORMATION: 2 * Sending client request on thread main
2 > GET https://api.adoptopenjdk.net/v3/assets/feature_releases/15/ga

INFORMATION: 2 * Client response received on thread main
2 < 404

As there are no general availability (ga), but only early access (ea) binaries for this feature release, the available releases endpoint should not list this version as most_recent_feature_release.

Fix pre version sort order

Currently in the version sort order something comes after absent for the pre field. According to point 11 in https://semver.org/ absent should come after something.

v3/binary/latest doesn't give the latest release build

The following v3 api link doesn't download the "latest" 11.0.7+10.1 build but the 11.0.7+10 build

https://api.adoptopenjdk.net/v3/binary/latest/11/ga/aix/ppc64/jdk/openj9/normal/adoptopenjdk

There may be a similar problem for Mac (+10.2) and Windows (+10.1) releases.

Enhance API to return the latest jdk version number

Ref adoptium/temurin-build#1574

https://api.adoptopenjdk.net/v3/info/available_releases does not return the JDK-Next number (currently 15). Enhancing the API to add a latest_jdk_version attribute and accompanying version number would be sufficient to reopen 1574.

Add Contributing.md

Add java -version output to the nightly build download page

See adoptium/temurin-build#367

We are now adding the java version output to the metadata from the builds. Assuming this will now automatically appear in the API (CC @johnoliver ?), please provide the java -version output of each build on the download so users can track it back to a git branch and commit.

Multiple binaries match request: openjdk 8 ea artefacts

$ curl -v https://api.adoptopenjdk.net/v3/binary/latest/8/ea/linux/x64/jdk/hotspot/normal/openjdk
*   Trying 104.17.158.60:443...
* TCP_NODELAY set
* Connected to api.adoptopenjdk.net (104.17.158.60) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=Cloudflare, Inc.; CN=adoptopenjdk.net
*  start date: Mar 19 00:00:00 2020 GMT
*  expire date: Oct  9 12:00:00 2020 GMT
*  subjectAltName: host "api.adoptopenjdk.net" matched cert's "*.adoptopenjdk.net"
*  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55fde2e77a00)
> GET /v3/binary/latest/8/ea/linux/x64/jdk/hotspot/normal/openjdk HTTP/2
> Host: api.adoptopenjdk.net
> User-Agent: curl/7.65.3
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 400 
< date: Thu, 30 Apr 2020 10:00:17 GMT
< content-type: application/octet-stream
< content-length: 192
< set-cookie: __cfduid=def3580af804e6c93e66e4dcfa653fa051588240817; expires=Sat, 30-May-20 10:00:17 GMT; path=/; domain=.adoptopenjdk.net; HttpOnly; SameSite=Lax
< access-control-allow-origin: *
< set-cookie: b7b892882bae631693e1ea44963ef628=262a5780929c0750267ffcad1ee2cf91; path=/; HttpOnly; Secure
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 58c06a346ed9cbc4-VIE
< alt-svc: h3-27=":443"; ma=86400, h3-25=":443"; ma=86400, h3-24=":443"; ma=86400, h3-23=":443"; ma=86400
< cf-request-id: 026c20b4bf0000cbc4af30f200000001
< 
* Connection #0 to host api.adoptopenjdk.net left intact
{"errorMessage":"Multiple binaries match request: [OpenJDK8U-jdk-jfr_x64_linux_8u262b01_ea.tar.gz, OpenJDK8U-jdk_x64_linux_8u262b01_ea.tar.gz, OpenJDK8U-jre-jfr_x64_linux_8u262b01_ea.tar.gz]"}

With the latest EA release of 8u262-b01, which now includes JFR enabled and JFR disabled (default) builds, the API gets confused. Can we ignore jdk-jfr and jre-jfr matching binaries?

Latest nightly builds not returned by API

The latest nightly builds are not returned by the v3 api:
Running:

https://api.adoptopenjdk.net/v3/binary/latest/8/ea/aix/ppc64/jdk/openj9/normal/adoptopenjdk

returns the build from the 6th Feb

OpenJDK8U-jdk_ppc64_aix_openj9_2020-02-06-13-39.tar.gz

even though there are later builds available - e.g. these builds are from 12th Feb: https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u-2020-02-12-20-33

The nightly builds download page also shows 6th Feb as being the latest available builds (presumably it uses the api): https://adoptopenjdk.net/nightly.html?variant=openjdk8&jvmVariant=openj9

v3 API should be able to retrieve testimage artifacts for a certain release

Binary Type already has jre and jdk as possible values. A third possible value of testimage comes to mind for retrieving the test image which can then be used for testing.

PR adding testimage artifacts:
adoptium/temurin-build#1251

Examples:
https://ci.adoptopenjdk.net/job/build-scripts-pr-tester/job/build-test/job/jobs/job/jdk11u/job/jdk11u-linux-x64-hotspot/133/
https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.5%2B5

Note: testimage artifacts are JDK 11+ only.

Unable to directly download an installer

Could it be possible to add an API end point like the binary end point that downloads an installer instead of the tar.gz file if an installer is available?

Add EOL-Reached field

Hello,

I think it would be extremely useful to have EOL field in /v3/assets/latest/{feature_version}/{jvm_impl} and /v3/info/available_releases.

It may look like "eol_reached": "true" or something like that.

This would be very useful in case of update automation (see adoptium/installer#4)

It would be also useful to have a recommendation like "recommended new branch": "11" in this case. Or maybe "most_recent_feature_release" and "most_recent_lts" from /v3/info/available_releases will suit this?

BTW, what happens when release version reaches EOL? Is it dropped from available_releases?

jdk8 hotspot nightly binaries not being returned by v3 api

https://api.adoptopenjdk.net/v3/binary/latest/8/ea/linux/x64/jdk/hotspot/normal/adoptopenjdk is not returning a jdk binary as expected.

Update README at this repo

The README doc at this repo likely needs updating, looks like it still references v2 api.

If possible, I would like a quick start on how to use the v3 api, so we can shift the test scripts over to using it.

api not downloading upto date nightly

Problem Description

Currently I am running daily java tests around 1:40 am by pulling latest builds.
from February 26th, I see 5 ppc64le_openj9 builds from adoptopenjdk (https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=openj9) for following dates - 6,10,23,25,26
however when I use the adoptapi to get latest build with following command,

curl -OLJSks  https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/ppc64le/jdk/openj9/normal/adoptopenjdk

I got following jdk, which is pretty outdated

openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+1-202002062012)
Eclipse OpenJ9 VM AdoptOpenJDK (build master-f09513cd4, JRE 11 Linux ppc64le-64-Bit Compressed References 20200206_445 (JIT enabled, AOT enabled)
OpenJ9   - f09513cd4
OMR      - 001677f30
JCL      - 058070839f based on jdk-11.0.7+1)

if it doesn't pull the 25th build right next day its understandable but 0210 and 0221 builds should be there at least not the 0206 build

Dockers stats is not recording feature_version for openj9 repos

A bug that was found by a teammate. The following route should return entries, but currently is not. It looks like the dockerStats collection is not recording feature_version correctly for openj9 repos.

Eg.

{
	"_id" : ObjectId("5ef1fd7ca5aec55e0b25e233"),
	"date" : ISODate("2020-06-23T13:02:50Z"),
	"pulls" : NumberLong(150212),
	"repo" : "openjdk13-openj9",
	"feature_version" : null,
	"jvm_impl" : "openj9",
	"metric" : NumberLong(150212),
	"id" : "openjdk13-openj9"
}

I would imagine it has something to do with the regex at

openjdk-api-v3/adoptopenjdk-api-v3-updater/src/main/kotlin/net/adoptopenjdk/api/v3/stats/DockerStatsInterface.kt

Line 55 in 1def369

 return "openjdk(?<featureNum>[0-9]+)".toRegex().matchEntire(name)?.groups?.get("featureNum")?.value?.toInt() 

Will investigate

jdk-11.0.7+10_openj9-0.20.0 not visiable in website or apiv3

Browser:

The website is not showing the published jdk-11.0.7+10_openj9-0.20.0
https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=openj9

Define standard linting rules to automate style-related PR reviews

This would automate reviews for most style issues and provide instant PR feedback to contributors, as well as automate some project configuration processes in capable IDE's.

Seeing as v3 is entering the active development phase, a consensus on standard style rules would prevent a lot of headaches, discussions, and manual intervention for the contributions that lie ahead.
Common "obvious" inconsistencies such as spacing, semicolon usage, tab width, and continuation width, can be detected in CI by defining them at the error level. Style issues that are debatable or context-dependent can be defined at the warning level to provide visibility for approvers and submitters without halting the pipeline.

Something like Code Climate (free for OSS) could be used for more granular control over Travis CI/GitHub integration, as well as lay the foundation for stuff like coverage reports and static analysis. As for Typescript linting, Microsoft appears to be phasing out TSLint in favor of ESLint, which is already used by the API and capable of handling some surprisingly complex cases.

I can submit a PR if this is a desirable feature, but wouldn't feel comfortable doing so without some sort of consensus. I'll respond below with a few of my own preferences.

Make debugimage archives available via the API

It would be useful to have downloads of the debug image archives via the API. Ideally the debugimage archives will be preserved for every build.

adoptium/temurin-build#1596 added debug image archives for OpenJ9 builds. Copying the contained debug-image folder over top of the jdk makes symbols available to greatly ease the task of debugging an issue with native code.

Enhance API to pick up Linux installers from artifactory (adoptopenjdk.jfrog.io)

We only have the RPM and .deb installers in Artifactory (adoptopenjdk.jfrog.io) which package managers can use. For completeness, we could also offer these installers through our API.

LTS flag is ignored for /v3/assets/version/{version} endpoint

The v3 swagger UI documents an optional lts query filter for the /v3/assets/version/{version} endpoint, but it does not appear to be implemented.

See example query here for versions 8+ with lts=true returning the latest non-lts 14 release. Looks like the query param is defined here but not used during filtering.

jdk8u181-b13_openj9-0.9.0 wrong metadata (large heap)

While playing around with the AdoptOpenJDK API v3, I saw that the artifact with the name OpenJDK8-OPENJ9_x64_LinuxLH_jdk8u181-b13_openj9-0.9.0.tar.gz wrong metadata and should have "heap_size": "large" but has "heap_size": "normal" instead.

# curl -X GET "https://api.adoptopenjdk.net/v3/assets/version/%5B8.0.180%2C8.0.182%5D?architecture=x64&image_type=jdk&jvm_impl=openj9&os=linux&page=0&page_size=20&project=jdk&release_type=ga&sort_order=DESC&vendor=adoptopenjdk" -H  "accept: application/json"

[
    {
        "binaries": [
            {
                "architecture": "x64",
                "download_count": 3015,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "openj9",
                "os": "linux",
                "package": {
                    "checksum": "c90fa5826c2d4898d70a24239cd958f0a4e1afb07ef578da2fb5969637bfa22f",
                    "checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/releases/download/jdk8u181-b13_openj9-0.9.0/OpenJDK8-OPENJ9_x64_Linux_jdk8u181-b13_openj9-0.9.0.sha256.txt",
                    "download_count": 3015,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/releases/download/jdk8u181-b13_openj9-0.9.0/OpenJDK8-OPENJ9_x64_Linux_jdk8u181-b13_openj9-0.9.0.tar.gz",
                    "name": "OpenJDK8-OPENJ9_x64_Linux_jdk8u181-b13_openj9-0.9.0.tar.gz",
                    "size": 88509704
                },
                "project": "jdk",
                "updated_at": "2018-08-14T12:13:29Z"
            },
            {
                "architecture": "x64",
                "download_count": 1382,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "openj9",
                "os": "linux",
                "package": {
                    "checksum": "aa478944bb9b93a03c4f8ffd97054e1b9b5a4f09cb35c310b58de816dc7ddcf2",
                    "checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/releases/download/jdk8u181-b13_openj9-0.9.0/OpenJDK8-OPENJ9_x64_LinuxLH_jdk8u181-b13_openj9-0.9.0.sha256.txt",
                    "download_count": 1382,
                    "link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/releases/download/jdk8u181-b13_openj9-0.9.0/OpenJDK8-OPENJ9_x64_LinuxLH_jdk8u181-b13_openj9-0.9.0.tar.gz",
                    "name": "OpenJDK8-OPENJ9_x64_LinuxLH_jdk8u181-b13_openj9-0.9.0.tar.gz",
                    "size": 88439461
                },
                "project": "jdk",
                "updated_at": "2018-08-14T12:13:35Z"
            }
        ],
        "download_count": 9134,
        "id": "MDc6UmVsZWFzZTEyMzk0ODMy",
        "release_link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/releases/tag/jdk8u181-b13_openj9-0.9.0",
        "release_name": "jdk8u181-b13_openj9-0.9.0",
        "release_type": "ga",
        "timestamp": "2018-08-14T12:12:45Z",
        "updated_at": "2018-08-14T12:12:45Z",
        "vendor": "adoptopenjdk",
        "version_data": {
            "build": 13,
            "major": 8,
            "minor": 0,
            "openjdk_version": "8u181-b13_openj9-0.9.0",
            "optional": "openj9-0.9.0",
            "security": 181,
            "semver": "8.0.181+13.openj9-0.9.0"
        }
    }
]

HEAD requests return forbidden

The binary endpoint is supposed to support HEAD requests but following the redirects, I always end up hitting a 403 Forbidden from AWS.

curl -L --head "https://api.adoptopenjdk.net/v3/binary/version/jdk-11.0.6%2B10/linux/x64/jdk/hotspot/normal/adoptopenjdk?project=jdk" -H "accept: */*"

Returns

HTTP/2 307 
date: Wed, 22 Jul 2020 15:01:16 GMT
set-cookie: __cfduid=ddf6fd43ad945d2bea6d9121b9beb48471595430076; expires=Fri, 21-Aug-20 15:01:16 GMT; path=/; domain=.adoptopenjdk.net; HttpOnly; SameSite=Lax
access-control-allow-origin: *
location: https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.6%2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.6_10.tar.gz
set-cookie: b7b892882bae631693e1ea44963ef628=b4b559031a2248016f9d4b104b089277; path=/; HttpOnly; Secure
cf-cache-status: DYNAMIC
cf-request-id: 0418a416780000cc3a6da45200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5b6e09372b9acc3a-ZRH
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

HTTP/1.1 302 Found
date: Wed, 22 Jul 2020 15:01:16 GMT
content-type: text/html; charset=utf-8
server: GitHub.com
status: 302 Found
vary: X-PJAX, Accept-Encoding, Accept, X-Requested-With, Accept-Encoding
location: https://github-production-release-asset-2e65be.s3.amazonaws.com/140419044/f9a2e800-37b6-11ea-81bd-408d941c9cf6?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200722%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200722T150116Z&X-Amz-Expires=300&X-Amz-Signature=4d019faa67769a8ce9262abdf5e2c8aeb5ae6ba83e26fbded23bd2ec390a8i02&X-Amz-SignedHeaders=host&actor_id=0&repo_id=140419044&response-content-disposition=attachment%3B%20filename%3DOpenJDK11U-jdk_x64_linux_hotspot_11.0.6_10.tar.gz&response-content-type=application%2Foctet-stream
cache-control: no-cache
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
expect-ct: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; connect-src 'self' uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events wss://alive.github.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; frame-src render.githubusercontent.com; img-src 'self' data: github.githubassets.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; manifest-src 'self'; media-src 'none'; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; worker-src github.com/socket-worker.js gist.github.com/socket-worker.js
Set-Cookie: _gh_sess=JcLuQNMYKiUmIqzWqupCugVrzXRqPpZwMyZNMR08M0TxPeaXBGbBgaJBRy8n2q%2BDHZnxOJP9Q5ZQa%2FvKm4tnpUSaoLyvD0fhX70BYGVCb4H4%2Bi1igXxZrTadqZUlsyiUb8S%2BprsNZFRvM7vfJw%2Fp3ILtbQJi7VAeO6QKTgpZHMzQXWEAF92v64MRjUEvdDe1ERprITPOrYce5N20P355b39K7Pm583e00GGh5tWPXMgEXoBL4sbVLp2jAx0CxgnAWsMdTJBBdlhF4fDYKj%2Fy4w%3D%3D--k8Ph0k5AspS8IJxI--G8pEhsupVWfdolW2Yry5wg%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: _octo=GH1.1.467823763.1595430076; Path=/; Domain=github.com; Expires=Thu, 22 Jul 2021 15:01:16 GMT; Secure; SameSite=Lax
Set-Cookie: logged_in=no; Path=/; Domain=github.com; Expires=Thu, 22 Jul 2021 15:01:16 GMT; HttpOnly; Secure; SameSite=Lax
Content-Length: 662
X-GitHub-Request-Id: EDDD:CB66:B4C1164:1089AC5B:5F1854BC

HTTP/1.1 403 Forbidden
x-amz-request-id: D0A1DCCFFE02A5F9
x-amz-id-2: FazxY833XZom2EUl9NxiB5mnM3XkLwKZ5A9WTJwXbotVsv4O82kQuRXcZeJNFsdvxYP2c/zFjY0=
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Wed, 22 Jul 2020 15:01:17 GMT
Server: AmazonS3

The same URL but as GET request works:
curl -L https://api.adoptopenjdk.net/v3/binary/version/jdk-11.0.6%2B10/linux/x64/jdk/hotspot/normal/adoptopenjdk\?project\=jdk --output jdk.tar.gz