Java Platform, Standard Edition Troubleshooting Guide
Contents    Previous    Next

16.2 Troubleshoot Applets

For modern browsers which support tabs, each tab might be a separate browser process. If a Java applet is embedded in a browser page and the next generation plugin is being used, usually the process associated with the browser tab creates a JVM within the process (browser VM). The browser VM will create another JVM process (client VM) which will run the applet and manage the applet's life cycle. The client VM is a Java process (java.exe on Windows and java on Oracle Solaris/Linux platforms).

The following are some problems with Applets and troubleshooting techniques.

16.2.1 Plugin Cheat Sheet for Applet Start

If your applet does not start, make sure to enable tracing and the Java console as explained previously. Then use hits below to find reason why applet does not work.

Do you get a trace file generated or see the Java console?

    • No, I don't get a trace file

      Check if Java technology is detected, see

      • Yes

        Look at JVM browser issues from

      • No

        It is likely to be a configuration issue. See for common configuration problems and if it does not help, look at JVM browser issues from

    • Yes, I have a trace file

      It is unlikely to be a configuration issue (unless you have the new generation plugin disabled). The problem is likely to be specific to this applet. Try to launch some other applets to confirm. Look at JVM client issues from

16.2.2 Browser or Java Process Crash

A crash could be caused by a platform or application issue.

Typically, if a crash happens in the JVM then there should be hs_err_*log file created in the current working directory (on Windows it is often placed on the desktop). It is the same crash report file as for standalone applications. For details about the report file, see Appendix A.

If you can spot native libraries loaded from the deployment cache directory, especially if you see code from these libraries in the crash stack, it is very likely to be a bug in the application.

Otherwise it is a JRE bug and needs to be reported to Bug Database.

The following are two scenarios to consider for a crash by platform or application issue.

  • JVM browser issues: Get more details about a JVM running in the browser process. Set the following two environment variables before starting the browser:

    JPI_PLUGIN2_DEBUG=1
    JPI_PLUGIN2_VERBOSE=1
    

    On Windows, there should be a command window associated with the browser process. All browser VM debug output goes into the command window. Check to see if any exceptions are visible there. A Java thread dump can be obtained by using the Control+Break key sequence on the command window.

    On Oracle Solaris or Linux platforms, after setting the above variables, start the browser from the same session. All browser VM debug output goes into the terminal window. To get a Java thread dump, on a separate terminal, use kill -3 pid or kill -SIGQUIT pid, where pid is the process id of the browser process.

    There are "heartbeat" messages sent between the client VM and browser VM. The "heartbeat" messages can be turned off by setting the JPI_PLUGIN2_NO_HEARTBEAT environment variable to 1. This will help isolate whether the problem is related to the "heartbeat".

    If the log is not opening and environment variables are set in the browser process, then it is likely that the JRE is not installed correctly or Java is disabled. Check for configuration errors and try to reinstall the JRE if nothing else helps.

  • JVM client issues: Check the latest trace file for ideas.

    Note: The same client JVM may be shared between multiple applets. Sometimes intermittent failures happen because the shared JVM does not have enough resources available (for example, heap size). In that case, a page reload often helps to resolve the problem.

    If application fails with an Out of memory error, the heap size needs to be increased. This can be done in the application deployment descriptor (JNLP file) or in the Java Control Panel using Runtime Parameters for JRE in use.

    If an application is signed and the user declined a security dialog, this may cause application failure. The decision made by the user is remembered until the JVM is restarted. To see the security dialog again, the user may need to restart the browser.

    Note: An applet can be deployed to reduce the risk of being affected by other applets and tailor execution environment for the applet's needs. See Applet Deployment in the JDK documentation. In particular, consider using the separate_jvm parameter argument.

16.2.3 Unresponsive Web page

The following are scenarios that could cause an unresponsive web page.

Contents    Previous    Next

Copyright © 1993, 2017, Oracle and/or its affiliates. All rights reserved.