Upstream OpenJDK 11 EA link not working

[zakkak]

Describe the bug
https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk does not link to latest OpenJDK 11 upstream EA binary.

To Reproduce
Run:

curl https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk -o openjdk.tar.gz

Expected behavior
openjdk.tar.gz should be created and contain the latest EA release of upstream OpenJDK 11.

Device (please complete the following information):

• OS: Fedora 33
• Browser: N/A
• Version: N/A

Additional context

curl https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk

returns:

{"errorMessage":"Multiple binaries match request: [OpenJDK11U-jdk_x64_linux_11.0.10_3_ea.tar.gz, OpenJDK11U-jre-shenandoah_x64_linux_11.0.10_3_ea.tar.gz, OpenJDK11U-jdk-shenandoah_x64_linux_11.0.10_3_ea.tar.gz, OpenJDK11U-testimage-shenandoah_x64_linux_11.0.10_3_ea.tar.gz]"}

Shenandoah builds were recently added to https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.10%2B3 and it looks like some filtering needs to be done to prevent this error and introduce a new hostspot-shenandoah variant or similar.

[jerboaa]

@johnoliver Do we need a similar fix to JFR for this? 37567ef

Thoughts?

[jerboaa]

#187 seems related.

[johnoliver]

I think this is a bug in classifying upstream binaries, if you look at:

{
                "architecture": "aarch64",
                "download_count": 0,
                "heap_size": "normal",
                "image_type": "jdk",
                "jvm_impl": "hotspot",
                "os": "linux",
                "package": {
                    "download_count": 0,
                    "link": "https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.10%2B1/OpenJDK11U-testimage-shenandoah_aar
ch64_linux_11.0.10_1_ea.tar.gz",
                    "name": "OpenJDK11U-testimage-shenandoah_aarch64_linux_11.0.10_1_ea.tar.gz",
                    "signature_link": "https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.10%2B1/OpenJDK11U-testimage-shen
andoah_aarch64_linux_11.0.10_1_ea.tar.gz.sign",
                    "size": 320532747
                },
                "project": "jdk",
                "updated_at": "2020-11-20T10:11:55Z"  
            }

image_type should probably be testimage for that binary. It seems like image_type is not working correctly for upstream

[johnoliver]

additional proposal, to add shenandoah as a project, changing projects to:

["jdk", "valhalla", "metropolis", "jfr", "shenandoah"]

@jerboaa @karianna @zakkak, thoughts?

[jerboaa]

I think this is a bug in classifying upstream binaries [...]
image_type should probably be testimage for that binary. It seems like image_type is not working correctly for upstream

Yes, agreed. It should be testimage for this artefact.

[jerboaa]

additional proposal, to add shenandoah as a project, changing projects to:

["jdk", "valhalla", "metropolis", "jfr", "shenandoah"]

@jerboaa @karianna @zakkak, thoughts?

Have you considered that a Shenandoah JDK would be both: Project jdk and shenandoah. Or what does project jdk mean precisely?

Anyway, if it helps the matter, sure, make it a project.

[johnoliver]

Project is there to effectively distinguish between the JvmImpl that would typically represent the overall flavour of the VM i.e hotspot/openj9 and something that may exist as a temporary (or not so temporary) fork from the mainline of that VM. jdk wrt Projects currently effectively means the default that you would expect to be released and not a fork.

[jerboaa]

Project is there to effectively distinguish between the JvmImpl that would typically represent the overall flavour of the VM i.e hotspot/openj9 and something that may exist as a temporary (or not so temporary) fork from the mainline of that VM. jdk wrt Projects currently effectively means the default that you would expect to be released and not a fork.

Right. Shenandoah is in the mainline JDK project. Also in mainline jdk-updates/jdk11u :) So it wouldn't be a fork as such. Perhaps a better model going forward (API v4?) would be to have a Feature or Build Feature type for each project. i.e. something roughly corresponding to --with-jvm-features config switch. There could be a default, shenandoah, jfr build from a single jdk project. That goes beyond this immediate issue, though.

[jerboaa]

@zakkak This seems to be working as expected again:

$ curl -v https://api.adoptopenjdk.net/v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk 
*   Trying 104.17.158.60:443...
* 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: Jul  2 00:00:00 2020 GMT
*  expire date: Jul  2 12:00:00 2021 GMT
*  subjectAltName: host "api.adoptopenjdk.net" matched cert's "*.adoptopenjdk.net"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  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 0x56064684cb10)
> GET /v3/binary/latest/11/ea/linux/x64/jdk/hotspot/normal/openjdk HTTP/2
> Host: api.adoptopenjdk.net
> user-agent: curl/7.69.1
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 307 
< date: Thu, 26 Nov 2020 11:01:20 GMT
< content-length: 0
< set-cookie: __cfduid=d4ee4b34c776ee05b2ba3c036e7c834ce1606388480; expires=Sat, 26-Dec-20 11:01:20 GMT; path=/; domain=.adoptopenjdk.net; HttpOnly; SameSite=Lax
< access-control-allow-origin: *
< location: https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/download/jdk-11.0.10%2B3/OpenJDK11U-jdk_x64_linux_11.0.10_3_ea.tar.gz
< set-cookie: b7b892882bae631693e1ea44963ef628=4d439066f3784c90698ddf72d48c7d22; path=/; HttpOnly; Secure
< cf-cache-status: DYNAMIC
< cf-request-id: 06a5d010fe000038b335b04000000001
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 5f831c619c7c38b3-VIE
< 
* Connection #0 to host api.adoptopenjdk.net left intact