Page last updated:
Warning: VMware Tanzu Application Service for VMs (TAS for VMs) v2.9 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
You can use use the Java buildpack with apps written in Grails, Play, Spring, or any other JVM-based language or framework.
See the following topics for more information:
- Tips for Java Developers
- Getting Started Deploying Apps
- Configuring Service Connections
- Cloud Foundry Java Client Library
- Using Java Native Image
The Java buildpack only runs during the staging process, and therefore only logs staging information such as the downloaded components, configuration data, and work performed on your application by the buildpack.
The Java buildpack source documentation states the following:
The Java buildpack logs all messages, regardless of severity, to
APP-DIRECTORY/.java-buildpack.log. The buildpack also logs messages to
$stderr, filtered by a configured severity level.
If the buildpack fails with an exception, the exception message is logged with a log level of
ERROR. The exception stack trace is logged with a log level of
DEBUG. This prevents users from seeing stack traces by default.
Once staging completes, the buildpack stops logging. The Loggregator handles application logging.
Your application must write to STDOUT or STDERR for its logs to be included in the Loggregator stream. For more information, see App Logging in TAS for VMs.
Versions 3.7 and later of the Java buildpack support BOSH-configured custom trusted certificates. For more information, see Configuring Trusted Certificates in the BOSH documentation.
The Java buildpack pulls the contents of
$CF_INSTANCE_CERT/$CF_INSTANCE_KEY by default.
The log output for Diego Instance Identity-based
KeyStore appears as follows:
Adding System Key Manager Adding Key Manager for /etc/cf-instance-credentials/instance.key and /etc/cf-instance-credentials/instance.crt Start watching /etc/cf-instance-credentials/instance.crt Start watching /etc/cf-instance-credentials/instance.key Initialized KeyManager for /etc/cf-instance-credentials/instance.key and /etc/cf-instance-credentials/instance.crt
The log output for Diego Trusted Certificate-based
TrustStore appears as follows:
Adding System Trust Manager Adding TrustManager for /etc/ssl/certs/ca-certificates.crt Start watching /etc/ssl/certs/ca-certificates.crt Initialized TrustManager for /etc/ssl/certs/ca-certificates.crt
The memory calculator in Java buildpack 4.0 accounts for the following memory regions:
-Xss: Thread Stacks
-XX:MaxDirectMemorySize: Direct Memory
-XX:ReservedCodeCacheSize: Code Cache
-XX:CompressedClassSpaceSize: Compressed Class Space
Applications which previously ran in 512 MB or smaller containers may no longer be able to. Most applications will run if they use the Cloud Foundry default container size of 1 G without any modifications. However, you can configure those memory regions directly as needed.
The Java buildpack optimizes for all non-heap memory regions first and leaves the remainder for the heap.
The Java buildpack prints a histogram of the heap to the logs when the JVM encounters a terminal failure.
The Cloud Foundry default Java buildpack is currently 3.x to allows time for apps to be upgrade to 4.x.
For more information, see Java buildpack 4.0.