Java Troubleshooting（JDK8）

138 阅读 0 评论 0 点赞

Java Platform, Standard Edition Deployment Guide
Contents Previous Next

33 Troubleshooting

This topic provides troubleshooting tips to try if you encounter any problems deploying your Java or JavaFX applications.

This topic contains the following sections:

Running Applications
Development Process Issues
Runtime Issues

33.1 Running Applications

Use the following checklist if you have trouble running applications after they are packaged:

Verify that you have a supported environment.
Check the release notes for known issues.

If the tips in the following sections do not help to resolve the issue, then the following actions are suggested:

Ask experts in the Java and JavaFX Forums.
File a bug to JIRA.

Describe in detail what you are trying to do, and what exactly does not work as expected. If possible, share a test case to reproduce the problem. Be sure to include information about your environment and your Java and JavaFX versions.

33.2 Development Process Issues

Verify that you are using the latest version of the packaging tools.
javapackager command fails:
- Ensure that the JDK bin folder, where the javapackager tool is located, is on the PATH.
- Ensure that JAVA_HOME is set.
- On OS X, the problem could be due to simultaneous use of Apple's JDK 6 and Oracle's JDK 7 or JDK 8. To work around this issue, set JAVA_HOME and add it to the path:
  - export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
  - export PATH=$JAVA_HOME/bin:$PATH
Packaging self-contained applications:
- If the package format you are trying to build depends on third-party tools, then make sure they are available on the PATH.
- Set verbose="true" in the <fx:deploy> task or pass "-v" to javapackager to get verbose build output.
- Set the environment variable JAVAFX_ANT_DEBUG to true to get additional details and keep intermediate build artifacts.
- If drop-in custom resources are not used, then verify that the JavaFX Ant task definitions are loaded with the correct classpath, typically with "." at the beginning. See Section 10.3, "Using JavaFX Ant Tasks."
Packaging self-contained applications on remote systems:
- If packaging tools are executed on a remote system (for example, Jenkins, Hudson, and other build systems) to produce the artifact, then it is important to have same user logged on a desktop system. If using the same user login is not possible, you can create a custom .dmg bundle using the following steps:
1. Create a .dmg image from manual build
2. Convert the .dmg file to a read-write form
3. Remove the content of you application folder, but keep the top level app directory
4. Add the dmg to the build
5. At the build time, mount it, copy .app contents to the image, then convert .dmg to a compressed read only form
NetBeans issues:
- Ensure you are using NetBeans 7.2 or later. To use JavaFX features, you need NetBeans 8.0 or later.
- If a Clean and Build fails to build the sample application or double-clicking some or all of the files results in an error, check that the JavaFX platform is enabled properly in NetBeans.
- To get more insight into the build process, enable verbose output by clicking the Tools icon in the build output window.
- To build self-contained applications, ensure that the required third-party tools are added to the PATH before you start NetBeans. See Section 7.4, "Installable Packages."

33.3 Runtime Issues

Basic checklist:

Verify that you have the latest version of Java installed (Java 8 or later).
For JavaFX applictions, before trying to troubleshoot your application, ensure the JavaFX samples run properly.
1. Download the JavaFX samples zip file.
2. Double-click the JAR file, the JNLP file, and the HTML file for at least one sample to ensure it runs correctly.
Validate that the java process is using your JRE installed location.
If you have a 64-bit system, you might be using either a 32 -or 64-bit version of Java. The best way to avoid problems caused by unexpected use of an older version of the JRE is to keep both 32- and 64-bit versions of Java up to date.

33.3.1 Standalone Execution

Run the same application from the command line as
java -jar MyApp.jar

This way you can see actual exceptions and trace messages, if any.
Pass -Djavafx.verbose=true to enable verbose output from the embedded launcher.
If your application starts slowly, then it could be due to network configuration. Try disabling the autoproxy configuration by passing -Djavafx.autoproxy.disable=true to see if it helps.

33.3.2 Self-Contained Applications

Run the native launcher from the console window to see trace messages and so on.
- On OS X, the launcher is MyApp.app/Contents/MacOS/JavaAppLauncher
- On Windows, you must pass the /Debug option to the launcher to open a window to see the trace messages.
You can pass debug options to your application with <fx:jvmarg> or <fx:property> at package time. Examples:
- To list all classes loaded, add the following to your <fx:deploy> task:
```
<fx:jvmarg value="-verbose:class"/>
```
- To debug:
```
<fx:jvmarg value="-agentlib:jdwp=transport=
    dt_socket,address=4000,server=y,suspend=y"/> 
```
  This instructs the agent to suspend after the JVM is initialized and wait for a debugger to connect on port 4000.
- To profile in Netbeans 7.2 on Mac OS X:
```
<fx:jvmarg value="-agentpath:/Applications/NetBeans/NetBeans
    7.2.app/Contents/Resources/NetBeans/profiler/lib/deployed/jdk16/
    mac/libprofilerinterface.jnilib=/Applications/NetBeans/NetBeans 
    7.2.app/Contents/Resources/NetBeans/profiler/lib,5140"/>
```
  This will stop the application after it is loaded until the profiler is attached. Consult the documentation on your profiler for exact values to pass.
Review the tips for troubleshooting standalone applications.
OS X: if other users cannot run your application, then ensure it is signed. See Section 7.3.5.1, "OS X.")
- To validate signing, use
```
codesign -v -d --verbose=4 MyApp.app
```

33.3.3 Web Start

If you rebuilt the application but do not see changes in the runtime, exit the application and use the following steps to clear the Java cache:
1. Run javaws -viewer from the command line, or open Java Control Panel manually (for example, by choosing Java in Windows Control Panel).
2. In the Java Control Panel, in the Temporary Internet Files section, click Settings, then click Delete Files.
3. Select Cached Applications and Applets and click OK.
If the application fails with an error, then check the process list to see what java process is actually used to run it. Ensure it comes from the correct location.
Consult the Java SE Troubleshooting Guide for tips on how to troubleshoot generic Java Web Start problems.

33.3.4 Applications Embedded in the Browser

Validate your version of Java at http://java.com.
Check the JavaScript error console for errors.
Try a different browser. See if the problem is common to the system or is browser-specific.

Remember that not all browsers are supported. For example, Chrome on OS X is not supported.
Find out the architecture of the browser you are using. Most of the browsers are 32-bit even if you are using a 64-bit platform.

Install/upgrade 32-bit Java and JavaFX runtimes to resolve the problem.
Review the browser's list of installed plugins.
- There should be only one Java Plugin in the list. For JavaFX 2.2 and Java 7 update 6 the correct plugin is version 10.6.*.
- On Windows, there should be only one Deployment Toolkit plugin, and it should be the same or a higher version than that of the Java Plugin.
Safari 6 on OS X if the file:// protocol is used:
- According to default Safari 6 policy, "no file:// is allowed to open any local resources that might run code". This means that Java and JavaFX applications will not load and appear to get stuck on the spinning wheel.
- Run a local web server or disable local file restrictions. To do this, enable the Develop menu, then check the Disable Local File Restrictions menu item.
See the Java SE Troubleshooting Guide for tips on how to troubleshoot generic Java plug-in problems.

33.3.5 Disabling the Autoproxy Configuration in the Code

By default, JavaFX application proxy settings are taken from the current browser if the application is embedded into a web page, or system proxy settings are used. Sometimes SOCKS proxy settings, specified in the System.setProxy are ignored.

If you need to disable the automatic proxy configuration in the application, specify a JavaFX-Feature-Proxy manifest entry in the fx:jar with the None as a value as in the following example.

<manifest>
    <attribute name="JavaFX-Feature-Proxy" value="None"/>
 </manifest>

After you enter the JavaFX-Feature-Proxy manifest, the network stack will not be initialized prior to application code gets executed and you can set socks properties in the code.

Contents Previous Next