SapMachine is an OpenJDK down-stream distribution maintained and supported by SAP. It is developed fully in the open on GitHub with binaries available for downloaded from SapMachine. Read on if you’re interested in the history of SapMachine, the philosophy behind the project and the difference to OpenJDK and other down-stream distributions.
SapMachine’s history and heritage
SAP has a long and proven track record when it comes to the development and support of Java Virtual Machines. We started almost 15 years ago (long before the OpenJDK project was created) with the releases of SAP JVM 4 and 5, which were commercial implementations of the Java SE 4 and 5 standards based on source code licensed from SUN Microsystems.
In the beginning, one of the biggest challenges we faced was the need to port the HotSpot Virtual Machine together with the JDK Class Library to all SAP platforms, because the licensed sources only supported Windows/Linux/MacOS/x86/x64 and Solaris/x64/SPARC. So the SAP JVM team added support for HP-UX/PARISC/Itanium, AIX/PowerPC64, OS_400/PowerPC64, Windows/Itanium and Linux/Itanium/PowerPC64/s390 thus creating the Java VM with the widest platform coverage in the industry.
Besides its broad platform support, the SAP JVM is supplemented by additional supportability and developer features (like the SAP JVM Profiler or “Debugging on Demand”) and extensive monitoring and tracing facilities. They were all designed as interactive, on-demand features with minimal performance impact. Unfortunately, the field-of-use and bundling exceptions which were part of our commercial license agreement, prevented us from offering SAP JVM as a general purpose, stand-alone JDK, but SAP internally it quickly became the default Java runtime for all SAP products running on the Java SE platform.
SEE ALSO: Knights of the Round (OpenJDK) Table: It’s time to put a spotlight on SapMachine
SAP joining the OpenJDK
In 2007, right after SUN Microsystems open-sourced its Java implementation within the OpenJDK, the SAP JVM team started looking into the project but it still took us until 2011 to officially join the OpenJDK project by finally signing the Oracle Contribution Agreement. With the extensive experience gained while working on SAP JVM, we quickly got accepted and appreciated by the OpenJDK community. This encouraged us to contribute bigger features like the complete AIX, Linux/PowerPC64 and Linux/s390 ports which we are still maintaining as responsible project leads.
Today SAP has become one of the biggest external OpenJDK contributors. We’re especially proud that a recent survey conducted by the Java Platform Group at Oracle identified SAP as the second biggest contributor with regard to the number of fixed issues for the latest Java 11 Long Term Support release.
Besides its engagement in the OpenJDK project, SAP is also a long-term member of the Java Community Process (JCP) where it serves in the Executive Committee and in the Java SE umbrella JSR 379, 383, 384, 386 and 388 Expert Groups for Java 9 to 13.
The OpenJDK project
Since Java 7, the OpenJDK project creates the open-source, GPLv2+CPE licensed, reference implementation for the Java SE platform. It has to be noted however, that up to Java 9, OpenJDK was a “source-only” project. This means that the projects itself didn’t provide any pre-built, binary JDK downloads.
Instead, OpenJDK was the foundation of Oracle JDK which has been the predominant JDK for a long time. Oracle as the owner of the OpenJDK sources, could offer its JDK under a different, the Oracle Binary Code License (OBCL). While not an open source license, the OBCL still allowed using the Oracle JDK in productive and commercial environments. As a differentiator compared to a plain OpenJDK, the Oracle JDK contained various, non-Java SE add-ons like for example JavaFX or WebStart and additional, commercial features like Flight Recorder and Mission Control.
SEE ALSO: “With so many large organizations sponsoring AdoptOpenJDK, it makes them a leading option for LTS builds right now”
Since Java 11, Oracle now offers both, pure GPLv2+CPE licensed, OpenJDK builds (but only for a six month time frame), and Oracle JDK builds under the new Oracle Technology Network License Agreement. While there’s no functional difference between these two versions any more (the former Oracle JDK supplements have either been open-sourced or removed) the latter aren’t allowed for productive, commercial use any more. Oracle JDK 8 updates after January 2019 won’t be available for productive use either.
Linux distributors like Red Hat, Canonical or SuSE always provided (and still provide) pure, GPLv2+CPE licensed, OpenJDK binaries for their respective distributions. AdoptOpenJDK, a community of Java user group members, developers and vendors initially organized by the London Java Community, created an open build and test harness to fill the gap and provide OpenJDK binaries on a wider variety of platforms. Finally, after Oracle’s license changes, other companies like Azul (with Zulu), Amazon (with Corretto), BellSoft (with Liberica) and SAP (with SapMachine) jumped on the train and started their own OpenJDK releases supporting different platforms and Java versions.
The rise of SapMachine
The advent of new Cloud and IoT scenarios made it increasingly hard for SAP customers and clients to consume our commercially licensed SAP JVM with its field-of-use and bundling restrictions. At the same time, Oracle decided to radically change the traditional Java release and support strategy from ~3 years release cycles with ~5 years maintenance to a much more frequent, time-based release cadence with 6 month release cycles and only 6 month of public maintenance for each release.
In order to keep pace and better meet our customer’s requirements SAP decided to come up with SapMachine, our own downstream version of the OpenJDK. As we’ve put it on sapmachine.io, the purpose of the SapMachine project is to build and maintain a SAP supported version of OpenJDK for SAP customers and partners who wish to use OpenJDK to run their applications. It is clearly a “friendly fork” in the sense that we don’t want to compete feature-wise with OpenJDK and remain fully committed to OpenJDK’s future success.
The idea behind SapMachine is that we need a simple way to quickly react on customer request and be able to deliver fixes and features independently of other vendors and down-stream distributors. But at the same time, our whole team of experienced OpenJDK Committers and Reviewers also remains active in the OpenJDK project and tries to contribute as much of our changes as possible upstream.
SEE ALSO: Amazon announces Corretto, a *free*, production-ready distribution of OpenJDK with LTS
The SapMachine development model
The SapMachine project was started within the Java 10 time-frame and SapMachine 10 was our first public release. Like in the upstream OpenJDK project, this was a short-term support (STS) release only, and was discontinued after two security updates. The current, long term support (LTS) release is SapMachine 11 which will be supported for at least four years. We are about to finalize the upcoming SapMachine 12 STS release which is planned for March 2019 and are actively contributing to OpenJDK / SapMachine 13, the current development version.
In contrast to OpenJDK which still uses Mercurial as version control system (this may be changed by project Skara), SapMachine is being developed on GitHub. We convert, mirror and regularly sync the original OpenJDK sources into our GitHub repository. In addition to these up-stream mirrors, we use separate “sapmachine” branches to merge our SapMachine specific changes with up-stream. These sapmachine branches are finally used to build our SapMachine releases.
We’ve also set up a Continous Integration system based on Jenkins to automatically build and test all incoming changes before they can be merged into our sapmachine branch. In addition we run a huge amount of complementary builds and tests on our closed SAP infrastructure for both, the original OpenJDK sources as well as for our specific SapMachine branches. Building and extensively testing the original OpenJDK is crucial for us in order to be able to detect and fix problems early in the development process. This allows us to keep SapMachine specific fixes to a minimum.
As a signatory of the OpenJDK Community TCK License Agreement (OCTLA), SAP also has the right to use the Java Compatibility Kit (JCK) to ensure that SapMachine fully conforms to the corresponding Java SE specification. The “Certification and Java Compatibility” section in our Wiki provides more information about certified versions and platforms.
Finally, the SapMachine Wiki contains a whole section dedicated to the description of the SapMachine Development Process, which may be consulted for more details.
SEE ALSO: Recent changes and what’s next for Java: “OpenJDK is the future of Java”
SapMachine differences and features
Every SapMachine release contains all the changes and fixes of the corresponding up-stream, OpenJDK release. While SAP is committed to contribute all its features up-stream, this may not always be possible due to the various players, interests and concerns in the OpenJDK. If a feature which we consider useful won’t be accepted in the OpenJDK, a contribution may still be possible if the feature is disabled by default. In such cases we may choose to enable such features by default in SapMachine. For example, SapMachine sets the jdk.includeInExceptions property in the java security configuration file. This property is unset in upstream OpenJDK but enables some additional information in exception messages, which have been contributed by SAP (e.g. JDK-8205525). -XX:+PrintExtendedThreadInfo and -XX:+ExtensiveErrorReports are other examples of options which are switched on by default in SapMachine.
SapMachine also contains additional root certificates like the “SAP Global Root CA” used by the SAP Global PKI infrastructure and we may add more relevant certificates in the future.
Finally, there are numerous enhancements and fixes which we’ve contributed (and continuously contribute) to the latest OpenJDK development branch. For each such change we consider a downport to older, but still supported SapMachine versions if it is deemed relevant for our customers. Our “Features Contributed by SAP” Wiki page contains a complete list of such changes and the corresponding SapMachine-specific downports.
SapMachine security, maintenance and support
Maintenance describes the planned and scheduled work which is necessary to keep a product running and secure. Support, on the other hand, is an ad-hoc, on-request effort to fix a specific problem in a product. In the past, most people simply used Oracle JDK, which was maintained for free for quite some time. Additional support and extended maintenance was available to paying customers. Since January 2019, these times are gone. Both Oracle JDK 8 and 11 won’t be maintained any more for free commercial use. Instead users have to choose updates from one of the numerous new OpenJDK distributors.
SAP will maintain SapMachine 11 for at least four years (and maybe longer, depending on our customer’s requirements). In any case, SapMachine updates will always be free for the full maintenance period. SAP also offers full professional support to all SAP customers who use SapMachine in the context of SAP supported products.
Besides that, we try our best to solve any community-submitted, SapMachine specific bugs as quickly as possible. At the same time we remain fully engaged as Co-Maintainers of the OpenJDK Updates project which will remain the base for SapMachine LTS releases.
Security wise, SapMachine is always on par with the latest OpenJDK update release. As member of the OpenJDK Vulnerability Group SAP has full access to all upcoming security fixes. This enables us to extensively test security fixes before they get pushed into the open OpenJDK repositories and release SapMachine security updates in a synchronized and timely manner.
SEE ALSO: Oracle JDK builds vs. OpenJDK builds: Understanding the differences
Using SapMachine
We currently build SapMachine for Linux/x64/ppc64/ppc64le, Windows/x64 and Mac OS X (see our Wiki for more details on the supported platforms). Depending on the platform, SapMachine releases can be consumed in various formats.
Installation instructions for our packed archives can be found in our Installation Wiki. It also contains information about how you can set up an .deb package repository if you’re on Ubuntu or Debian:
sudo bash wget -q -O - https://dist.sapmachine.io/debian/sapmachine.key | apt-key add - echo "deb http://dist.sapmachine.io/debian/amd64/ ./" >> /etc/apt/sources.list apt-get update apt-get install sapmachine-11-jre
For Linux we also offer Docker Images:
docker pull sapmachine/jdk11:latest docker run -it sapmachine/jdk11:latest java -version
or installation by SDKman:
sdk install java 11.02.sapmchn
Finally, starting from version v4.9 of the Cloud Foundry Java Buildpack has builtin support for SapMachine. Using it can be as easy as:
cf set-envJBP_CONFIG_COMPONENTS '{jres: ["JavaBuildpack::Jre::SapMachineJRE"]}' cf restage
Why SapMachine?
SapMachine is a professionally maintained and supported OpenJDK release. It is built by a team with a long standing experience and a considerable footprint in the OpenJDK project. This allows us both, to fix arbitrary issues and contribute new features directly to the OpenJDK but also to maintain specific enhancements in the SapMachine if a contribution is not possible right away.
The post Sweet SapMachine and the OpenJDK appeared first on JAXenter.
Source : JAXenter
