Known Issues

Area: Install / Linux 

Installing a 1.8.0 JRE rpms on a Linux host where an older revision of the JRE rpm was previously installed may experience problems. Prior releases of the JRE may be leaving files and directories which conflict with the 1.8.0 rpm and raise an error, such as:

file /etc/init.d/jexec from install of jre-1.8.0-fcs.x86_64 conflicts with 
file from package jre-1.6.0_10-beta.x86_64

This behavior can be overridden using the --force flag, which ignores package and file conflicts.

Syntax: rpm <rpm commands> --force <rpm-package-name>.rpm

Example: rpm -i --force jre-1.8.0-fcs.x86_64.rpm

Area: Install / Solaris 

During installation of SUNWj8rt and SUNWj8dev packages on Solaris, chksum errors may occur, causing partial installation failure, for example:

ERROR: content verification of <file> failed
file cksum <11517> expected <10771> actual
{...}
Installation of <SUNWj8dev> partially failed.

Though legitimate checksum errors may be thrown for other reasons, the errors above are limited to specific network configurations that are believed to be rare.

The errors do not affect core functionality. The install has completed successfully.

Area: Install / Windows 

The "Enable Java Access Bridge" check box gets removed from the Control Panel (go to Control Panel -> Ease of Access Center -> Use the computer without a display) when the 64-bit JRE 8 is uninstalled, even if a 32-bit JRE version 7u6 or later exists. The workaround is to uninstall the existing 32-bit JRE and install it again. The "Enable Java Access Bridge" check box will appear after the 32-bit JRE version 7u6 or later is installed.

1. Bug
2. 8030124

Area: Deploy  

If an application uses RMI and runs in a restricted environment (ie. Java Plug-in, Java Web Start), it may not work. In particular, if you run a UI from an RMI callback, a NullPointerException is likely to be thrown.

1. Bug
2. 8019274

Area: Deploy  

In some circumstances, the Java Control Panel reports the JRE platform version as 1.7 instead of 1.8 when upgrading an older JRE in the same path. This should not impact Windows or Linux users, but could impact Mac OS X users. If an applet requests version 1.8 in a JNLP file or an HTML applet tag, then the applet fails or loads resources for an older JRE than intended. To work around this issue, either delete the deployment.properties file, or edit the deployment.properties file and remove the JRE entry.

Area: Deploy / Mac OS X 

When running on OS X 10.9, certain actions in the Java Control Panel requiring administrative privileges do not work properly. Currently this impacts two features: disabling the Java Plug-in and disabling automatic update checks. The plugin will be disabled for the current user if the authorization dialog is cancelled, so users may still disable it but each user on the system will have to do so individually. There is no known workaround for disabling the automatic update check.

1. Bug
2. 8029309

Area: Deploy / Plug-In 

Using the family CLSID to trigger loading of an applet does not work with certain JRE family versions.

If you use the family CLSID to trigger loading of an applet with a certain JRE family version, the family CLISD will be ignored and the latest JRE version installed on your system is used to load the applet instead. Family CLSID is specific to Internet Explorer. The workaround is to use the java_version applet parameter or the version attribute of the Java element in JNLP file instead.

Area: Deploy / Plug-In 

Regression: JARSigningException exception throws when use 7u jarsigner.

JAR files signed with jarsigner from Java SE 1.4 or earlier versions, will not be signed properly when they contain resource files in META-INF, such as license docs or images.

For security purposes, such JARs are no longer considered to be validly signed. Currently applets using these JARs will fail to load, with no indication of the cause to the end user.

The only workaround is to re-sign the JAR with the current version of jarsigner.

Area: Deploy / Plug-In 

For signed jars without the manifest attribute "Permissions", there is still a security warning dialog before the Application Error (or Blocked) dialog.

If the signed main JAR file does not contain the required "Permissions" attribute in the manifest file, the application should be blocked. However the security dialog is shown first, asking the user's permission to run the application, before the application is blocked.

1. Bug
2. 8027821

Area: Deploy / Plug-In 

If a user has the deployment.security.level property set to MEDIUM when using JDK 7, the property is automatically upgraded to HIGH the first time that JDK 8 is used to run any deployment code. However, if there is also a system configuration setting for the deployment.security.level property, the upgrade to HIGH is not done. The property can be manually upgraded using the Java Control Panel.

Area: Deploy / Plug-In 

It takes a long time to load app after accepting a multi-click dialog caused by "the certificate revocation site cannot be accessed"

For sandbox app, a second certificate revocation check is always performed after accepting security dialog, ignoring that fact that user already accepted the certificate. If there are network connection problems, such as when a proxy is turned off, the revocation check can take a long time, before java.net.SocketTimeoutException is thrown.

Workaround:

User can disable certificate revocation checks by using Java Control Panel:

• Select tab Advanced
• Find the option named Performs certificate revocation checks on
• Set it to Do not check (not recommended)

Area: Deploy / Web Start 

Javaws cannot switch to offline application run mode if the application cannot be launched online.

The command javaws <jnlp_url> fails to launch the cached application if the system is offline, even if the application JNLP file has the <offline-allowed> element specified. As a workaround users can either:

• Launch Javaws explicitly with the command javaws -offline <jnlp_url>
• Launch the cached application using the Java Cache Viewer

Area: Core Libs / java.lang.reflect 

Type annotations on a class, or on a member of that class, get dropped if the class is redefined using, for example, JVMTI or the classes in java.lang.instrument.

1. Bug
2. 8025934

Area: Core Libs / java.lang.reflect 

The array returned from the Class.getMethods() method may include methods that are not members of the class. The array may include methods from superinterfaces that have a more specific match in a different superinterface.

1. Bug
2. 8029459

Area: Core Libs / java.lang.reflect 

The array returned from a call to the Class.getMethods() method may, in some scenarios, include default methods that are not members of the class. Specifically, default methods from superinterfaces that have a more specific method may be included.

1. Bug
2. 8029674

Area: Core Libs / java.net

On Windows platforms, the IPv4 stack needs to be configured in addition to the IPv6 stack, for the IPv6 stack to work. For more information on IPv6 configuration, see Networking IPv6 User Guide.

1. Bug
2. 8040229

Area: Core Services / Debugger 

Currently it is not possible to programmatically invoke default interface methods using the JDI API. The interface default methods are a new feature of JDK 8 and the JDI specification has not been updated to work with this feature yet.

1. Bug
2. 8031195

Area: Client Libs

It has been found that some Windows GDI functions don't support all types of Java heap memory allocation schemes. This problem can cause repaint issues and printing bugs. Affected JVM flags: -XX:+UseLargePages and -XX:+UseNUMAInterleaving. The problem can be worked around by turning off the listed flags.

See: https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used

1. Bug
2. 8240654

Area: Client Libs / java.swing 

On Mac OS X, the ComboBox control consumes the Esc and Enter keys. When the ComboBox in a dialog box has focus, the keyboard cannot be used to close the dialog box.

1. Bug
2. 8031485

Area: JavaFX / Swing Node 

The SwingNode class does not support High DPI displays.

1. Bug
2. RT-32597

Area: JavaFX / Packager Tool 

The JavaFX packager tool in some cases generates a valid .exe installer but an invalid .msi installer on Windows x64.

1. Bug
2. RT-28984

Area: JavaFX / Non-mouse traversal input 

Non-mouse traversal functionality does not work as expected on the non-editable ComboBox in the following cases:

• When a ComboBox is in focus and has a neighbor control on the right, pressing the Right arrow key causes the original ComboBox to lose focus, however the target ComboBox does not gain focus. The right arrow key must be pressed a second time for the target ComboBox to gain focus.
• When any ComboBox is selected, pressing the up arrow key or down arrow key shows that interactive mode is on when traverse mode is expected.

1. Bug
2. RT-33344

Area: JavaFX / Linux 

The Scene Builder has repaint issues on Linux when the machine has been activated after being suspended.

1. Bug
2. RT-25683

Area: Security Libs 

If a jar file is signed, but the signer's certificate includes a KeyUsage extension that does not allow code signing, jarsigner was designed to print out a warning but still treat the file as signed. In fact, because the KeyUsage check is performed inside the JarFile parsing, jarsigner now simply treats the file as unsigned with no warning.

Area: Security Libs / javax.crypto / Solaris

When using the OracleUcrypto provider for AES/GCM/NoPadding encryption, an unexpected IllegalBlockSizeException might be thrown on Solaris 11 and later releases.

The following workarounds are available:

• Disable the GCM implementation from the OracleUcrypto provider by adding the "Cipher.AES/GCM/NoPadding" string to the disabledServices section in its provider configuration file, for example, <java-home>/lib/security/ucrypto-solaris.cfg.
• Disable the OracleUCrypto provider, and use the SunJCE GCM implementation instead using one of the following methods. Be aware that this workaround disables all services provided by OracleUcrypto.
  • Statically: Edit the <java-home>/lib/security/java.security file.
  • Dynamically: Use the java.security.Security.removeProvider("OracleUcrypto") API.

1. Bug
2. 8031431

Area: Security Libs / javax.crypto / Solaris

Newer clients such as Mozilla's Firefox might try to negotiate TLS v1.2 connections using AEAD/GCM-based ciphers, such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. JDK 8-based servers such as Tomcat 8.0.3 might run into a known issue in the OracleUcrypto provider, in which a previous GCM state could be retried and the following exception thrown:

java.lang.IllegalStateException: Must use either different key or iv 
for GCM encryption

The following workarounds are available:

• Disable the GCM implementation from the OracleUcrypto provider by adding the "Cipher.AES/GCM/NoPadding" string to the disabledServices section in its provider configuration file, for example, <java-home>/lib/security/ucrypto-solaris.cfg.
• Disable the OracleUCrypto provider, and use the SunJCE GCM implementation instead using one of the following methods. Be aware that this workaround disables all services provided by OracleUcrypto.
  • Statically: Edit the <java-home>/lib/security/java.security file.
  • Dynamically: Use the java.security.Security.removeProvider("OracleUcrypto") API.

1. Bug
2. 8036970

Area: Security Libs / javax.net.ssl 

When using RSA client key exchange in SSL/TLS protocols, SunJSSE provider cannot work in FIPS 140 compliant mode. This issue does not impact the default mode of SunJSSE.

A straightforward workaround is to disable FIPS mode of SunJSSE provider.

An alternative workaround is to disable the use of RSA key exchange in SSL/TLS protocols. This issue only happens to RSA key exchange based SSL/TLS cipher suites. To workaround this issue, applications can use DHE/ECDHE cipher suites instead (for example, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, etc.). See JSSE Reference Guide for information about customizing SSL/TLS cipher suites.

Area: HotSpot / compiler 

With power of 2 values, Math.pow has reduced performance. Use code similar to the following example to work around the issue:

if (power == 2) {
 return x * x;
}
return Math.pow(x, power); 

1. Bug
2. 8029302

Area: Tools 

Localized man pages for the java command do not contain information about the deprecation of certain options that control some rarely used garbage collector combinations that were deprecated. The English man pages contain the relevant information. For more information about affected options, see http://openjdk.java.net/jeps/173.

1. Bug
2. 8030999

Area: Tools / javac 

ElementType.TYPE_USE is introduced in JDK 8 and should be considered a logical superset of ElementType.TYPE and ElementType.ANNOTATION_TYPE. However, the javac command does not currently recognize ElementType.TYPE_USE as a superset.

1. Bug
2. 8029017

Area: Tools / javac 

Due to a type inference specification change in JDK 8, programs similar to the following example are not accepted by the javac command:

abstract class A2<T>{
  abstract <S> S foo(S x, S y);
  abstract <S1> void baz(A2<S1> a);

   void bar(A2<Integer> y, A2<Long> x){
      baz(foo(x, y));
   }
}

1. Bug
2. 8030741

Area: Tools / javac 

Mixing lambda expressions and inner classes, similar to the following example, can cause the javac tool to crash.

public class Test {
    void m() {
        m1(()-> {
            new A(){
                public void m11() {}
            };
        });
 
    }
 
    void m1(Runnable r) {}
}

Note that this program compiles correctly if A is a known identifier.

1. Bug
2. 8030816

Area: Tools / javac 

An incorrect exception table is generated for code that has multiple catch statements inside a lambda. The following example shows the type of code that causes this behavior:

class LambdaWithMultiCatch {
  public static void main(String[] args) {
    Runnable r = () -> {
    try {
      throw new IOException();
    } catch(IOException | IllegalArgumentException e) {
      System.out.println("This code will generate a wrong exception table");
    }
   };
   r.run();
 }
}

The generated exception table for method main() contains the following information:

 Exception table:
   from to target type
      0 8 8 Class java/lang/Exception <--- neither IOException nor
                                      <--- IllegalArgumentException appears

Avoid using multiple catch statements inside lambda bodies until this issue is fixed.

1. Bug
2. 8036942

Area: Tools / launcher 

To overcome an incompatible change in VisualStudio 2010 with setargv.obj, the Java launcher uses its own argument parser/processor as outlined in the release note for 7146424 in the Java SE 7 Update 4 Release Notes.

A side effect of the above fix is that the escaping of quotes and spaces must be done according to the Windows specification. The following examples show the correct way to quote a command line containing spaces in a directory:

• "c:\Program Files\Java\jdk1.8.0\bin\java.exe" -cp "c:\Some Dir\" SomeMain

This example is the correct way to use the quotes. This is also how the Windows command interpreter (cmd.exe) auto-completes user commands and quotes arguments.

• c:\\"Program Files\"\Java\jdk1.8.0\bin\java.exe -cp "c:\Some Dir\" SomeMain
• c:\Progra~1\Java\jdk1.8.0\bin\java.exe -cp "c:\Some Dir\" SomeMain

This example is for short filenames for files that are not in the 8-dot-3 format obtained from dir /X.

1. Bug
2. 8030961

Area: Java DB 

An additional permission may be needed to bring up the Java DB network server. In particular, the startup scripts in <db/bin> may fail to boot the network server.

While attempting to boot, the network server may fail and raise the following error:

access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")

To fix this problem, you must bring up the network server with a security policy that includes the missing permission. Instead of booting the network server as:

java org.apache.derby.drda.NetworkServerControl start

boot the network server as follows:

java -Djava.security.manager -Djava.security.policy=${yourPolicyFile}
org.apache.derby.drda.NetworkServerControl start

where ${yourPolicyFile} is a file containing a customized version of the policy file described in the Java DB Admin Guide section titled Basic Network Server security policy. You must customize that generic policy file to fit your application. In addition, you must add the following permission to the permissions block granted to the ${derby.install.url}derbynet.jar codebase:

permission java.net.SocketPermission "localhost:${port}", "listen";

where ${port} should be replaced by the port number where the network server listens for incoming connection requests. By default, that is port 1527.

For more information on Java DB security policies, see the Java DB Admin Guide sections titled Network Server security and Running the Network Server under the security manager.

If you are using replication, a similar permission must be granted to the security policy for the slave server. Add the following permission to the ${derby.install.url}derby.jar codebase:

permission java.net.SocketPermission "localhost:${slavePort}", "listen";

where ${slavePort} should be replaced by the port number where the slave server listens for incoming connection requests (typically 4851). For more information on the security policy for the slave server, see the Java DB Server and Administration Guide section titled Replication and security.

1. Bug
2. 8290347

Area: XML / jaxp

Applications using the JDK XSLT transformer to convert stylesheets to Java objects can encounter the following exception:

Applications will encounter the above exception if the size of the XSL template is too large. It is recommended to split the XSL template into smaller templates. Alternatively, applications can override the JDK XSLT Transformer by providing third-party implementation JAR files in the class path.

Resolved Known Issues

The following list includes Known Issues from previous releases that have been resolved in JDK 8.

Area: Install 

[macosx] Scheduled AU - cannot auto update on Mac 10.9

On Mac OS 10.9, when a scheduled Java (auto) update is initiated, the installer may become unresponsive.

Area: HotSpot / gc 

Crashes due to failure to allocate large pages.

On Linux, failures when allocating large pages can lead to crashes. When running JDK 7u51 or later versions, the issue can be recognized in two ways:

• Before the crash happens, one or more lines similar to the following example will have been printed to the log:

  
  os::commit_memory(0x00000006b1600000, 352321536, 2097152, 0) failed;
  error='Cannot allocate memory' (errno=12); Cannot allocate large pages, 
  falling back to regular pages
  

• If a file named hs_err is generated, it will contain a line similar to the following example:

  
  Large page allocation failures have occurred 3 times
  

The problem can be avoided by running with large page support turned off, for example, by passing the "-XX:-UseLargePages" option to the java binary.