The following documents contain information about incompatibilities between adjacent releases.
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 .
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.
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.
-enablesystemassertionsflag, 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.
file.encodingsystem 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-16leconverter. 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.
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:
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.
IndexColorModelobject 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
getTransparentPixel() are now more accurate and consistent.
The bug report associated with this change is 4688381.
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.
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
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.