Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • February 17, 2015

Planning safe removal of under-used “endorsed extension” directories

Guest Author

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.

Join the discussion

Comments ( 6 )
  • guest Wednesday, February 18, 2015

    For the last several days, users of Internet Explorer 11 cannot Install / Update Java from www.java.com

    A bug report has been filed and a post made in the Oracle Community forums.


    Is Oracle not serious about supporting Java on Internet Explore 11 ?

    How can this problem not be detected by Oracle QA and testing ?

  • costlow Thursday, February 19, 2015

    There is a reply on your linked post from RogerL (Oracle) on the 17th, shortly after your report, saying that the issue is being investigated. Based on dates (today is morning on the 19th), he is likely still investigating the issue and will reply on that forum. I recommend following up there.

    The post on this blog is unrelated to applets.

  • JP Wednesday, March 4, 2015

    Any information on how Java input methods will be handled if the extension mechanism is removed? Currently, I believe the only way to install a Java IMF input method is by putting the jar in the extension directory.


  • costlow Friday, March 6, 2015

    JP - The current process is simply to notify and provide people with information to prepare for the future. JDK 9 has made changes to load SPIs like IMF from the classpath. See https://bugs.openjdk.java.net/browse/JDK-8062588 for details and you can grab early-access JDK 9 builds from https://jdk9.java.net/

  • puce Thursday, March 12, 2015

    Is there a way to "prepare for the future" when using the endorsed-standards override mechanism? AFAIK adding them to classpath won't have any effect since the classes from the JRE will be preferred. That's why this endorsed-standards override mechanism exists.

    Note my question at StackOverflow: http://stackoverflow.com/questions/28983922/alternative-for-deprecated-endorsed-standards-override-mechanism-and-extension-m

  • costlow Tuesday, March 17, 2015

    The linked bug above (JDK-8062588) offers support for loading items from the classpath, such as java.util.spi.*, java.text.spi.*, java.awt.im.spi

    That will handle both the IMF input methods above and your case. Consider testing your library against early access builds via https://jdk9.java.net

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.