This section describes other issues such as, splash screen issues, pop up menu issues, and background color inheritance with AWT and provides information for troubleshooting them. In particular, it contains the following subsections:
This section describes some issues that can arise with the splash screen in AWT.
Issue 1 - The user specified a JAR file with an appropriate MANIFEST.MF in -classpath, but the splash screen does not work.
Solution: See solution to the next issue.
Issue 2 - It is not clear which of several JAR files in an application should contain the splash screen image.
Solution: The splash screen image will be picked from a JAR file only if the file is used with the -jar command-line option. This JAR file should contain both the "SplashScreen-Image" manifest option and the image file. JAR files in -classpath will never be checked for splash screens in MANIFEST.MF. If you do not use -jar, you can still use -splash to specify the splash screen image in the command line.
Issue 3 - Translucent PNG splash screens do not work on Oracle Solaris and Linux operating systems.
Solution: This is a native limitation of X11. On Oracle Solaris and Linux operating systems, the alpha channel of a translucent image will be compared with 50% threshold. Alpha values above 0.5 will make opaque pixels and pixels with alpha below 0.5 will be completely transparent. Translucency support might improve in future versions of Java SE.
With the Java SE 6 release on Windows 98, the method TrayIcon.displayMessage() is not supported because the native service to display a balloon is not supported on Windows 98.
If a SecurityManager is installed, the value of AWTPermission must be set to accessSystemTray in order to create a TrayIcon object.
In the JPopupMenu.setInvoker() method, the invoker is the component in which the popup menu is to be displayed. If this property is set to null, the popup menu does not function correctly.
The solution is to set the popup's invoker to itself.
Many AWT components use their own defaults for background and foreground colors instead of using the colors of their parents.
This behavior is platform-dependent: the same component can behave differently on different platforms. In addition, some components use the default value for one of the background or foreground colors, but take the value from the parent for another color.
To ensure the consistency of your application on every platform, use explicit color assignment (both foreground and background) for every component or container.
The AWT container has a size limitation. On most platforms, this limit is 32767 pixels. This means that, for example, if the canvas objects are 25 pixels high, a Java AWT panel cannot display more than 1310 objects.
Unfortunately there is no way to change this limit, neither with Java code nor with native code. The limit depends on what data type the operating system uses to store a widget size. For example, the Windows 2000/XP operating system and the Linux X operating system use integer type and are therefore limited to the maximum size of an integer. Other operating systems might use different types, such as long, and in this case the limit could be higher.
For more information, refer to the documentation for your platform.
The following are examples of workarounds for this limit that might be helpful:
Display components page by page.
Use tabs to display a few components at a time.
Certain graphical user interface (GUI) actions require grabbing all the input events in order to determine when the action should terminate (for example, navigating popup menus). While the grab is active, no other applications receive input events. If a Java application is being debugged, and a breakpoint is reached while the grab has been active, the operating system appears to hang. This happens because the Java application holding the grab is stopped by the debugger and cannot process any input events, and other applications simply do not receive the events due to the installed grab. In order to allow debugging such applications, the following system property should be set when running the application from the debugger:
-Dsun.awt.disablegrab=true
This effectively turns off setting the grab, and as such does not hang the system. However, with this option set, in some cases this may lead to inability to terminate a GUI actions that would normally be terminated. For example, popup menus may not be dismissed when clicking a window's title bar.
Due to restrictions enforced by third-party software (in particular, by window managers such as the Metacity), the toFront()/toBack() methods may not always work as expected and cause the window to not change its stacking order in relation to other top-level windows. More details are available in the CR 6472274.
If an application ultimately wants to bring a window to top, it can try to workaround the issue by calling Window.setAlwaysOnTop(true) to temporarily make the window always stay on top and then calling setAlwaysOnTop(false) to reset the "always on top" state.
|
Note: This workaround is not guaranteed to always work because window managers can enforce more restrictions in the future. Also, the setting a window to "always on top" is available to trusted applications only. An unsigned applet or an unsigned Web Start application running in a sandbox cannot use this API, and thus is unable to work around the issue.However, native applications experience similar issues, and as such this peculiarity makes Java applications behave similar to native applications. Therefore this issue cannot really be considered a bug. |
