adoptopenjdk / openjdk-api-v3 Goto Github PK
View Code? Open in Web Editor NEWAdoptOpenJDK API V3 π
Home Page: https://api.adoptopenjdk.net/swagger-ui
License: Apache License 2.0
AdoptOpenJDK API V3 π
Home Page: https://api.adoptopenjdk.net/swagger-ui
License: Apache License 2.0
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
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?
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).
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
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.
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
?
Proposed Changes:
Store the following data every day:
official
, openjdk11-openj9
, openjdk8-hotspot
etc)official
, openjdk11-openj9
, openjdk8-hotspot
etc)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,
},
...
}
]
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.
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.
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
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
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
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.
https://api.adoptopenjdk.net/v3/binary/latest/8/ea/linux/x64/jdk/hotspot/normal/adoptopenjdk is not returning a jdk binary as expected.
ππ₯πΆ 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.
Looking at https://adoptopenjdk.net/nightly.html?variant=openjdk14&jvmVariant=openj9 the latest nightly builds are from May 8. Same with hotspot.
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)
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)
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.
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.
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
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
.
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.
@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).
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
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.
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.
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?
The current schema assumes that a given release contains releases of the same version. In fact we have a mix of versions inside nightlies.
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.
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.
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.
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.
See also AdoptOpenJDK/openjdk-website#696
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.
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"
}
}
]
Examples will make it easier for people to easily migrate to the V3 API
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
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?
$ 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?
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
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.
To help contributors to create good quality feature requests/bug reports we should add the GitHub templates to support this.
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.
We should pretty-print the JSON responses from the API
Maybe we could have a flag that removes the pretty print if needed
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
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.
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.
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"
}
}
]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.