View on GitHub

SapMachine

Fast. Reliable. Open.

Features of SapMachine

SapMachine is kept as close as possible to the OpenJDK to make it usable as a drop-in replacement for any OpenJDK build by any vendor. Therefore, features and fixes identified to be required for SAP applications will usually be developed in and contributed to the OpenJDK.

It might happen that something which we deem important for our enterprise customers can not make its way into the OpenJDK. In that case we will accept differences between SapMachine and OpenJDK. But we try to be very cautious and selective with that.

To ensure transparency, this page outlines all SapMachine features that differ from upstream OpenJDK.

Version numbers

You can easily identify SapMachine from the output of the java -version command (see below). Although the version information of SapMachine and OpenJDK/OracleJDK are slightly different, the SapMachine version output still fully conforms to the format specified in the JEP 322: Time-Based Release Versioning and JEP 223: New Version-String Scheme.

SapMachine version information

$ ./sapmachine-25/bin/java -version
openjdk version "25.0.1" 2025-10-21 LTS
OpenJDK Runtime Environment SapMachine (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 25.0.1+8-LTS, mixed mode, sharing)

In addition to the original OpenJDK version output (see below), SapMachine adds an optional part (i.e. LTS) to the version number. This optional part (defined as optional build information in JEP 322) starts with LTS for long term support releases. If we will do an additional SapMachine specific release for this version, the fifth element of the version number will be increased and looks as follows 17.0.3.0.1+0-LTS. Once we pull and merge the next upstream release, this number will be reset to zero (e.g. 17.0.4+0-LTS). We are currently not using the build number part of the version string and always set it to 0.

The version date, as defined in JEP 322, will be set to the date, the SapMachine is generally available (GA). This date is never before the OpenJDK GA but may be set to a date after the OpenJDK GA.

OpenJDK version information

$ ./jdk-25-openjdk/bin/java -version
openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8)
OpenJDK 64-Bit Server VM (build 25.0.1+8, mixed mode, sharing)

System properties

The following listing shows the differences in the Java system properties between SapMachine and OpenJDK. Besides the version differences already discussed above that’s mostly the different values for the various vendor properties:

-    java.runtime.version = 25.0.1+8
+    java.runtime.version = 25.0.1+8-LTS
-    java.vendor = Oracle Corporation
-    java.vendor.url = https://java.oracle.com/
-    java.vendor.url.bug = https://bugreport.java.com/bugreport/
+    java.vendor = SAP SE
+    java.vendor.url = https://sapmachine.io/
+    java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new
+    java.vendor.version = SapMachine
-    java.vm.vendor = Oracle Corporation
-    java.vm.version = 25.0.1+8
+    java.vm.vendor = SAP SE
+    java.vm.version = 25.0.1+8-LTS

Behavioral differences

  • SapMachine enables extended thread dumps -XX:+PrintExtendedThreadInfo. See also JDK-8200720.

  • SapMachine enables output of additional information in exception messages by setting jdk.includeInExceptions in the java security configuration file. SapMachine 11 sets this property to ‘hostinfo’, SapMachine 12 and later set ‘hostinfo,jar’. See also JDK-8204622 and JDK-8207768.

  • SapMachine enables output of code snippets in exception messages.

  • SapMachine enables -XX:+ExtensiveErrorReports.

  • SapMachine trusts the SAP specific root certificate “SAP Global Root CA”, used by the SAP Global PKI infrastructure.

  • SapMachine has a supportability feature called Vitals.

  • SapMachine prints all flags in hs_err files, not just the default ones. Comments are omitted, though.

  • SapMachine has two additional JFR configurations, especially for GC profiling (gc.jfc and gc_details.jfc).

  • SapMachine handles some *OnOutOfMemoryErrorswitches differently than stock OpenJDK to be more useful in cloud scenarios. Behaviorial changes highlighted with italics:

    • ExitOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property *Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • prints “Terminating due to java.lang.OutOfMemoryError” to stdout
      • Exits the VM
    • CrashOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property *Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • Writes an error report (hs_err_pid..)
      • prints “Aborting due to java.lang.OutOfMemoryError” to stdout
      • exits the VM
      • will NOT write a core file unless +CreateCoredumpOnCrash was explicitly specified on the command line
    • HeapDumpOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property *Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • generates heap dump
    • OnOutOfMemoryError=command
      • also works for thread exhaustion OOMs (but note that whatever resource exhaustion caused thread creation errors may cause the subsequent fork for command to fail as well)
      • prints stack to stdout
      • invokes the given command

    Notes:

    • Avoiding core file creation with CrashOnOutOfMemoryError is intentional. CrashOnOutOfMemoryError is by default tuned to shut the VM down with a minimum of fuzz while still giving us a useful error report. If a core file is wanted for post analysis, specify -XX:+CreateCoreDumpOnCrash.
    • For thread creation errors, xxxOnOutOfMemoryError switches are handled before the JVMTI ResourceExhausted event is posted. This means that JVMTI agents monitoring this event (e.g. CloundFoundry’s jvmkill) may not get invoked. This is intentional.
    • The SapMachine-specific flag ExitVMOnOutOfMemoryError (note the “VM” in the name, not to be confused with ExitOnOutOfMemoryError) is an alias to CrashOnOutOfMemoryError and provided for backward compatibility reasons.

Additionally Included Software

We started including async-profiler in our distribution.