The Java ecosystem is incredibly diverse.  It powers billions of devices and servers. It is key to cloud infrastructure worldwide. Even just the Java Platform, Standard Edition, “Java SE”, which is the core Java platform for general computing, is itself diverse.

We on the Java Platform Group at Oracle think of our work on “Java SE” in four main areas, described below.

1) OpenJDK.  OpenJDK is the place we collaborate on an open-source implementation of the Java Platform, Standard Edition, and related projects.  Our commitment to OpenJDK remains as strong as ever and we even recently kicked off the JDK 10 project there. OpenJDK enjoys broad participation across the ecosystem. It has consistently grown in activity since Oracle acquired Sun.  For example, most major Linux distributors and other parties such as Red Hat, Canonical and SUSE produce and ship binaries based on this opensource code.  The source code is available under the popular GNU General Public License v2, i.e. it's completely gratis. Commercial source licenses are also available for companies that would like to license the source code for a multitude of purposes, and dozens have, such as HP, SAP, IBM and others who produce their own commercial Hardware/OS products for which they'd like to have a commercial grade Java SE port available.

2) Oracle's Java SE implementation, aka "Oracle JDK" and "Oracle JRE".  The Oracle JRE/JDK is Oracle's implementation of Java SE.  Just as many other companies (like SAP, Red Hat, IBM, HP, etc) provide their implementations of Java SE to their customers, so does Oracle.  We have two main channels for our binary distributions -- java.com is for consumers who may want to run the Java Runtime Environment (JRE) on their home computers for applications like Minecraft or other Java based consumer software, and the Java Development Kit (JDK) on OTN which is targeted to developers and enterprises.  These binaries are gratis for the vast majority of use cases as noted in java.com/license.

 3) Oracle Java SE Advanced, Java SE Advanced Desktop, Java SE Suite.  In addition to Oracle's core Java SE implementation, Oracle also provides additional advanced tools and features that target enterprise users.  These features include the tools to help monitor, manage and deploy Java within an enterprise, advanced runtime diagnostics and monitoring, as well as access to support and updates to legacy versions of Java SE such as Java SE 6, and Java SE 7. These commercial features are provided as separate downloads available via “My Oracle Support” or OTN, and to the degree they need to interact with the Oracle JRE, they are turned off by default in that product, and can be enabled using the "-XX:+UnlockCommercialFeatures" flag at runtime in your JVM, for example. More information on specific commercial features can be found in Table 1-1 here.

 4) Java SE embedded.  As noted in (2), the Oracle JRE/JDK is gratis for most use cases, where it is running on a General Purpose desktop or server.  If a customer would like to embed the Oracle JDK/JRE in a device of some kind (eg, a cash register) then the gratis BCL license does not apply. In such cases a commercial Java SE embedded license needs to be negotiated. Java SE embedded also provides additional binary options for resource constrained devices and more embedded oriented chip sets.

Visual VM is a tool that provides information about code running on a Java Virtual Machine.  It was provided with Oracle JDK 6, Oracle JDK 7, and Oracle JDK 8.

More information about Visual VM can be found on the NetBeans Profiler and Visual VM blog: https://blogs.oracle.com/nbprofiler/

Starting with JDK 9, Visual VM will not be included with Oracle JDK. Developers who would like to use Visual VM with Oracle JDK 9 or later can get it from the Visual VM open source project site.

Beginning with the April 2017 Critical Patch Update, JAR files signed using MD5 will no longer be considered as signed by the Oracle JRE.  Affected MD5-signed JAR files will no longer be considered trusted and as a result will not be able to run by default, such as in the case of Java applets, or Java Web Start applications.[Read More]

One of the most recently popular posts on the Java Platform Group Product Management blog has been “Moving to a Plugin-Free Web” from January 2016.

In the interim, the Oracle development team has published a JDK Enhancement Proposal (JEP 289: Deprecate the Applet API) with technical details about the planned deprecation step in JDK 9. In short, JEP 289 proposes to add the @Deprecated annotation to classes in the Applet API, rather than removing them. The implementation of the proposal has made its way into JDK 9 Early Access releases, which are available for download and testing.

In addition, updated timelines for removal of standards-based plugin support from their browsers, eliminating the possibility to embed Flash, Silverlight, Java and other plugin based technologies, have been announced by the developers of Apple Safari and Mozilla Firefox. Please consult the linked blog posts by their vendors for details of the announced changes in those browsers as well as the timelines for those changes to be implemented and rolled out to the public.

JavaOne 2016 has opened its Call for Proposals to speak at the conference. This year, security topics take place in the Core Java Platform track.

Speaker Proposals must be submitted by May 9th. The conference itself takes place from September 18-22 in San Francisco. Accepted speakers will receive a gratis pass to attend.

Before each JavaOne conference, we receive a number of great submissions from Java community members around the globe, about different security topics. Our review committee also tries to call attention to help solicit interesting proposals and guide speakers. If you are familiar with running or coding Java and want to speak at JavaOne, consider applying your expertise to the following areas:

• Architecture & Analysis – how should security architects and developers build/integrate applications to evaluate and verify security?
• How does this change for green-field versus inherited applications?
• How should you build and maintain a threat model of an application and its environment? (bonus for breaking a threat model down into JDK 9 jigsaw modules)
• What is the importance of library code, and how/when/why should it be updated? What are strategies to test compatibility?
• When micro-services are connected, how does that impact trust boundaries?
• Development – how can developers evaluate and test their own applications?
• Code analysis (both for what you write and use)
• Penetration testing or scanning of Java applications
• There are many different secure development standards frameworks. What are they and how can they be used to test applications?
• Operations – when running Java, what are the proper strategies for configuring, managing, and upgrading JVMs?
• What are strategies between minor versions (e.g. 8uA to 8uB) and major versions (e.g. from JDK 8 to JDK 9)? How is the compatibility guide used?
• What are monitoring strategies to analyze JVM security events? What are connections between current logging frameworks and/or the planned Unified Logging API for JDK 9?
• How should a JVM or Java web server be tuned to achieve an A+ rating on SSL Labs? What about TLS for non-HTTPS uses, such as JDBC?
  For helpful tools, see Diagnosing TLS, SSL, and HTTPS as well as Deep Violet.
• Other ideas – there are many great ideas in the Java ecosystem, so please submit yours!

Java’s garbage collection capabilities make it easier for developers to write software and focus on the task at hand, without focusing on freeing up unused memory. In JDK 9, the G1 garbage collector will likely become the default collector and can do more than simply freeing memory. Instead of a simple garbage collector to free up memory, G1 takes the role of a waste management consultant: freeing unused memory and identifying ways to reduce the overall amount of garbage.

String Deduplication may decrease heap usage by about 10%

String objects are among the most commonly used object by almost all applications. Applications often store the same String multiple times for a variety of reasons, either within one class or across many classes. By analyzing these Strings, the JDK can decrease the overall memory needed to store them.String Deduplication may decrease heap usage by about 10%

String deduplication was first introduced in JDK 8 update 20 and operates as a background task. As the G1 garbage collector walks through memory references to clean up, it analyzes Strings to find duplicates and create memory-saving links between them. Similar to other garbage collection tasks, developers do not need to modify any code in order for it to work. An analysis by Fabian Lange from Codecentric found that String deduplication “adds no runtime overhead as it is performed asynchronously and concurrent during garbage collection.”

The following flags are needed to enable String Deduplication on JDK 8:

-XX:+UseG1GC	Enables the G1 garbage collector.
-XX:+UseStringDeduplication	Enables the String Deduplication feature within G1.
-XX:+PrintStringDeduplicationStatistics	Optional flag to analyze what is happening through the command-line.
-XX:StringDeduplicationAgeThreshold=3	Optional flag to change when Strings become eligible for deduplication.

Example: Decreasing memory used by the Eclipse IDE

Eclipse is a popular Integrated Development Environment, helping developers read, write, and construct source code. The G1 garbage collector will typically perform better for long-running applications focused on throughput (e.g. servlet containers), but it can also function well for client applications.

The following example was run on JDK 8u72 with Eclipse Mars. I am also turning on a Java Flight Recording to see the impact on garbage collection, object allocation, and overall memory consumption. I ran the same operations twice: once without –XX:+UseStringDeduplication and the filename of before.jfr, so that I could do somewhat of a comparison.

The following lines can go inside your eclipse.ini at the end:The following lines can go inside your eclipse.ini at the end:

-XX:+UseG1GC
-XX:+UseStringDeduplication
#The lines below are not necessary for G1, I am including them to benchmark the difference
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
-XX:StartFlightRecording=filename=after.jfr,dumponexit=true,maxage=5m,settings=c:/Users/ecostlow /desktop/Everything-Costlow.jfc
-XX:FlightRecorderOptions=dumponexit=true,disk=true,maxage=10m

As a background task, String deduplication was taking about 0.0000908 seconds during my brief usage. It probably took longer to print statistics. Although my laptop is not a controlled environment and I manually did the same actions, the overall heap usage went down about 9% from 233MB to 213MB during my five minutes of usage.

Here are the details from the final output of the String Deduplication Statistics (using -XX:+PrintStringDeduplicationStatistics) with some cumulative numbers:

[GC concurrent-string-deduplication, 14.5K->6120.0B(8744.0B), avg 38.6%, 0.0000908 secs]
   [Last Exec: 0.0000908 secs, Idle: 0.8590383 secs, Blocked: 0/0.0000000 secs]
      [Inspected:             142]
         [Skipped:              0(  0.0%)]
         [Hashed:              89( 62.7%)]
         [Known:               21( 14.8%)]
         [New:                121( 85.2%)     14.5K]
      [Deduplicated:           96( 79.3%)   8744.0B( 58.8%)]
         [Young:                0(  0.0%)      0.0B(  0.0%)]
         [Old:                 96(100.0%)   8744.0B(100.0%)]
   [Total Exec: 52/0.1772395 secs, Idle: 52/103.0713572 secs, Blocked: 2/0.1476086 secs]
      [Inspected:          322160]
         [Skipped:              0(  0.0%)]
         [Hashed:          164740( 51.1%)]
         [Known:            61960( 19.2%)]
         [New:             260200( 80.8%)     20.3M]
      [Deduplicated:       144975( 55.7%)   8037.4K( 38.6%)]
         [Young:                2(  0.0%)     72.0B(  0.0%)]
         [Old:             144973(100.0%)   8037.3K(100.0%)]
   [Table]
      [Memory Usage: 4213.1K]
      [Size: 131072, Min: 1024, Max: 16777216]
      [Entries: 132446, Load: 101.0%, Cached: 3622, Added: 170306, Removed: 37860]
      [Resize Count: 7, Shrink Threshold: 87381(66.7%), Grow Threshold: 262144(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
   [Queue]
      [Dropped: 0]

Today, the Java Platform team is pleased to release Java Advanced Management Console version 2.2.  Available for production use with appropriately licensed Java SE Advanced products, the Advanced Management Console helps system administrators track and manage Java across their organization. Its usage tracking capabilities help system administrators create a Java application inventory to know which Java versions are used for which applications, and by whom. Administrators can then manage exposure of the browser plugin: allowing known-safe applications to run against older Java versions based on compatibility, and potentially blocking unknown applications altogether. 

This newest version of Advanced Management Console makes a number of improvements designed to streamline Java usage across client endpoints across a large organization:

• This version supports zero-configuration endpoints to better handle cases of multi-user systems and walk-up terminals. In previous versions, each agent installation needed a post-install configuration to identify the user. In AMC 2.2, this step is optional and the system offers more visibility on the hostname.
• Another streamlining capability helps simplify the certificates used by endpoints to verify the Deployment Rule Set. When installed, the DeploymentRuleSet.jar file must be signed by a trusted certificate. A number of organizations use self-signed certificates or act as their own internal certificate authority. As clients download updated Deployment Rule Set files from a trusted Advanced Management Console server, clients will apply transitive trust and import the Deployment Rule Set’s certificate. As a result of this change, systems will see fewer cases of "DeploymentRuleSet.jar is not valid."

If your organization is looking to manage the security and compatibility of many different Java versions, please download an evaluation copy of the Advanced Management Console.

By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Flash, Silverlight, Java and other plugin based technologies.

With modern browser vendors working to restrict and reduce plugin support in their products, developers of applications that rely on the Java browser plugin need to consider alternative options such as migrating from Java Applets (which rely on a browser plugin) to the plugin-free Java Web Start technology.

Oracle plans to deprecate the Java browser plugin in JDK 9. This technology will be removed from the Oracle JDK and JRE in a future Java SE release.

Early Access releases of JDK 9 are available for download and testing at http://jdk9.java.net. More background and information about different migration options can be found in this short whitepaper from Oracle.

Update:  Technical information about the planned deprecation step in JDK 9 can be found in JEP 289 .

With JDK 7 Oracle started delivering on that vision. It completed the work with JDK 8. Customers using the Oracle JRockit JVM, in the meantime, have been receiving periodic security updates and bug fixes. CPU releases and bug fixes for Java SE 6 JRockit (R28 only) will continue to be provided until the end of JRockit for Java SE 6's extended support phase, currently scheduled for December 2018.

One of the smaller, but rather important planned changes for JDK 9 is an updated JDK version string scheme. It is described in detail in JEP 223.

The new version string scheme makes it easier to distinguish major, minor and critical patch update (CPU) releases, by encoding each property into a separate numerical component as part of a JDK version string. Following the new MAJOR.MINOR.SECURITY convention, JDK 9 version strings would start with ‘9’ for the MAJOR release component.

For example, if the JDK 9 GA release (with the version string: ‘9’) were to be followed by a CPU, then that CPU would carry the version string ‘9.0.1’. If that CPU were to be followed by a minor release with additional changes on top of those already found in the ‘9.0.1’ release, than the new release would carry the version string ‘9.1.1’. If in turn, that minor release were to be followed by another CPU, the new CPU would be designated as ‘9.1.2’, leading to the following hypothetical sequence of release versions:

9	GA
9.0.1	CPU: 9 + critical changes
9.1.1	Minor release: 9.0.1 + other changes
9.1.2	CPU: 9.1.1 + critical changes
9.2.2	Minor release: 9.1.2 + other changes
9.2.3	CPU: 9.2.2 + critical changes
9.2.4	CPU: 9.2.3 + critical changes
9.3.4	Minor release: 9.2.4 + other changes

 

The individual components of the version string would start at 0 and then increase based on the type of a release, making it easy to check whether a local installation meets a given security baseline by looking at the third, i.e. SECURITY, component of the JDK 9 version string.

Due to the changes in the version string scheme, code that parses JDK version strings could need to be adjusted - for example if it assumes that the first element of a JDK version string always has the value of ‘1’ (as in ‘1.9.0_ea-b19’), and therefore always skips to the second element when comparing releases. Details on the adjustments can be found in the JEP text.

In addition, the JEP text describes other types of information that can be encoded in a JDK 9 version string, like build numbers, as in ‘9.0.1+63’.

Developers, who would like to test the planned changes, can do so by downloading a JDK 9 Early Access Build at jdk9.java.net. Feedback on the planned version string scheme changes should be directed to the verona-dev mailing list.

The scheduled Critical Patch Update of Oracle Java SE on January 19 2016 is planned to disable X.509 certificates signed with MD5. Plans are also being developed to disable X.509 certificates signed with SHA-1 and further details will be announced in a future post.

Specifically, this change will treat certificate chains containing a certificate with an MD5-based signature to be invalid and blocked by default. This affects Java clients and servers using TLS (via the JSSE API), signed applets and Web Start applications, and any application using the PKIX implementation of the CertPath API to validate certificate chains.

This was previously covered in a post, Strengthening Signatures, and is similar to announcements from other platform providers like Microsoft, which deprecated MD5 in June 2014 and is focusing on SHA-1 efforts for 2016.

System Administrators wanting to test their systems can update their JAVA_HOME/lib/security/java.security file and add MD5 into jdk.certpath.disabledAlgorithms.

Change "jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024" to "jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024"

After this change, the MD5 algorithm will still be available for other non-certificate uses. For example applications that use MessageDigest.getInstance("MD5") for alternate reasons will continue to function.

For System Administrators that must re-enable the weaker MD5 algorithm

In cases where a system authenticates itself through MD5 signatures, system administrators are encouraged to generate newer certificates that use SHA-256 or higher.

Users are encouraged to accept the default security settings and not re-enable MD5 in X.509 certificates. However, if necessary, MD5 can be re-enabled in either of the following ways:

Option A (preferred if weak MD5 is needed), by using a startup flag that will only impact specific applications. Create a file that copies the jdk.certpath.disabledAlgorithms line from JAVA_HOME/lib/security/java.security Remove MD5 from that line In your startup command, add -Djava.security.properties=FILE Plan your migration away from weak algorithms and undoing this change.

Option B, editing a configuration file that will affect all applications used by a JRE: Open JAVA_HOME/lib/security/java.security Remove MD5 from the line jdk.certpath.disabledAlgorithms Plan your migration away from weak algorithms and undoing this change.

SHA-1 plans

We are also working with industry groups on a plan to migrate away from certificates signed with SHA-1. The Certificate Authority Browser Forum previously set guidance to avoid issuing new SHA-1 certificates after January 2016. This guidance assists in our planning, as well as that of peer programs such as Microsoft, Mozilla, and Google. 

 

"Java update available -- a new version of Java is ready to be installed..."

This occurs four times a year: January, April, July, and October.

Oracle Java SE is updated on the Oracle Critical Patch Update schedule. The date for these updates is published a year in advance. This schedule helps system administrators manage software across a fleet of systems. Combined with another feature, the security baseline, client systems can detect newer security updates and adjust their behavior by offering an update and decreasing the client’s attack surface.

System Administrators can use Deployment Rule Sets to control compatibility if they need a version below the security baseline.

The Security Baseline

The security baseline received new behavior in Java 7 update 10 (December 2012), combining it with the JRE expiration date. Prior to this, it has identified which Java versions contain the latest security patches since JDK 1.4. There is a different baseline version for each major Java version: Java 6, Java 7, and Java 8. The JRE will identify that it should be updated in two main ways:

• The JRE will periodically check the security baseline to see if a new version is available. If it detects that it is below the security baseline, it will consider itself to require an update to a version that meets the security baseline requirement.
  The schedule for this periodic check can be controlled by system administrators.
• If clients cannot obtain the security baseline for any reason, they will eventually reach their built-in expiration date. This expiration date is published in every release note, but it is typically a month after the next scheduled critical patch update.
  This expiration date is built in and cannot be controlled.
• For example at time of writing (November 2015), the current security baseline for Java 8 is 1.8.0_65. The next scheduled Critical Patch Update is January 19th. The expiration date for Java 1.8.0_65 is February 19th.

In addition to Critical Patch Updates, there is another release type called a Patch Set Update(PSU), which contains additional non-critical changes. Although a PSU version is numerically “above” the security baseline, the PSU contains the exact same critical patches as the corresponding CPU at the security baseline. Example: At time of writing, the security baseline is 1.8.0_65. A different patch set update, 1.8.0_66, is available with additional changes. Users that only want critical patches do not have to deal with these changes yet, and can test them separately. In the next scheduled Critical Patch Update, we will include those changes from 1.8.0_66.

What happens when the security baseline changes or the expiration date passes

When clients detect that it is below the current security baseline, they will typically do two things: prompt end-users to install the newer update, and decrease the potential attack surface of the installed JRE.

These changes are described in the Rich Internet Application Deployment Process under the question, “Is the JRE expired or below the security baseline.” Desktop administrators that need to control prompts and/or use Java versions below the security baseline may do so through Deployment Rule Sets, under the question, “Does a rule exist for this RIA.”

The attack surface reduction applies to Rich Internet Applications (through browsers).

Planning for updates

With the dates of Critical Patch Updates published a year in advance, system administrators should plan ahead to roll out Java updates onto client systems. Deployment Rule Sets should be used with applications that cannot use the latest Java Runtime Environment for one reason or another, to whitelist which known-safe application can use specific older JREs. Critical Patch Updates are available to Java 6 and Java 7 through the commercial Java SE Advanced, along with other management tools.

Administrators needing to deploy Java across thousands of managed systems every quarter may consider the commercial Java SE Advanced, which offers tools to better manage Java at scale. Examples of these commercial features include:

•  An enterprise MSI installer to support easier customization and deployment.
• Critical Patch Updates for older versions of Java beyond public support (e.g. Java 6 and Java 7).
• The Advanced Management Console, to help build an application inventory of Java applications and create a Deployment Rule Set from tracked usage.
• Java Flight Recorder and Mission Control, for deep performance analysis.
• Support from an experienced team that can monitor and track Java bugs.
  

Additional Resources

• Introducing Deployment Rule Sets
• Deployment Rule Sets by Example
• Advanced Management Console
• Video Walkthrough
  
• Managing Multiple Java Versions
  

Java’s rapid rise to fame 20 years ago began with a tumbling duke applet running in the HotJava browser. Applets allowed richer development functionality at a time when browser capabilities were very limited, and provided centralized distribution of applications without requiring users to install or update applications locally.

HotJava’s support for applets was picked up by Netscape. In 1995 Netscape Navigator 2.0 and plugins became more popular to expand the kind of content that could be displayed. Navigator’s plugin interface (NPAPI) was adopted by other browsers and supported since 2004. Support for Java applets across several different browsers was implemented relying on the common NPAPI plugin interface to provide cross-browser compatibility of Java applications running on the web.

As Java evolved to become one of the leading mainstream development platforms, so did the applet’s hosts – the web browsers.  The rise of web usage on mobile device browsers, typically without support for plugins, increasingly led browser makers to want to restrict and remove plugin support from their products, as they tried to unify the set of features available across desktop and mobile versions. Coincidental with the rise of mobile was the emergence of the “app store” model rather than “plugin based” models for application delivery. The “app store” model grew for reasons related to simplicity, security, and centralized availability. Given these evolutions in mobile, delivery, and capabilities, the set of browsers that continue to support standards based plugins has shrunk over time.

The announcement from Mozilla provides a timeline for developers and users who rely on Mozilla Firefox for applets to evaluate and migrate to alternatives. You should consider using plugin-free technologies, like Java Web Start, or move to other supported browsers, before NPAPI functionality is removed from Firefox in their regular and/or Firefox Extended Support Releases.

As with other browsers, the Oracle JRE can only support applets on Firefox for as long as Mozilla provides the requisite NPAPI support. Having been in regular contact with the Mozilla engineering team over the past years, we have worked together to ensure that our common users benefit from improvements made in Firefox and the Oracle JRE.  We'll continue to collaborate on enabling a smooth transition to plugin-free technologies like Java Web Start.

Meanwhile, we don’t plan to provide additional browser-specific plugins, as such plugins would require application developers to write browser-specific applets for each browser they wish to support. Moreover, we would only be able to offer a subset of the required functionality, different from one browser to the next, impacting both application developers and users.

As with previous transitions, any additional information specific to Oracle products will be provided by the corresponding product teams. Internet Explorer and Safari browsers are not impacted by this change.

System administrators who want to prepare for the transition and learn more about applets (and other kinds of Java applications) running inside their organization should evaluate the Java Advanced Management Console. 

Java applications can be distributed to clients through download capabilities like Applet and Web Start. These applications are delivered to users through web browsers, allowing for convenient access on client systems.

Web Start applications can be launched from any web browser by opening the application’s JNLP file. Once opened, these applications no longer rely on browser plugins or integrations. Instructions for launching JNLP files can be located in "What is Java Web Start and how is it launched" on Java.com. In short, this involves associating the .jnlp file association with Java’s javaws command.

Desktop Administrators can control Web Start dialogs/prompts by using Deployment Rule Sets (DRS). This DRS feature enabled administrators to create an application whitelist that can control execution of known-safe applications as well as manage compatibility between different versions of Java on the same system.

System Administrators can use the Java Advanced Management Console to track Java usage within their organization, identifying Applet, Web Start, and other Java application types. This usage tracking enables them to identify which versions of Java are used by which applications, and create Deployment Rule Sets to manage compatibility between versions.

Later this year, the Oracle JDK team plans to restricting the use of MD5 signatures within X.509 certificates used by SSL/TLS and code-signing. This will take place in the public versions of JDK 9 (early access) and JDK 8, as well as the commercially supported JDK 7.

The IETF has recommended a move away from MD5 since 2011.

Most Certificate Authorities followed this guidance by requiring stronger signatures (typically in the SHA family). Although the default JDK options switched away from MD5 in the past, additional time was necessary for organizations to phase out their use of MD5 and reissue certificates with stronger hash algorithms.

System Administrators that still actively use certificates with MD5 hashes should consider revoking and/or re-issuing those certificates with stronger signatures. Developers that have previously signed artifacts with MD5 signatures should consider re-signing and timestamping these artifacts.

This change will only affect MD5 usage in regards to certificates. This will not affect other uses, such as MD5 hashing of files to generate checksums or perform simple checks.

System Administrators can control algorithm availability by adjusting their JRE configuration. For example, some organizations may still rely on internal systems that require MD5. Users of these systems will likely see a message "constraints check failed: MD5withRSA" in their application logs.

This configuration change takes place within the jre/lib/security/java.security file. The specific property is jdk.certpath.disabledAlgorithms.