Wednesday Jan 27, 2016

Java Advanced Management Console 2.2

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.

Moving to a Plugin-Free Web

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.

Tuesday Jan 19, 2016

Now Available: Migration Guide from Oracle JRockit JVM to HotSpot JVM

During the 2010 JavaOne conference Oracle announced that it would merge the Oracle JRockit JVM and HotSpot JVM by incorporating the features that were only available in JRockit into HotSpot.

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.


Migration Guide for customers moving from the Oracle JRockit JVM to the HotSpot JVM has been published. It provides information on many common tools and options available for JRockit and their HotSpot counterparts.

Sunday Dec 06, 2015

A New JDK 9 Version String Scheme


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.

Monday Nov 16, 2015

Strengthening Signatures part 2

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.
  1. Create a file that copies the jdk.certpath.disabledAlgorithms line from JAVA_HOME/lib/security/java.security
  2. Remove MD5 from that line
  3. In your startup command, add -Djava.security.properties=FILE
  4. 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:
  1. Open JAVA_HOME/lib/security/java.security
  2. Remove MD5 from the line jdk.certpath.disabledAlgorithms
  3. 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

 

Thursday Nov 12, 2015

When is the next Java update?

"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.

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:

Additional Resources

Thursday Oct 08, 2015

NPAPI Plugin Perspectives and the Oracle JRE

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

Monday Aug 31, 2015

Launching Web Start applications

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.

Wednesday Aug 05, 2015

Strengthening Signatures

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.

Wednesday Jun 24, 2015

The 2015 Leap Second’s impact on the Oracle JDK

On June 30, the official Universal Coordinated Time will experience a leap second. Many technical news sites have written about this upcoming leap second’s impact on various technical systems.

System Administrators concerned about leap seconds should focus on it as a standard maintenance problem of updating Java’s time zone information and using operating system time tools like NTP.

Update Time Zone Information

Time Zone updates were covered in a previous post, Understanding Time Zone Updater 2.0. System Administrators looking to update their systems can simply use the tzupdater tool to update JDK installations. Alternately, each JDK release always contains the latest time zone information for users that upgrade.

Check the Operating System

Java relies on the operating system clock for time. Each operating system has its own method of handling date changes such as leap seconds. Consult your operating system information for details on handling the leap second. Linux users may consult the Wired interview with Linus Torvalds, "Linux’s creator wants us all to chill out about the leap second."

Details for Windows can be found in KB-909614 How the Windows Time service treats a leap second. Hosting providers like Amazon and Google will be doing a time skew over the course of a day.

Some applications may still require restarts

Although the Java API defines a second as a number between 0 and 61 to accommodate leap seconds, some applications may have taken short-cuts to assume that there are 60 seconds in a minute or 86400 seconds in a day. Systems that perform synchronized time-based transactions with other systems may run into issues if one system updates and another does not.

The 2015 leap second takes place at exactly 23:59:60 UTC on June 30, 2015. I advise system administrators to monitor processes during this time and pay extra attention to systems for a short while.

Monday Jun 15, 2015

Deferring to Derby in JDK 9

Java DB is simply a re-branded distribution of the Apache Derby open source database. It contains the same binaries as Apache Derby.

As of JDK 9, it is no longer being planned to include it in the 'db' directory of Oracle JDK downloads.

Developers looking ahead to JDK 9 should plan to get and bundle Apache Derby independently for the same purpose.

 - Don 

Tuesday Apr 21, 2015

Understanding Time Zone Updater 2.0

The JRE uses the IANA Time Zone Database for its time zone calculations. To keep this information up to date users must keep their JRE versions up to date or use a utility called TZUpdater available from Oracle. Until recently a new version of TZUpdater was needed for each Time Zone Database update. An enhancement to the tool lets users get the latest information directly from IANA allowing users to rely on the same tool for all future update. [Read More]

Tuesday Mar 31, 2015

JavaOne 2015 Call For Proposals Is Open

The call for proposals is now open for JavaOne 2015. If you are interested in speaking, please submit your abstract to the site.

Key Information

  • JavaOne 2015 will run from October 25th to the 29th in San Francisco.
  • The call for proposals ends on April 29 at midnight PDT. Submit your talk by then.
  • Accepted speakers receive complimentary passes to attend the conference.

Choose the best track for your topic

JavaOne features several different tracks based on different roles and interest. These tracks include core platform, security, JVM languages, DevOps/Cloud, Internet of Things (embedded), Server-Side development, Clients, and Tools & Agile methodologies. The 2015 tracks page provides a complete listing and description of each track.

Videos and materials from the 2014 conference are available for on-demand replay and access through both ActiveEvents and Parleys.

Security Track

This is the third year for a dedicated Security track at JavaOne, and I am honored to be on the review committee. Last year’s security track featured many great presentations. Among them, Frank Kim was recognized as a JavaOne Rock Star presentation for his talk on "Five Keys for Securing Java Web Apps." Typical talks on this track were about methodologies, analysis techniques to find threats/vulnerabilities, and advanced tool usage.

For those submitting talks, a few good topics would be:

  • Explain the relation between new Java 8 features and security. For example Java 8 introduced type annotations and their ability to annotate data such as local variables. By storing this information in bytecode, how can tool authors and library writers support each-other to make it easier to write secure code? What opportunities are present for things like the checker-framework’s tainting checker?
  • Designing code for security analysis, or designing security analyzers. As developers write code and as users run applications, how can we detect or prevent security issues before code gets released? How does the Java platform facilitate this detection both for Java as well as other languages featured on the JVM Language track?
  • Tools, libraries, and techniques. How does your team or organization make security decisions? If you have mastered usage of certain techniques or tools, share guidance and experience with your peers.

Thursday Mar 26, 2015

Future updates of Java 7 and Java 6

The upcoming release of Java 7 update 80 (April 2015) marks the last public release in Orale’s JDK 7 family. Java users should upgrade to the publicly supported JDK 8 or obtain a commercial support contract of Java SE Advanced for continued updates of JDK 7 and JDK 6.

Additional details can be found in the video, "Java SE 7 End of Public Updates" by Tomas Nilsson.

Support dates for the publicly supported JDK versions are as follows:

Oracle Java SE Public Updates
(copied as of March 26, 2015)
Major Release
GA Date
End of public updates
Commercial support timeline
JDK 5
May 2004
Oct 2009
Available through Java SE Advanced. See linked Oracle Java SE Support Roadmap.
JDK 6
Dec 2006
Feb 2013
JDK 7
Jul 2011
Apr 2015
JDK 8
Mar 2014
See roadmap

Companies that require older Java versions after the end of public updates may benefit from the fixes in these older versions, such as security enhancements.

The last public release of JDK 6 was Java 6 update 41 in February 2013. I recommend that users without commercial support contracts of Java SE Advanced use a publicly supported JDK, such as JDK 8. Oracle commercial customers whose applications depend on JDK 6 may download Java 6 update 91, released January 2015. This commercial release contains almost three years of bug fixes and security improvements.

Java 7 will follow a similar path. The last public release of Java 7 will be Java 7 update 80 in April 2015. After that time, I recommend that users without commercial support contracts upgrade to JDK 8. Oracle commercial customers whose applications depend on JDK 7 will still be able to download critical patches of JDK 7 in July and later, as identified by the Critical Patch Update schedule.

Versions of Java 8 are available to all, with or without commercial support, on Java.com and the Java SE Downloads page of the Oracle Technology Network.

Benefits of Java SE Advanced

In addition to support and patches, the commercial Java SE Advanced provides the following features:

  • Java Mission Control and Flight Recorder provide developers and system administrators with a way to monitor applications in production using a low-overhead profiler that captures runtime information. Flight Recorder can operate in a continuous loop and create recordings based on events – the loop enables developers to see what lead up to the event and not what happened after.
  • The Advanced Management Console offers system administrators with a way to track and understand Java usage across managed systems. By using the console, system administrators can manage a situation where different users need different versions of Java for different applications. By using usage tracking to create an application inventory, the system administrator can create a guided Deployment Rule Set to specify which applications need which versions of Java. The result is that older Java versions are available for compatible known-safe applications but cannot be used by modern-day internet threats.
  • The MSI Installer (through My Oracle Support) offers a simplified way for system administrators to customize and install Java onto many systems.
  • Additional technical features are available through runtime flags, such as Application Class Data Sharing to reduce startup times.

Tuesday Feb 17, 2015

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

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.
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« February 2016
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
     
       
Today