The Big Switchover.

From version 15.3 on, Excelsior JET will include the OpenJDK implementation of the standard Java SE API.

OpenJDK Logo

Download an Excelsior JET 15.3 Evaluation Package

As you know, Oracle has changed its Java business model beginning with Java SE 11. Simply put, developing and testing with Oracle Java is still free, but you have to pay Oracle for its production use even on General Purpose Desktop Computers and Servers, as that term used to be defined in the previous Java SE license, the BCL. Those who do not want to buy a Java Subscription from Oracle can use OpenJDK, which shares nearly all of its codebase with the Oracle JDK, but comes under a different, open source license, namely GPLv2 with Classpath Exception.

Up to and including version 15, the Excelsior JET Runtime consisted principally of our own, clean-room JVM implementation and the licensed Oracle implementation of the Java SE API. A continued use of the latter in our product would have required us to align its licensing conditions with the new Oracle Java business model, essentially introducing mandatory runtime royalties or subscription payments. That would apply to all new versions of Excelsior JET, whether they support Java 11+ or Java SE 8.

To avoid imposing such obligations on our customers, from version 15.3 onwards Excelsior JET will include the OpenJDK implementation of the Java SE API instead. We've made sure to use only those parts of OpenJDK that fall under the Classpath Exception, so as to preclude a contamination of our product and, transitively, our customers' applications with the GPL.

For more details, consult the OpenJDK API Switchover FAQ below.

What essentially is being replaced with what?

Any Java SE Platform implementation includes two principal components:

  • A Java Virtual Machine (JVM) that provides the low-level services to the application such as threading, synchronization, memory allocation, garbage collection, class loading, etc., and
  • An implementation of the standard Java SE API that in particular abstracts away the differences in functions and capabilities of the underlying operating systems and middleware.

Excelsior JET includes our proprietary JVM and AOT compiler. The AOT compiler produces native binaries interoperable with our JVM. They used to be bundled with the implementation of the standard Java SE API that we commercially licensed from Sun Microsystems and later from Oracle.

However, as of Java SE 8, the standard API implementations in the Oracle JDK and OpenJDK were almost identical from the technical standpoint. Only some portions of the graphics API use different libraries underneath. So technically Excelsior JET could have included the OpenJDK implementation of the API instead for many years already.

Will I need to change the end user license agreement for my optimized application?

To the best of our understanding, supported by the opinion of our legal counsel, the answer is no. The Classpath Exception to the GPL essentially says your application code can link with the library licensed under the CE and copy and distribute the resulting executable under the terms of your choice.


Certain source files distributed by Oracle America and/or its affiliates are
subject to the following clarification and special exception to the GPL, but
only where Oracle has expressly included in the particular source file's header
the words "Oracle designates this particular file as subject to the "Classpath"
exception as provided by Oracle in the LICENSE file that accompanied this code."

We have made absolutely, 100% sure to incorporate only those OpenJDK source code files in the Excelsior JET codebase that do have those words in their headers.

    Linking this library statically or dynamically with other modules is making
    a combined work based on this library.  Thus, the terms and conditions of
    the GNU General Public License cover the whole combination.

    As a special exception, the copyright holders of this library give you
    permission to link this library with independent modules to produce an
    executable, regardless of the license terms of these independent modules,
    and to copy and distribute the resulting executable under terms of your
    choice, provided that you also meet, for each linked independent module,
    the terms and conditions of the license of that module.  An independent
    module is a module which is not derived from or based on this library.  If
    you modify this library, you may extend this exception to your version of
    the library, but you are not obligated to do so.  If you do not wish to do
    so, delete this exception statement from your version.
What are the differences between the OpenJDK and Oracle JDK implementations of the Java SE API?

As of Java SE 8 Update 181, the differences between the two API implementations are mostly local to the libraries that power the graphics pipleine:

Implementation Oracle JDK OpenJDK
Font rasterizer T2K Freetype
Color management Kodak CMM LCMS
Graphics renderer
(replaced with Marlin in Java 9)
Ductus Pisces

There is one more difference that may be important for certain usage scenarios. The cryptography framework in the OpenJDK API does not restrict which providers can be used, whereas the Oracle JDK version requires the third party cryptographic providers to be signed by a known certificate. This means that from Excelsior JET 15.3 onwards, unsigned providers will be accepted in addition to those with valid signatures.

Will you provide security updates for the LTS versions of Java?
It is not clear yet whether Oracle or a third party will be contributing the respective patches to OpenJDK or not. If this uncertainty resolves positively, we would by all means include those patches in new Excelsior JET versions and updates.

Engineering Team
Any technical questions or issues

Sales Team
Pricing, licensing, support renewals, etc.

Front Desk
All other issues.