Print-friendly Version

Release Notes Java 2 SDK, Standard Edition Version 1.3 for Linux

For a list of changes in J2SE 1.3.0_02, see the J2SE 1.3.0_02 Release Notes.

Contents

Overview
Superuser - Potential Problem
Remote Displays Not Supported by Java Plug-in
Virtual Machines and Red Hat 7.0
Java -help Message Not Complete
Delete Key Does Not Work for JPasswordField
Input Method Support
Man Pages Available
For Users of SuSE Kernel
Linux SMP System Bug
Limitation for Multiscreen Support
RMI-IIOP and Java IDL
Drag and Drop
Accessibility
Swing
Security
Networking
Java Plug-in
Issues Regarding Support for Japanese
Chinese Not Supported
Year 2000 Compliance

See the following document on the Java Developer Connection web site.

Java Technology on the Linux Platform

Version 1.3.0 is a upgrade release of the Java 2 SDK and Java 2 Runtime Environment containing new functionality and APIs, performance enhancements and bug fixes in many areas. For a comprehensive summary of new features and enhancements in version 1.3.0 of the Java 2 SDK, see the

New Features and Enhancements

section of the documentation.

In addition to bug fixes in the virtual machine and class libraries, this release provides new support for input methods and includes man pages for the SDK tools.

Behavior in comformance with the API specification is not guaranteed while running as superuser on any version of Linux whose kernel was compiled with the CONFIG_IP_TRANSPARENT_PROXY option. The default kernel shipped with the RedHat 6.2 distribution is compiled with this option. To avoid incompatibilities associated with this problem, either do not use the Java platform while superuser or else upgrade to a Linux operating system whose kernel was not compiled with the CONFIG_IP_TRANSPARENT_PROXY option. Red Hat 7.1 ships with the version 2.4 kernel which does not have this problem.

Remote Displays Not Supported

J2SE 1.3.0 supports KDE and KWM window managers in conjunction with displays set to a local Linux host. However, the KDE window manager is not supported by Java Plug-in 1.3.0 when the display is set to a remote Linux host. When using Java Plug-in, the configuration of KDE window manager and remote display can result in runtime errors when using during creation of GUI objects. This issue is being tracked as bug 4380775.

Virtual Machines and Red Hat 7.0

J2SE 1.3 has two implementations of the Java virtual machine (VM):

• The Java HotSpot Client VM, tuned for fast startup time.
• The Java HotSpot Server VM, tuned for peak operating speed for long-running server applications.

See the J2SE 1.3 documentation for more information.

The Java 2 SDK 1.3 also contains the now-obsolete Classic VM, which can be invoked by using the -classic command-line option (java -classic MyApp). However, the Classic VM will not work with Red Hat 7.0 due to a bug in the glibc library. We believe this bug is fixed in glibc-2.1.94. This problem is being tracked as bug 4375774.

The Classic VM is not included as part of the Java 2 Runtime Environment 1.3.

Running the Java application launcher with the -help option (java -help) displays a help message that gives brief descriptions of available command-line options. However, the help message is incomplete in that it does not list all options. For a complete list of available options, see the man page for the Java application launcher or consult the Java application launcher's reference page in the J2SE documentation.

The main Delete key located in the middle key block does not work properly in JPasswordFields. You can workaround this problem by using the BackSpace key to delete characters. The Delete key in the numeric keypad works properly and can also be used to delete characters. This problem is being tracked as bug 4366978

Input Method Support

The Java 2 Runtime Environment on Linux lets the user select input methods using a user-configurable hot key. To define a hot key, set the following environment variables:

• JAVA_INPUT_METHOD_SELECTION_KEY

  
  Set to a key code as defined in the java.awt.event.KeyEvent class, e.g., VK_F4.

• JAVA_INPUT_METHOD_SELECTION_KEY_MODIFIERS

  
  Set to a combination of modifier masks as defined in the java.awt.event.InputEvent class, e.g., SHIFT_MASK. If there is more than one mask, the masks must be separated by a comma. Setting this variable is optional.

When the user presses the hot key combination, a pop up window appears,which contains a list of selectable input methods. There are no default values set for the environment variables, so there is no default hot key.

On the Windows and Solaris platforms, the Java runtime environment adds a "Select Input Method" menu item to the Window menu (on Motif) or the System menu (on Windows), which lets the user select an input method. However, Linux window managers do not support the addition of such a menu item; therefore the selection is initiated by a hot key. Note that this feature is implementation specific and likely to change in a future release.

J2SE 1.3 for Linux is tested and supported on the Red Hat 6.1 operating system. Other Linux platforms are not supported, and users may encounter problems when attempting to use J2SE 1.3 on other Linux systems.

For example, the SuSE 6.4 kernel has a stack/heap memory configuration that, in its default mode, is incompatible with the way the the Java virtual machine uses the stack, resuling in a virtual machine crash with a stack overflow. To avoid the crash, first change the contents of the heap-stack-gap file by running the following command:

echo 4 > /proc/sys/vm/heap-stack-gap

See bug report 4345034 for more information.

Linux SMP system bug 4343002 has the following symptoms. A race condition in the linuxthreads contained within glibc 2.1.2 can cause the VM to crash. The race condition that causes the crash occurs only rarely and is generally not reproducible. The crash results in an error message similar to the following:

# # An unexpected exception has been detected in native code outside the VM. # Program counter=0x40091598 # Problematic Thread: prio=1 tid=0x812ea40 nid=0x1c08 runnable #

Versions of the XFree86 X server prior to version 4.0 do not support multiscreen functionality. If you are using an XFree86 X server, you must have version 4.0 to support the new multiscreen functionality in the Java 2 Platform. However, XFree86 4.0 is a recent release, and the Java 2 SDK on XFree86 4.0 has not been thoroughly tested.

The following comments pertain to RMI-IIOP functionality in 1.3.

• The Java ORB shipped with Java 2 SDK, Standard Edition (J2SE) v 1.3 lacks support for evolutionary changes to serializable classes as specified by the Java Serialization Specification. This is a known functionality bug in the Java ORB shipped with 1.3. As a manifestation of this functionality bug, the Java ORB in J2SE 1.3 will fail to pass certain Java Platform classes from J2SE 1.2 to J2SE 1.3 and vice versa.

  The following set of classes have evolved from J2SE 1.2.2 to J2SE 1.3.

  javax.swing.AbstractAction
  javax.swing.JTable
  javax.swing.text.html.HTML$UnknownTag
  sun.awt.font.FontDesignMetrics
  

  These classes did not have a writeObject method in J2SE 1.2.2, but do have it in J2SE 1.3.

  The interoperability failures occur when a client passing these data types is executed using Java 2 Enterprise Edition Reference Implemementation or the RMI-IIOP standard Edition over J2SE 1.2 and tries to communicate with a server executing on J2SE 1.3 or vice versa.

  For application programmers to workaround this bug, it is recommended that they define a writeObject method in their serializable class. The specification of the writeObject method causes the serializable class to be custom marshalable using the Java ORB, and will help maintain compatability when running on future versions of the Java platform.

• When using the RMI Stub Compiler (the rmic utility) with the -iiop option to generate stubs for the IIOP protocol, bug 4318477 causes it to ignore JAR files specified with the -classpath option. A workaround for this bug is to take the class files out of the JAR file. The rmic compiler will load the loose class files correctly. This bug will be fixed in the next maintenance release of the Java 2 SDK. Documentation for the RMI Stub Compiler can be found in the SDK's Tools and Utilities documentation.

• When writing code in OMG IDL, do not use an interface name as the name of a module. Doing so runs the risk of getting inconsistent results when compiling with tools from different vendors, thereby jeopardizing the code's portability. For example, code containing the same names could be compiled with the IDL to Java compiler from Sun Microsystems and get one result. The same code compiled with another vendor's IDL to Java compiler could produce a different result.

The Java platform does not support 16-color displays. If you see problems drawing graphics and GUI components on a 16-color display, try changing the color depth to 256 color mode or higher.

Two new methods have been added to class java.awt.datatransfer.DataFlavor:

• selectBestTextFlavor(DataFlavor[]) - This method selects the most appropriate flavor from the input DataFlavor array. The method compares the flavors in the array with encodings supported by the Java 2 Platform, including comparisons of mimetypes on the basis of charset attributes, and returns the flavor that is the best match.
• getReaderForText(Transferable) - This method gets the reader that is appropriate for the flavor selected by the selectBestTextFlavor method.

Without the use of the new methods, unicode-encoded text will not be dragged onto some native-application documents correctly (an extra character will be left at the beginning of the text). The new methods will deliver ISO8859-1 text instead of unicode text to avoid this problem.

AWT and Swing components have inner classes that implement the Java Accessibility API and provide accessibility support appropriate for the components. However, accessibility support for the following AWT classes is not completely implemented in this release:

java.awt.TextComponent
java.awt.Menu
java.awt.MenuItem
java.awt.List

Full accessibility support for all components will be implemented in a future release of the Java 2 platform.

The method Component.getListeners does not work for Swing interfaces AncestorListener and VetoableChangeListener. For those interfaces, getListeners will return a zero-length array regardless of how many listeners are actually registered. This problem is being tracked in bug reports 4290704 and 4257538.

The following security-related issues pertain to this release.

The jarsigner utility can verify files signed by the Netscape SignTool 1.3 if the code-signing certificates are not self-signed. Note: One can get official Netscape code-signing certificates from VeriSign^TM. Those certificates are issued by VeriSign. They are not self-signed.

The Netscape SignTool 1.3 does not put certificates in the signature file if the code-signing certificate is self-signed, and jarsigner cannot verify a signed JAR file if the signature file doesn't contain the signer's certificate. Note: The code-signing certificate generated by the SignTool 1.3 itself is just for tesing, and it is self-signed. It is a known issue that the jarsigner cannot verify a JAR file signed by the Netscape SignTool 1.3 if the code-signing certificate is a self-signed testing certificate.

In the Java 2 SDK, application classes are loaded by an actual ClassLoader instance. This makes it possible for application classes to use installed extensions and also separates the application class path, which is specified by the user, from the bootstrap class path, which is fixed and normally should not be modified by the user. The -Xbootclasspath option can be used to override the boostrap class path if necessary.

However, this means that in the Java 2 SDK, application classes no longer have all permissions by default. Instead, they are granted permissions based on the system's configured security policy. This may cause some applications that write their own security code based on the original security model in 1.0/1.1 to throw an exception and not start in the Java 2 SDK. .

The following notes summarize issues related to security policies and signing.

• The default security policy implementation used by the Java 2 platform is specified by the policy.provider property in the Java security properties file, jre/lib/security/java.security. If you specify a non-default security policy implementation, you must put your new, non-default security properties class file on the bootclasspath. You can do so by using the -Xbootclasspath command-line option. See the Java application launcher reference page for information on this option. This will cause the policy file to be loaded by the bootstrap class loader. If the new default policy file is placed elsewhere, such as on the class path or in an extension, it will not be picked up and the default policy provided in sun.security.provider.PolicyFile will be used instead.

• Beginning with version 1.2.2, the Java 2 SDK uses a new class-loading mechanism. Under the new class loader, if any class file belonging to a package in a Jar file is signed, all class files belonging to the same package must have been signed by the same signers. It is no longer possible to use a Jar file in which some classes of a package are signed and others are unsigned or signed by a different signer. Jar files may still contain packages that are unsigned. However, if any packages contain signed classes, all class files of that package must be signed by the same signer. Existing Jar files that don't meet this criterion will not be usable with this version of the Java 2 Platform.

The keytool tool currently can import or print a Base64-encoded certificate from a file only if the file is terminated by a newline (linefeed). If there is no linefeed at the end of the certificate file and you try to import or print the certificate, you will get an "Unsupported encoding" CertificateException or a keytool error message such as "Failed to parse input" or "Input not an X.509 certificate."

If you get such a message or exception, perhaps the problem is a missing terminating linefeed. One reason this may occur is that sometimes a certificate reply from a Certificate Authority (in response to a Certificate Signing Request) does not contain a terminating linefeed.

In UNIX, you can determine whether or not a file has a terminating linefeed by executing the following command:

    od -xc <certificate_name>

where <certificate_name> is the name of the file containing the certificate. For example, if the file is named mycert the command would be

    od -xc mycert

If the resulting output contains a "\n" (without the quotes) at the very end, there is already a linefeed at the end. If not, you can add one.

If you are unsure whether or not the certificate file contains a terminating linefeed, you can simply add one per the following paragraph (having extras never hurts) and retry the -import or -printcert command. If the command now works, the problem was the missing linefeed. If you still get an error, there is a different problem with your certificate.

To add a linefeed to the end of a Base64-encoded certificate file, open the file in any text editor, place your cursor at the very end of the file, and add a linefeed (or carriage return linefeed), for example by simply pressing the Enter key on your keyboard.

Networking

This release has the following known bugs and limitations in the networking API:

• The HTML 4.0 specification recommends that non-ASCII characters in Uniform Resource Identifiers (URIs) should be encoded in one or more UTF-8 bytes. Many existing CGI scripts handle non-ASCII characters by using bytes from the encoding in which a document is received. However, classes URLEncoder and URLDecoder do not support either of these methods of handling non-ASCII characters in URIs. Instead, these classes substitute one or more bytes for the characters as defined in the underlying platform's default encoding. This is bug 4257115.

• A call to method HttpURLConnection.getResponseCode on the client can cause the virtual machine to crash when there are extra CRs in the HTTP header field sent by a Win98 or WinNT server. This is bug 4258697.

Java Plug-in

Version 1.3 of the Java Plug-in product supports only the Java 2 Platform. It will not work in conjunction with JDK 1.1.x software. Those who desire to use the plug-in with a 1.1.x version of the Java platform should use a pre-1.3 version of the Java Plug-in product.

The following are some limitations of the Java Plug-in technology in this release.

• A bug will cause a browser to hang if the command-line swing -Djava.security-debug=all is set in the Plug-in control panel.

• When HTTPS is used in Netscape Navigator, server response headers are not available in java.net.URLConnection.

• Use of 1.3's new applet caching support for HTTPS requires the additional parameter "cache_version" in the EMBED/OBJECT tag to make it work. For example,

  <PARAM NAME="cache_version" VALUE="1.2.1.0">
  

  where cache_version is in the form of X.X.X.X where X could be 0 to F in Hex. If the version number is larger than the one installed, the JAR will be downloaded.

• To run Java Plug-in HTML Converter, launch it from the command line as follows:

  java -jar HTMLConverter.jar
  

• Modal dialog are not completely modal. Users will still be able to click on the parent window and perform action in Java Plug-in.

Issues Regarding Support for Japanese

For general information about Japanese support on the Java 2 SDK, see Japan Localization. The following notes pertain to using input methods in this release.

• Bug 4300209 concerns a problem with input of Japanese characters when using a Kana-kanji root window and a passive client window on RedHat6.1J. When Japanese characters are input and committed in the root window, they don't appear in the client window until the client window gets focus. When the client window gets focus, words will appear in the client in the reverse order that they were committed in the root window. This problem has not been noted on RedHat 6.1J_upgrade or RedHat 6.2.

  Bug 4351215 is another problem with input methods in which InputMethodWindows improperly gets activated for keyboard input when it is created, leading to focus problems that prevent input methods from working.

  Workaround: To avoid these problems, set the the KWM focus policy to "(old) focus-follows-mouse" in the KDE Control Center.

• When the Red Hat 6.1J-update operating system starts, due to the setting of Japanese locale, it fails to bring up the input-method server kinput2 in the background automatically even when it is configured to do so by default. If the input-method server is not running, system errors will occur when a Java application attempts to use input methods. To use the J2SE 1.3 in conjunction with Red Hat 6.1J-update, you must manually start the input-method server. This problem has not been noted with other versions of the Red Hat operating system.

Chinese Not Supported

J2SE 1.3 for Linux is supported on the Red Hat 6.1 operating system. However, no version of Red Hat is available for the Chinese market. J2SE 1.3 for Linux may work in the Chinese locale on operating systems other than Red Hat, but Sun does not test or support J2SE 1.3 on other operating systems. This issue is being tracked as bug 4339494.

Year 2000 Compliance

For information about Year 2000 Compliance, see the Year 2000 Compliant Product List.