Printable Page

Release Notes Java 2 SDK, Standard Edition Version 1.4.2

Introduction

OS & Hardware Platforms

Solaris 2.6 Operating Environment Not Supported

Linux Notes

Virtual Machine

HotSpot VMs

Core Libraries

Networking

New I/O (NIO)

Security

Internationalization

JAXP

Platform Time Zone Detection on Microsoft Windows

Directories on Windows XP with Samba Mounted Drives

Serialization of Throwable

Floating-Point Exceptions

Integration Libraries

CORBA, Java IDL, and Java RMI-IIOP

Java Naming and Directory Interface API

User Interface

Java Sound Technology

Java 2D Technology

Fonts for Japanese Locale

Input Methods

AWT

Swing

Deployment

Applets

Java Plug-in Technology

Java Web Start Technology

Java Update

Server VM

Tools and Tool Architecture

Java Platform Debugger Architecture

Java Virtual Machine Profiler Interface

Java Compiler (javac)

Javadoc Tool

Jarsigner Tool

Tool Compatibility

Sun ONE Studio (formerly Forte for Java) and NetBeans

libsafe Library

The Java 2 SDK, Standard Edition, v1.4.2 is an upgrade release of the Java platform. It contains new features and enhancements in many functional areas.

This document summarizes known bugs, workarounds, and other important issues to be aware of in this release. For further information, refer to the following links:

Enhancements and Changes in J2SE 1.4.2 Platform

Bug Fixes in the Initial 1.4.2 Release

Bug Fixes in Subsequent 1.4.2 Update Release Versions

Compatibility between J2SE 1.4.2 and Previous Releases

To determine the version number of your J2SE software, use the following command:

java -version

For platform-dependent issues and bugs in particular J2SE technologies, search this page for the platform name ("Windows", "Linux", or "Solaris"). Also see J2SE enhancements and changes.

The Solaris 2.6 Operating Environment is not a supported platform for J2SE 1.4.1 or 1.4.2. One ramification of this is that support for Motif 1.2 in the J2SE 1.4.1 or 1.4.2 platform has been dropped.

The following notes apply to use of this release on Linux platforms.

• Linux kernels for Itanium prior to 2.4.20 have serious virtual memory bugs. These early kernels are the standard kernels that come with RedHat for Itanium. Java applications running on these kernels, especially on multi-processor machines, will likely experience random segment faults and in general will be unreliable. Please verify that you have the 2.4.20 kernel or a later one installed by using the 'uname -a' command. You can obtain an updated kernel for RedHat Advanced Server from either HP or RedHat.

• The following problems can occur intermittently on multi-processor systems. No workaround exists for these problems; the Linux system must be upgraded to eliminate them. However, using only one processor on an Itanium system will avoid these problems.
  • A glibc 2.2 bug in versions 2.2.4 and earlier can cause the virtual machine to hang on exit when there is only one remaining active thread. This problem can affect Linux platforms such as Red Hat 7.0, 7.1, and 7.2 that have glibc versions 2.2 to 2.2.4. The problem is fixed in glibc 2.2.5. See bug report 4656697.
  • The Linux 2.4 SMP kernel sometimes issues duplicate PIDs, which can lead to anything from network errors to crashes. This problem is fixed in kernel 2.4.18. See bug reports 4650839 and 4682743.
  • An apparent bug in the Linux 2.4.9 kernel can sometimes cause an application running on the Java platform to occupy essentially all CPU resources, causing the application to hang. This problem is being tracked in bug report 4701394.

• 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.

• Because Red Hat 7.* on Japanese does not have a TrueType font for JIS X 0201 by default, the Japanese font properties file, font.properties.ja, does not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font and modify the font.properties.ja file accordingly.

See also the Known Problems section of the Linux Installation Notes.

The following notes pertain to the Java HotSpot virtual machines (VMs) in this release. Also see Virtual Machine changes and enhancmenets.

• Beginning with J2SE 1.4.1, the Java HotSpot Server VM does not support operation on chips with SPARC^® v8 architecture. The SPARCstation^® family of processors, includng the SPARCstation Workstation, SPARCstation Classic, SPARCstation 2, SPARCstation 4, SPARCstation 5, SPARCstation 10, SPARCstation 20, and SPARCstation^® Voyager processors, are affected by this change . The Java HotSpot Client VM does support operation on SPARC v8 platforms. See the Java HotSpot VM documentation for information on the Server VM and Client VM.

  UltraSPARC^® processors and are not affected by this change.

• The Java HotSpot VM cannot expand its heap size if memory is completely allocated and no swap space is available. This can occur, for example, when several applications are running simultaneously. When this happens, the VM will exit after printing a message similar to the following.

     Exception java.lang.OutOfMemoryError: requested <size> bytes
  

  If you see this symptom, consider increasing the available swap space by allocating more of your disk for virtual memory and/or by limiting the number of applications you run simultaneously. You may also be able to avoid this problem by setting the command-line flags -Xmx and -Xms to the same value to prevent the VM from trying to expand the heap. Note that simply increasing the value of -Xmx will not help when no swap space is available.

  This issue is being tracked in bug 4697804.

• A bug in the HotSpot Server VM is related to its use of floating-point SSE instructions on IA32. The problem can occur on Pentium 3 or Pentium 4 machines if there is floating-point data held in registers when a JIT-compiled method is stopped during its execution for garbage collection. A program that experiences this problem could produce incorrect floating-point values. The problem can be avoided by specifying the command line option "-XX:UseSSE=0".

  This issue is being tracked in bug 4828693.

For information on known bugs and issues in networking functionality in this release, see the Networking Release Notes.

Also see Networking enhancements and changes.

• The following bug still exists in 1.4.2: Interruption of file-locking operations not completely implemented (bug 4460065).

• In J2SE 1.4.2. both ISO-2022-CN-CNS and ISO-2022-CN-GB encoding support have been removed from the java.nio.charset API. It is still possible to use java.io or java.lang.String APIs to encode an input stream or String into these target encodings. J2SE 1.4.1 previewed a limited (but incomplete) ISO-2022-CN-* java.nio charset support. The limitations included the inability to perform round-trip conversion, and specifically the existence of bug 4737614 "sun.nio.cs.ext.ISO2022_CN_CNS.newDecoder() returns null".

For changes in 1.4.2, please see NIO enhancements and changes. For information about NIO, see the main and supplemental NIO documentation.

The following notes pertain to issues with Security functionality in this release. For changes in 1.4.2, please see Security enhancements and changes.

• On Unix platforms, the Sun SecureRandom implementation uses /dev/random to seed itself, if available. This approach can improve the startup time of cryptographic applications considerably, but can also cause delays if the kernel entropy pool is empty. Solaris 8 users experiencing this problem should ensure that they have patch 112438-01 (SPARC) or 112439-01 (x86) installed. It is also possible to edit the <java.home>/lib/security/java.security file to specify a different URL for seeding. Note that if the URL cannot be opened, the implementation defaults to the pure-Java seeding implementation.
• A bug in Sun's JSSE v1.0, v1.0.1, and v1.0.2 caused SSL_DHE_DSS_* cipher suites to encode DSA signatures incorrectly when those signatures were used as part of a DSA server key exchange message.
  
  An interoperability system property controls which behavior is active. This property was introduced in Sun's JSSE 1.0.2 :

com.sun.net.ssl.dhKeyExchangeFix
true	Use the correct behavior. (Interoperable with JSSE 1.0.3)
false	Use the "broken" behavior. (Interoperable with JSSE 1.0, 1.0.1, and 1.0.2)

For backwards compatibility, the SunJSSE provider in J2SDK 1.4 and above also has this property; its default value is true.

Release	Default Behavior	Switch
J2SDK 1.4.0/above	correct	true
JSSE 1.0.3	correct	true
JSSE 1.0.2	broken	false
JSSE 1.0.1	broken	N/A
JSSE 1.0	broken	N/A

• When exchanging an RSA-based PreMasterSecret, RFC 2246-TLSv1 specifies that the PreMasterSecret message should contain the latest (newest) version supported by the client. Some SSL implementations send the current session's version number (incorrect), while others send the correct message. Most servers accept messages of either type.
  
  These differences are only an issue if the client requests a particular protocol version that the server doesn't support, and as a result the server requests a lower version number and then only accepts one message type (either correct or incorrect).
  
  Servers using the SunJSSE in J2SDK 1.4.1 or 1.4.2 accept messages of either type.
  
  Servers using the SunJSSE in J2SDK 1.4.0's JDK accepts the incorrect message type only. (Currently most popular Web browsers send the incorrect message.)
  
  Clients using the SunJSSE in J2SDK 1.4.1 or 1.4.2 can control which message type is active by using a system property:

com.sun.net.ssl.rsaPreMasterSecretFix
true	Use the correct RFC 2246 behavior
false	Use the incorrect behavior.

Given that most servers accept either message type, for interoperability with servers using SunJSSE in J2SDK 1.4.0 the current default is false:

Release	Default Behavior	Switch
J2SDK 1.4.1 and 1.4.2	incorrect	false
J2SDK 1.4.0	incorrect	N/A

See Internationalization enhancements and changes.

JAXP

Specification Version: 1.1
Reference Implementation (RI) Version: 1.1.4

• XML Parsing
• Security Issue
• XSLT Processing
  • The Interpreting XSLT Processor (Xalan)
  • Custom Class Loader Issue

XML Parsing

This release contains Apache Crimson-1.1.3+ (Crimson 1.1.3 final with controlled bug fixes).

Notes:

• There are two factory classes for making parsers pluggable. If you limit your application to the JAXP API in the javax.xml.parsers, org.xml.sax, and org.w3c.dom DOM Level 2 Core packages, you can use the library in a manner independent of the underlying implementing parser.
  

More information on known bugs and recent fixes can be found at the http://xml.apache.org/crimson/index.html.) For more information on the latest JAXP releases, see the JAXP FAQ.

Security Issue

While XML does not allow recursive entity definitions, it does permit nested entity definitions, which produces the potential for Denial of Service attacks on a server which accepts XML data from external sources. For example, a SOAP document like the following that has extremely deeply nested entity definitions can consume 100% of CPU time and a lot of memory in entity expansions.

<?xml version="1.0" encoding ="UTF-8"?>
 <!DOCTYPE foobar[
 <!ENTITY x100 "foobar">
 <!ENTITY  x99 "&x100;&x100;">
 <!ENTITY  x98 "&x99;&x99;">
 ...
 <!ENTITY   x2 "&x3;&x3;">
 <!ENTITY   x1 "&x2;&x2;">
 ]>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=...>
<SOAP-ENV:Body>
<ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">
<foobar xsi:type="xsd:string">&x1;</foobar>
</ns1:aaa>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

A system that doesn't take in external XML data need not be concerned with issue, but one that does can utilize one of the following safeguards to prevent the problem:

New system property to limit entity expansion

The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, no limit is set, because such a constraint would make the XML parser incompatible with the XML 1.0 specification.)

To set the entity expansion limit using the system property, use an option like the following on the java command line: -DentityExpansionLimit=100000

 

New parser property to disallow DTDs

The application can also set the http://apache.org/xml/features/disallow-doctype-decl parser property to true. A fatal error is then thrown if the incoming XML document contains a DOCTYPE declaration. (The default value for this property is false.) This property is typically useful for SOAP based applications where a SOAP message must not contain a Document Type Declaration.

XSLT Processing

The JAXP RI contains the interpreting transformation engine (Xalan). This section of the Release Notes describes:

• The Interpreting XSLT Processor (Xalan)

Note:
XSLT is supported by the JAXP transform package. See javax.xml.transform for details on accessing basic XSLT functionality in an implementation-independent manner.

The Interpreting XSLT Processor (Xalan)

This implementation includes xalan-j 2.4.1+ (Xalan version 2.4.1 with controlled bug fixes). More information can be found at the Apache Xalan site.

For the latest information on other known bugs and recent fixes, see the Xalan "Read Me" at http://xml.apache.org/xalan-j/readme.html.

Custom Class Loader Issue

A problem can occur when using a custom class loader with a transformation factory.

Transformation factories in JAXP always prefer the use of the "context class loader" to the use of the "system class loader". Thus, if an application uses a custom class loader, it may need to set the custom class loader as the context class loader for transformation factory to use it. Setting a custom class loader on the current thread can be done as follows:

try { Thread currentThread = Thread.currentThread(); currentThread.setContextClassLoader(customClassLoader); } catch (SecurityException e) { // ... }

If the application is multi-threaded, the custom class loader may need to be set in all threads (every time a new thread is created). A security exception is thrown if an application does not have permission to set the context class loader.

If you select a time zone that doesn't observe daylight saving time (e.g., Tokyo Standard Time) on an installation of a Microsoft Windows operating system, that selection may turn off the global system setting "Automatically adjust clock for daylight saving changes." Under this setting, the Java runtime detects the platform time zone in the GMT offset format (e.g., "GMT+09:00"), not as a time zone ID (e.g., "Asia/Tokyo"). To fix this installation problem, take the following steps after the installation (unless you intend to turn off the setting):

1. Open Date/Time in Control Panel.
2. On the Time Zone tab, choose a time zone that observes daylight saving time (e.g., "(GMT-08:00) Pacific Time (US & Canada); Tijuana"), select the "Automatically adjust clock for daylight saving changes" check box, and press the Apply button.
3. Choose your time zone back and press the OK button.

When using Windows XP (either 32 and 64-bit version) with Samba mounted drives, if the FileOutputStream(name) constructor is called and an empty directory with the same name exists, the directory will be deleted. This is not a bug in the J2SE platform, but it is being tracked as bug report 4693219.

Instances of java.lang.Throwable and subclasses (including all exceptions) serialized by Java 2 SDK 1.4.0, 1.4.1 or 1.4.2 cannot be deserialized by the Microsoft Windows JDK 1.1 implementation used by Internet Explorer browsers. Deserialization of such objects results in a ClassNotFoundException being thrown. This issue is described in bug report 4634165.

A processor's floating-point unit (FPU) usually has a control word which affects its behavior on certain floating-point events, such as overflow (generating a result too large to represent as a finite value), underflow (generating an especially small result), and divide by zero (e.g. 1.0/0.0). Java precisely defines the outcome of these events; Java uses the default returns values from the IEEE 754 floating-point standard. For example, overflow and divide by zero generate either positive or negative infinity. Other language environments may allow different outcomes from such events; for example, instead of returning an infinity, dividing by zero could generate an exception and stop the program. If a program with different floating-point semantics is called from a Java program, the called program may alter the FPU control word to implement its own semantics. However, such a called program should restore the FPU control word to its previous value. If the called program does not restore an altered FPU control word, and Java program could terminate with an improper floating-point exception after the external program exited. However, some commercial dlls are known not to restore the FPU control word to its previous value when they return to the calling thread. If your program terminates with a floating-point exception, you should consider this possibility as the source of the problem.

See bug 4644270 as an example of this issue.

The following bugs that pertain to CORBA, Java IDL, and Java RMI-IIOP technology were fixed for this release:

• Bug 4728756 fixed. In 1.4.1, CopyObject throws Marshalling exception for org.jdom.Document object. In 1.4.2, CopyObject does not throw Marshalling exception for org.jdom.Document object.

• Bug 4764130 fixed. In 1.4.1, ClientDelegate.addServiceContexts() was recording in the connection whether or not the SendingContextRuntime was sent or not. This may result in ClientDelegate.addServiceContexts() recording connections prematurely. In 1.4.2, recording of SendingContextRuntime is sent at the last possible moment.

• Bug 4771005 fixed. In 1.4.1, poor performance from the PIORB when client interceptors are installed. In 1.4.2, improved performance for PIORB when ClientRequestInterceptor is used.

• Bug 4730878 fixed. In 1.4.1, PortableRemoteObject.narrow(...) casting result to java.rmi.Remote. In 1.4.2, PortableRemoteObject.narrow(...) does not cast result to java.rmi.Remote.

See JNDI enhancements and changes.

See Java sound enhancements and changes.

• On Microsoft Windows platforms, Java 2D functionality in J2SE 1.4.1 and beyond is implemented using DirectDraw and Direct3D for various offscreen rendering functions. Bugs in some Direct3D drivers can cause a system crash (blue screen). If you encounter this problem while running a graphical application, consider updating your driver (the latest drivers for a particular card are usually available on the website of your computer, video card, or video chip manufacturer, such as http://www.nvidia.com or http://www.atitech.com).

  One example of a known problem is that using Direct3D on some small subset of Windows 2000 systems has been known to cause a system crash. You can also try launching your application with the following command-line flag set:

  -Dsun.java2d.d3d=false
  

  This forcibly disables our use of Direct3D and avoids any Direct3D-specific problems.

  You can also try the following flag:

  -Dsun.java2d.ddoffscreen=false
  

  This flag disables our use of DirectDraw and Direct3D for offscreen images (such as the Swing back buffer).

  If problems persists, try launching the application with this flag:

  -Dsun.java2d.noddraw=true
  

  This flag disables our use of DirectDraw and Direct3D completely and thus avoids any problems you may be seeing associated with our use of those APIs and their respective drivers on your system.

  For more information about performance-related flags, see Flags for Controlling Performance and Quality, a section in the High Performance Graphics white paper (also available in PDF format).

• Drawing many simple primitives to an accelerated offscreen surface may result in a JRE crash and corruption of the underlying graphics subsystem due to leakage of GDI resources. This problem is being tracked as bug 4766813. The workaround is to turn off offscreen acceleration:

  -Dsun.java2d.ddoffscreen=false
  

Because Red Hat 7.* on Japanese does not have a TrueType font for JIS X 0201 by default, the Japanese font properties file, font.properties.ja, does not include any definition for JIS X 0201. The workaround is to install a TrueType JIS X 0201 font and modify the font.properties.ja file accordingly.

Input Methods

See Input Methods enhancements and changes.

The following notes pertain to AWT functionality in this release. Also see AWT enhancements and changes.

• If you have installed English Visual C++ 6.0 onto a machine that also has an Asian edition of Windows NT installed, you may encounter strange artifacts when rendering Asian text in a TextArea component. You may also see this problem if you have installed Microsoft Exchange or Microsoft Office 97 onto a machine running an Asian Windows NT 4.0. Although this problem was reported on the Japanese version of Windows NT, it will probably occur on other non-Latin versions of NT as well, such as Chinese or Korean.

  The problem is caused when the installation of those programs replaces the Asian Riched32.dll file with the English version of the same file. The problem can be corrected by replacing Riched32.dll with the Asian version.

See the AWT release notes for more information.

• On newer Microsoft Windows platforms, Windows 2000 and Windows XP, mnemonics are normally hidden. On these platforms mnemonics can be made visible by pressing the alt key. When using Swing's Windows Look and Feel pressing alt may not make the mnemonics visible. You can workaround this with the following code:

  frame.getRootPane().getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(
       KeyStroke.getKeyStroke(KeyEvent.VK_ALT, Event.ALT_MASK, false),
       "repaint");
  

  See bug report 4736093 for more information.

• The text Components no longer register key bindings using a Keymap. They have been migrated completely to a combination of InputMap and ActionMap. You can continue to use Keymap, but Swing will no longer register bindings in a Keymap. See bug report 4682626.

See the Swing release notes for more information.

See Applets changes.

With the conventional applet format, use of an attribute named object with a PARAM element will cause an exception with the Sun VM: 'Either "code" or "object" should be specified, but not both.'. With the Microsoft VM, no exception will be thrown. This is a compatibility issue. To avoid the exception with the Sun VM, do not use an attribute named object with the PARAM element in an applet.

For Netscape 7, or Mozilla 1.1 or later, running on Microsoft Windows, the browser will always use Sun's latest jre—even if you have deselected the "Netscape 6 or later" or "Mozilla 1.1 or later" check box in the Browser tab of the Java Plug-in Control Panel. This is due to the auto-scan features of these browsers. For instance, if Netscape 7 is installed on a Windows machine that has Sun's 1.4.2 jre installed as the latest version and you deselect "Netscape 6 or later" in the Control Panel, Netscape 7 will still run Sun's 1.4.2 jre (Java Plug-in).

Using Java Plug-in 1.4.2 in conjunction with Netscape ^TM 6.x browsers can cause erratic behavior, including closure of the browser window, for applets that invoke applet functions from Javascript. This problem is due to a bug in the browser, and you can avoid this problem by using Netscape 7.0 browsers.

The Netscape 7 installer provides three choices for installation: Recommended, Full, and Custom. The Java Plug-in may not work properly in Recommended or Full installations of Netscape 7 browsers. Such Netscape 7 browsers may close when attempting to launch an applet. To avoid this problem, install Netscape 7 using the Custom option, and choose not to install the Quality Feedback Agent.

When installing Java Plug-in, it is necessary to shut down and then restart your web browser. On Microsoft Windows platforms, Netscape 7 has a Quick Launch feature that keeps it running in the background so that it can be launched with minimal start-up time from a Quick Launch icon in the system tray. To completely shut down Netscape 7, you must exit Netscape 7 from its Quick Launch icon in the system tray.

A Java Plug-in cache problem that exists in 1.4.1 that can cause an "java.lang.IllegalStateException: zip file closed" exception to occur has been fixed in 1.4.2. See 4740901.

For important bug fixes and RFEs in this release, see Java Plug-in enhancements and changes.

See Java Web Start enhancments and changes. See also Java Web Start Technology 1.4.2 Release Notes for more detailed information.

Java Update (available in 1.4.2_01 and higher versions) is a new feature of the SDK/JRE. Its purpose is to provide the latest update of Java in a flexible and user-selectable manner. See Enhancement and Changes for more more information about Java Update.

Note that the Help button in the 1.4.2 version refers to a "Get Java" button that is only present in 1.4.2_01 and higher versions.

The server VM is not installed with the stand-alone Windows JRE installation, nor is it installed with the public JRE installed with the SDK installation. If you want the server VM to work with the public JRE, you will need to create the directory

<drive>\:Program Files\Java\j2re1.4.2\bin\server

and copy the server VM from

<drive>\:sdk1.4.2\jre\bin\server

See JPDA enhancements and changes.

Java Virtual Machine Profiler Interface

As in earlier versions, JVMPI support continues to be limited to the default garbage collector in the system; none of the optional garbage collectors provide support for JVMPI. NOTE: JVMPI, always an experimental interface, will be removed and replaced by a standardized interface in the next upcoming major feature release.

Java Compiler (javac)

See Compiler enhancements and changes.

Notable outstanding bugs in Javadoc 1.4.2:

• In 1.4.2, javadoc hangs without any useful message if {@inheritDoc} is used in a member that cannot inherit a comment. (This can happen if the member does not override, implement or hide another member.) Bug 4812240:

• Internet Explorer displays an unnecessary horizontal scroll bar in the main content pane when frames are showing. A simple workaround is described in the bug report. Bug 4852280

Notable bug fixes in 1.4.2:

• Links to external methods using -link or -linkoffline are now generated. Bug 4615751

• Javadoc now generates cross references between classes/interfaces. Bug 4628281

• Using the -link option, @link now links to external classes. Bug 4652655

• Links to "Serialized Form" now contain anchors to classes. Bug 4521661

The complete list of Javadoc new features and fixed bugs are documented at What's New in Javadoc 1.4.2.

When verifying an unsigned JAR using jarsigner, instead of reporting that the JAR is unsigned, an java.lang.IllegalStateException is thrown due to a change in J2SE 1.4.2 that breaks an assumption made in the jarsigner code. Bug 4874885 (not published).

Sun ONE Studio 3.0, Community Edition and NetBeans 3.2.1 will work in conjunction with the Java 2 SDK 1.4.1 or 1.4.2. However, Forte for Java 2.0 and NetBeans 3.2 do not work with Java 2 SDK 1.4.1 or 1.4.2.

• libsafe library - A limitation in the 1.x versions of the libsafe library, available from Avaya Labs Research, can cause Java 2 SDK tools to fail with the message "Invalid initial heap size: -Xms8m." Trying to use the java application launcher by setting the -Xms option explicitly will fail also. This limitation is fixed in the most recent release of the libsafe library, version 2.0, available for download from http://www.research.avayalabs.com/project/libsafe/.