Pushing a Java App with JDK Version 17(and JDK Version 15) Causes Staging Failure using versions of Java Buildpack offline before v4.51
search cancel

Pushing a Java App with JDK Version 17(and JDK Version 15) Causes Staging Failure using versions of Java Buildpack offline before v4.51

book

Article ID: 298427

calendar_today

Updated On:

Products

VMware Tanzu Application Service for VMs

Issue/Introduction

You may encounter a staging failure when pushing a Java App using the below variable for JDK 17(and JDK 15) and Java Buildpack Offline versions before v4.51.

JBP_CONFIG_OPEN_JDK_JRE: '{ jre: { version: 17.+}}'
JBP_CONFIG_OPEN_JDK_JRE: '{ jre: { version: 15.+}}'


The error message looks like the following:
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:18.908476284Z OUT Downloaded app package (89.8M)
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.82521994Z OUT ----->Java Buildpack v4.49(offline)| [email protected]:cloudfoundry/java-buildpack.git#5d5900c0
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.890377478Z OUT ----->Downloading Jvmkill Agent1.16.0_RELEASE from https://java-buildpack.cloudfoundry.org/jvmkill/bionic/x86_64/jvmkill-1.16.0_RELEASE.so (found in cache)
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.894854888Z ERR [Buildpack]                      ERROR Finalize failed with exception #<RuntimeError: Unable to find cached file for https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre17.0.5%2B8-linux-amd64.tar.gz>
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.894891788Z ERR Unable to find cached file for https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre17.0.5%2B8-linux-amd64.tar.gz
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.899521497Z ERR Failed to compile droplet: Failed to run finalize script: exit status 1
9e100f21-c22c-43dc-853b-4e9772472d4f STG/0 2023-01-31T10:48:21.91029762Z OUT Downloading Open Jdk JRE17.0.5_8 from https://java-buildpack.cloudfoundry.org/openjdk/bionic/x86_64/bellsoft-jre17.0.5%2B8-linux-amd64.tar.gz Exit status 223

Cause:
Versions of the Java Buildpack (JBP) before 4.51 only pin the default version of 8, which causes the buildpack to attempt to fetch the latest version of JDK 17 (and JDK15).
 

Additional Information:
This issue is related to the packaging caveats mentioned in the Java Buildpack's GitHub repository: https://github.com/cloudfoundry/java-buildpack#packaging-caveats

1. Prior to version 4.51, when pinning versions, only the default JRE version is pinned. There is special handling to package additional versions of a JRE, and this method will pick the latest version at the time of packaging, not at the time of the version's release. Starting with version 4.51, the version number for all JRE version lines is tracked in the config/ file.
2. The index.yml file for a dependency is packaged in the buildpack cache when building offline buildpacks. The index.yml file isn't versioned with the release, so if you package an offline buildpack later after the release was tagged, it will pull the current index.yml, not the one from the time of the release. This can result in errors at build time if a user tells the buildpack to install the latest version of a dependency because the latest version is calculated from the index.yml file, which has more recent versions than what are packaged in the offline buildpack.

 


Environment

Product Version: 2.13

Resolution

1. Please specify the exact version that should be included in the buildpack using the JBP_CONFIG_OPEN_JDK_JRE variable.
To determine which JDK 17(and JDK 15) JRE versions are available, you can visit the Java Buildpack's GitHub repository: https://github.com/cloudfoundry/java-buildpack/releases and then choose the desired JRE version from the available releases and set the JBP_CONFIG_OPEN_JDK_JRE environment variable accordingly.
For example for Java Buildpack v4.49:
JBP_CONFIG_OPEN_JDK_JRE: '{ jre: { version: 17.0.3_7 }}'

2. Upgrade the Java Buildpack to version 4.51 or later. These version track the version number for all JRE version lines in the config/ file, which resolves this issue.