As the Java platform moves forward, we look for ways to reduce and eliminate technical debt. One example is the planned removal of deprecated Garbage Collection combinations, as outlined in JEP 214. As another example, in Java 8 update 40, as part of JEP 220, we will be deprecating two rarely-used extension capabilities, with the intent to remove them in JDK 9, providing suitable replacements as necessary. Most developers do not use these features, and system administrators can quickly tell if any legacy systems will be affected.

What is changing: Removals of the endorsed-standard override mechanism and the extension mechanism

Previous versions of Java SE have allowed developers to place JAR files into two directories within the JRE, making anything in those JAR files available to all launched applications.

The original Endorsed Standards Override Mechanism enabled Java to quickly take advantage from new versions of external standards that were developed outside of the JCP, such as CORBA and XML Processing. As different libraries and build systems became available, developers have taken a preference of including such libraries directly within their applications rather than deploying these endorsed standards directories within the JRE. The Extension Mechanism enabled developers to do similar activities by placing JAR files into a jre/lib/ext directory.

Details about this planned change for JDK 9 can be found in JEP 220. The associated ticket, JDK-8065702 discusses the deprecation of the extension mechanism in JDK 8. As called out in the ticket, there will be a new JVM flag in JDK 8u40 that people can use to see if this change will cause any problems: -XX:+CheckEndorsedAndExtDirs.

When is this change taking place?

A preliminary feature is being introduced in Java 8 update 40, that will allow developers to more easily identify if they will be affected by this change. No actual changes are being made; rather this is a tool to help identify potential future problems.

The actual change to remove this under-used functionality will take place alongside the release of Java 9. By providing detection tools in advance, we intend to help applications that plan to adjust.

Developers: Why most applications are unaffected

The majority of applications in use today do not use either of those features and will be unaffected by this change. Instead, most applications bundle third party JAR files. By bundling their own dependencies, applications could be moved between systems without requiring pre-requisite files to be installed inside the JRE. It has also made upgrades easier, where system administrators can upgrade the JRE without worrying about these internal directories.

If you are building or maintaining an application that requires third party JAR files to be present in the JRE, please consider providing those JAR files as part of your application.

System Administrators: How to tell if your applications are affected

System Administrators managing deployments may want to verify that their applications will be unaffected by this change.

Use a Java startup flag (recommended)

The easiest way to identify usage of endorsed standards is to ask the JVM to detect their usage.

When launching Java applications and servers, add -XX:+CheckEndorsedAndExtDirs to your invocation. This will cause the system to print a message about any unexpected items in the endorsed standards or extensions directory.

Check your jre/lib/ext directory

One way to identify if this change will affect anything is to look at your JRE’s jre/lib/ext directory and see if there is anything present there that is not included by default.

The following is a sample list from my system to identify a normal installation. If your folders look like this, then you are not using the extension mechanism.

Java 8 update 25 jre/lib/ext

Java 7 update 60 jre/lib/ext

Thirteen (13) files:

access-bridge-64.jar

cldrdata.jar

dnsns.jar

jaccess.jar

jfxrt.jar

localedata.jar

meta-index

nashorn.jar

sunec.jar

sunjce_provider.jar

sunmscapi.jar

sunpkcs11.jar

zipfs.jar



Nine (9) files: access-bridge-64.jar

dnsns.jar

jaccess.jar

localedata.jar

meta-index

sunec.jar

sunjce_provider.jar

sunmscapi.jar

zipfs.jar



The presence of anything listed above is normal and expected. Other files are not.

What to do if you are affected

Although most applications do not use the endorsed standards or extension mechanism, some applications do. If you are a developer, please consider providing dependencies as part of your application rather than requiring external system configurations. If you are not the developer, please contact the individual software vendor for support.