Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
emil_aleksandrov
Explorer
Cloud Foundry has released a new Java Buildpack 4.3 that has incompatible features and components compared with Java Buildpack 3.x. In this blog, we will describe the known incompatibilities that could impact SAP Cloud Platform CF users and show how one can test the new version before it is made a default one for the platform.

Known incompatibilities

Revised Memory Calculation

One of the major advantages of using the Java Buildpack is its memory calculation facilities. In a nutshell, it takes care of distributing the available container memory to the various memory regions of a JVM. To avoid that a JVM consumes more memory than the assigned container quota allows, a sophisticated calculation is key. To simplify the configuration as well as making the containerized JVM even more stable, the memory calculation was completely rewritten for the Java Buildpack 4.

The new memory calculator now accounts for the following memory regions:
Metaspace (-XX:MaxMetaspaceSize) [heuristic depending on amount of classes in the app]
Thread Stacks (-Xss) [1M per Thread; default: 300M]
Direct Memory (-XX:MaxDirectMemorySize) [constant 10M]
Code Cache (-XX:ReservedCodeCacheSize) [constant 240M]
Compressed Class Space (-XX:CompressedClassSpaceSize) [heuristic depending on amount of classes in the app]
Heap (-Xmx) [memory that is left after calculating all other memory areas]

 

Result of accounting for all of these memory regions is that applications that used to run with less than 1G (in particular with less than 768M) might fail with: “Cannot calculate JVM memory configuration: There is insufficient memory remaining for heap.”. Additionally, the buildpack now supports manual changes to the memory calculation by simply adding the standard JVM flags to a JAVA_OPTS environment variable.

In short if you want to stay out of issues and you don’t do some fine-tuning memory configuration, run your application with memory allocation of 768M at least. The default memory allocation in CF is 1GB. So even if you haven’t specified “memory” parameter your application will run just fine.

Tomcat update:

Tomcat is updated from v8.0.x to 8.5.16. Changes between 8.0.x and 8.5.x may cause backwards compatibility problems when upgrading. More details and migration guide can be found here -https://tomcat.apache.org/migration-85.html.

 

How can I test it?

Via specifying “buildpack” attribute into the application manifest.yml file or by providing “-b” command line option.

E.g.

In manifest.yml file
applications:
- name: hello-war
host: hello-war
memory: 1024M
instances: 1
path: sample.war
buildpack: https://github.com/cloudfoundry/java-buildpack.git#v4.3

via command line
$ cf push -b https://github.com/cloudfoundry/java-buildpack.git#v4.3 hello-war

 

For the full list of Java Buildpack v4.3 components please check the release notes - https://github.com/cloudfoundry/java-buildpack/releases/tag/v4.3