Compatibility

SDK Documentation

Java 2 Platform, Standard Edition Version 1.4.2
Compatibility with Previous Releases

The following documents contain information about incompatibilities between adjacent releases.

• Incompatibilities in J2SE 1.4.1   (since 1.4.0)
• Incompatibilities in J2SE 1.4.0   (since 1.3)
• Incompatibilities in J2SE 1.3   (since 1.2)
• Incompatibilities in J2SE 1.2   (since 1.1)
• Incompatibilities in JDK 1.1   (since 1.0)

See the Java Language Specification Maintenance Page for a summary of changes that have been made to the specification of the Java programming language since the publication of the Java Language Specification, Second Edition.

Binary Compatibility

The Java 2 SDK, v1.4.2 is upwards binary-compatible with Java 2 SDK, v1.4.1 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, class files built with version 1.4.1 compilers will run correctly in the Java 2 SDK, v1.4.2.

Some early bytecode obfuscators produced class files that violated the class file format as given in the virtual machine specification. Such improperly formatted class files will not run on the Java 2 SDK's virtual machine, though some of them may have run on earlier versions of the virtual machine. To remedy this problem, regenerate the class files with a newer obfuscator that produces properly formatted class files.

Source Compatibility

Downward source compatibility is not supported. If source files use new language features or Java 2 Platform APIs, they will not be usable with an earlier version of the Java platform.

In general, the policy is that:

• Maintenance releases (such as 1.4.1, 1.4.2) do not introduce any new language features or APIs, so they maintain source-compatibility with each other.

• Functionality releases and major releases (such as 1.3.0, 1.4.0) maintain upwards but not downwards source-compatibility.

Deprecated APIs are methods and classes that are supported only for backwards compatibility, and thecompiler will generate a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated methods and classes, though there are no current plans to remove such methods and classes entirely from the system.

Some APIs in the sun.* packages have changed. These APIs are not intended for use by developers. Developers importing from sun.* packages do so at their own risk. For more details, see Why Developers Should Not Write Programs That Call sun.* Packages.

J2SE 1.4.2 is strongly compatible with previous versions of the Java 2 Platform. Almost all existing programs should run on J2SE 1.4.2 without modification. However, there are some minor potential incompatibilities that involve rare circumstances and "corner cases" that we are documenting here for completeness.

1. In J2SE 1.4.2, there is a known JCK failure. When running with the -enablesystemassertions flag, in rare cases, converting a floating-point number to a string can throw an assertion error.

   In J2SE 1.4.2_01, this incompatibility is removed and the associated bug is fixed. The bug report associated with this incompatibility is 4905011.

2. Beginning with version 1.4.2 of the J2SE Platform, class java.net.URI permits a hostname in the host component of a hierarchical URI, that comprises only a single domain label, to start with a digit. Previously, a URI such as s://123/p would not have its authority component parsed as a server-based authority and it would thus be considered a registry-based authority. As part of this change, the specification for URI.getHost() has been revised. The previous specification included the statement: "The last, or only, label in a domain name begins with an alpha character". The updated specification replaces this with: "The rightmost label of a domain name consisting of two or more labels, begins with an alpha character".
3. Prior to J2SE 1.4.2, when using a Microsoft Windows platform, if a user selected a user locale having no corresponding ANSI code page in the Control Panel (for example, Hindi), the file.encoding system property was set to utf-16le. As this property is used for the default encoding in Java, all readers and writers would default to using this encoding. As a result, files on the system were read/written using the utf-16le converter. This situation would often generate an exception.

   As of J2SE 1.4.2, the file.encoding system property is derived from the system default locale. As there is no explicit default file encoding on Microsoft Windows platforms, the system default locale provides a best guess for default file encoding in Java.

   If an application assumes utf-16le encoding as the default for non-ANSI codepage based locales, the application would fail.

   The bug report associated with this change is 4459099.

4. Prior to J2SE 1.4.0, the character encoding scheme for security policy files was unspecified, and the files were read in using the default character encoding. Starting in 1.4.0, the policy files were required to be encoded in UTF-8.

   While this allowed a policy file to be used across different locales, it broke existing policy files that contained characters in the default encoding.

   In J2SE 1.4.2, a new system property was introduced:     sun.security.policy.utf8

   If this system property is set to true, the policy file is read in using UTF8 (1.4.0 and 1.4.1 behavior). If the system property is set to false, the policy file is read in using the default encoding (pre-1.4.0 behavior). When the system property is not set (it is NULL), its default value is true.

5. The code for determining the Transparency value for an IndexColorModel object from a supplied colormap has been made more consistent and predictable. The related documentation has been updated accordingly.

   For any code that uses IndexColorModel, the return values of getTransparency() and getTransparentPixel() are now more accurate and consistent.

   The bug report associated with this change is 4688381.

6. Java Generic Security Services (JGSS) over Kerberos V5 is supported as of J2SE 1.4.0. As a part of estabishing the security context, a client receives a Service Ticket from the Kerberos server. This Service Ticket is presented by the client to the server as a part of the GSS Context establishment process.

   Prior to J2SE 1.4.2, if the useSubjectCredsOnly property was set to true, the Ticket Granting Ticket (TGT) was retrieved from the Subject and used to establish a GSS Security context. Service tickets obtained during the GSS Context establishment process were not stored in the Subject.

   As of J2SE 1.4.2, if the useSubjectCredsOnly property is true, service tickets obtained are stored in the Subject. This provides application developers access to Service tickets outside of the JGSS. For example, such tickets could be used by native applications or proprietary protocols. Also such tickets could be reused if a client again tries to estabish a security context to the same service.

   There are no related API changes. However, if a client application searches through the Subject's private credentials, in releases prior to J2SE 1.4.2, it would find only the TGT. As of J2SE 1.4.2, it will also find any additional Service ticket(s) obtained.

7. In J2SE 1.4.0, keyboard focus management was redesigned and "opposite" fields were added to java.awt.event.FocusEvent and java.awt.event.WindowEvent.

   For example, for WindowEvent, opposite is the other Window that participated in the state change. If the source of the event was activated, opposite would be the Window that was deactivated, and vice versa. For FocusEvent, opposite is the other component that participated in focus transfer. If the source of the event has gained focus, then opposite is the component that lost focus, and vice versa.

   The "source" field in java.util.EventObject, from which other events are inherited, is transient. Since FocusEvent.opposite and WindowEvent.opposite are not transient, serializing and deserializing them doesn't make sense. Thus as of J2SE 1.4.2, after deserialization, WindowEvent.opposite and FocusEvent.opposite are set to null.

   The bug report associated with this change is 4759974.