API Incompatibilities
-
The ActiveEvent class now resides in the package java.awt. It used to be in java.awt.peer.
-
The Swing and Accessibility packages (formerly in the com.sun.java.* namespace) have moved to the javax.* namespace. These packages now have the following names:
-
Applications that use the old com.sun.java.swing* names for these packages from Swing 1.0 do not work in the Java 2 SDK for Solaris platform. Update these applications to use the new java.swing package names. A PackageRenamer tool is available at http://java.sun.com/products/jfc/PackageRenamer for making this conversion.
Note -The packages com.sun.java.swing.plaf.windows and com.sun.java.plaf.motif have not changed names.
If necessary, you can force applications using the old package names to work on the Java 2 SDK for Solaris platform by placing the Swing 1.0 jar file first on the boot class path:
java -Xbootclasspath:<path to 1.0 swingall.jar>:<path to Java 2 SDK rt.jar> ...
Note -The Java 2 SDK for Solaris Swing package has been modified to deal with Java 2 SDK for Solaris security. Therefore if you use this technique to run the Swing 1.0 classes with Java 2 SDK for Solaris in an environment where a security manager is present (that is, applets in a browser), the program might not run correctly.
-
The following fields of class java.awt.datatransfer have been made final in Java 2 SDK for Solaris: stringFlavor and plainTextFlavor:
public static final DataFlavor stringFlavor public static final DataFlavor plainTextFlavor
-
Java 2 SDK for Solaris includes the java.util.List interface. As a result, existing source code might possibly produce a namespace conflict between java.awt.List and java.util.List.
In Java 2 SDK for Solaris, using the wildcard import statements together causes a compiler error for code that contains the unqualified name List, as in the following example:
import java.awt.*; import java.util.*;
To work around this problem, either add an import statement such as
import java.awt.List;
to resolve the conflict throughout the file, or fully qualify the class name by the desired package at each point of use.
-
In Java 2 SDK for Solaris, the field CHAR_UNDEFINED in class java.awt.event.KeyEvent has the value 0x0ffff. In JDK 1.1-based releases, the field had a value of 0x0. This change was made because 0 is a valid Unicode character and therefore cannot be used to define CHAR_UNDEFINED.
-
In Java 2 SDK for Solaris, the signature of the java.io.StringReader.ready method changed so an IOException can be thrown if the StringReader is closed. Now the StringReader class properly implements the general contract spelled out in the abstract class java.io.Reader, which it extends.
-
In Java 2 SDK for Solaris, the specifications for Integer.decode() and Short.decode() are explicit about the correct representation of negative numbers. Negative numbers always begin with a minus sign (-). If the number is hexadecimal or octal, the base specifier (0x, #, or 0), must come after the minus sign.
In Java 2 SDK for Solaris, the specifications did not clearly state whether a minus sign should come before or after a base specifier. The actual implementations expected the base specifier (if any) to come before the minus sign (if any).
For example, in Java 2 SDK for Solaris, decoding -0x5 returns -5 and decoding 0x-5 throws a NumberFormatException. In JDK 1.1, the results were opposite: -0x5 threw a NumberFormatException and 0x-5 returned -5.
The decoding rules used in JDK 1.1 were unconventional and undocumented. However, some programs might rely on this behavior.
-
In Java 2 SDK for Solaris, classes java.util.Vector and java.util.Hashtable have been retrofitted to implement the relevant interfaces in the new Collections Framework (java.util.Map, respectively). As a consequence, the semantics of the equals and hashCode methods have changed to provide value equality, rather than reference equality, as per the general contracts set forth in List.equals and Map.equals.
This raises several compatibility issues:
-
"Self-reference" (inserting a Vector or Hashtable into itself) can now cause stack overflows under certain circumstances:
-
If a Hashtable is inserted into itself as a key, the Hashtable becomes corrupt, and subsequent operations can cause stack overflow. (It has never been permissible to mutate an object that is serving as a Hashtable key Inserting an object into a Hashtable now qualifies as mutation, since it affects equals comparison.)
-
If a Hashtable contains itself as a value (otherwise known as an element), equals and hashCode are undefined by the contract. If the hashCode or equals methods are called on such a "self-referential" Hashtable, a stack overflow can result.
-
If a Vector contains itself as an element, equals and hashCode are undefined by the contract, and can cause a stack overflow.
-
-
Because equals and hashCode now depend on the contents of the Vector or Hashtable, they are now synchronized against other operations on the collection. Prior to Java 2 SDK for Solaris, they were unsynchronized. The additional synchronization could cause liveness problems if a client depended on the fact that equals or hashCode were unsynchronized.
-
Clients with explicit dependence on the "reference equality" behavior of equals for Vector or Hashtable do not operate properly. For example, suppose a program kept a Hashtable whose keys were all of the Vectors (or Hashtables) in some system. It was previously the case that each Vector (or Hashtable) was a distinct key, regardless of its contents. It is now the case that any two Vectors (or Hashtables) with the same contents are considered equal. Further, it is no longer legal to modify a Vector or Hashtable that is currently serving as the key in a Hashtable.
-
Because equals and hashCode now examine the entire contents of the Vector or Hashtable, they might run more slowly than they used to for large collections.
-
-
The new version of the File class is compatible with both its originally intended behavior and its current common uses. However, some minor differences in behavior might cause some programs to fail.
-
In Java 2 SDK for Solaris, the checkAccess method of java.lang.Thread is final. In the JDK 1.1 platform, checkAccess was not final [bug 4151102] .
-
In Java 2 SDK for Solaris, the getInterfaces method of class java.lang.Class returns an array containing Cloneable and Serializable class objects when invoked on a class representing an array. In JDK 1.1, getInterfaces returned an empty array when invoked thus.
-
The Java 2 SDK for Solaris abstract classes java.text.BreakIterator, java.text.SimpleTextBoundary, and java.text.Collator (and Collator's subclass java.text.RuleBasedCollator) no longer implement the Serializable interface as they did in JDK 1.1 [bug 4152965] .
-
The Java 2 SDK for Solaris abstract method drawString(AttributedCharacterIterator,int,int) has been added to the java.awt.Graphics class as part of the Input Method Framework for use by the PersonalJavaTM platform. Subclasses of Graphics in applications based on the JDK 1.1 platform are likely to be rare. However, any such subclasses needs to provide an implementation of this new abstract method for use in conjunction with the Java 2 SDK for Solaris platform [bug 4128205].
-
The String hash function implemented in JDK 1.1 releases did not match the function specified in the first edition of the JLS. In fact, the specified function cannot be implemented, in that it addresses characters outside of the input string. Additionally, the implemented function did not perform well on certain classes of strings, including URLs.
To bring the implementation into accord with the specification, and to fix the performance problems, the specification and implementation have been modified. The Java 2 SDK for Solaris String hash() function is specified as:
s[0] * 31^(n-1) + s[1] * 31^(n-2) + ... + s[n-1]
where s[i] is the ith character of string s.
This change should have no effect on the majority of applications. If an application has persistent data that depend on actual String hash values, it could theoretically be affected. However, the serialized representation of a Hashtable does not depend on the actual hash values of the keys stored in the Hashtable. Thus, applications relying on serialization for storage of persistent data are unaffected [bug 4045622].
-
Java 2 SDK for Solaris does not support the Native Method Interface (NMI).
If you have either written non-JNI native methods with the NMI supported by JDK 1.0, or embedded the runtime by way of the JNI Invocation Interface, you must re-link your native libraries before they can be used with Java 2 SDK for Solaris. In the Solaris environment, you have to replace -ljava in your link command line with -ljvm. You also have to rewrite to the JNI.
Note -This change does not affect JNI programmers implementing native methods.
As of Java 2 SDK for Solaris, Sun supports JNI only. JNI is the standard way to make your native libraries inter-operate with the Java programming language. In addition, JNI offers VM independence for any native code that you write. If your methods use NMI, please refer to Chapter 3, Java Native Interface (JNI) for information about migrating your native methods to JNI.
-
Using Thread.suspend() can lead to a deadlock condition. This method is inherently unsafe and has been deprecated (along with other asynchronous thread methods, such as Thread.stop() and Thread.resume() [bug Id 4203325].
Thread.suspend() is unsafe since it might cause a thread to be suspended, for instance, while it is in the midst of a synchronized method. This action can potentially lock out other threads, and might cause deadlock (please see http://java.sun.com/products//jdk/1.2/docs/guide/misc/threadPrimitiveDeprecation.html reference platform documentation for more detail).
-
In JDK 1.1, Thread.stop can interrupt a thread blocked in Object.wait or Thread.sleep. In Java 2 SDK for Solaris running on the Solaris 2.6 environment with native threads, Thread.stop cannot interrupt a blocked thread. Java 2 SDK for Solaris behaves the same as JDK 1.1 with respect to Thread.stop when running on other operating systems or on the Solaris 2.6 environment.
-
This section describes compatibility issues affecting developers who implement the interfaces in the java.sql package (primarily those implementing JDBC drivers). The following interfaces contain new methods in Java 2 SDK for Solaris:
-
Source code that implements the JDK 1.1 versions of these interfaces do not compile properly under Java 2 SDK for Solaris unless you change it to implement the new methods.
The following interfaces support new types in Java 2 SDK for Solaris:
-
Source code that implements these interfaces and compiles correctly in Java 2 SDK for Solaris do not compile under the JDK 1.1 as the new types added to java.sql are not present.
-
A public field, serialVersionUID, was introduced into the java.io.Serializable interface in Java 2 SDK for Solaris. This field should never have been introduced into the interface. Its meaning is unspecified, and its presence contradicts the java.io.Serializable specification.
The API specification for java.io.Serializable states
The serialization interface has no methods or fields."
Furthermore, according to the serialization specification, the only way to get the serial version UID of a class is through the ObjectStreamClass.lookup(className).getSerialVersionUID() method. It does not make sense to try to get the serial version UID through a field that might or might not exist.
The serial version UID is sometimes computed and sometimes explicitly defined in a class, but it is never inherited from a superclass or interface. Since interfaces cannot be instantiated directly, a serialVersionUID field in an interface can be of no use to the serialization system. In fact, the serialization system makes no use of this field.
For these reasons, the public serialVersionUID field was removed in Java 2 SDK for Solaris. It is expected that this change will not break any existing applications.
- © 2010, Oracle Corporation and/or its affiliates