Enhancements and Changes in J2SE 1.4.1 Platform

Contents

Introduction
Developer Releases for 64-Bit Intel Itanium Processors
Java Web Start 1.2
Compiler and Class File Format Changes
Javadoc Changes
Java Naming and Directory Interface API
RMI
AWT Changes
Swing Changes
Internationalization
Shift-JIS Character Encoding Change
Security
Enhancements to Java Plug-in Technology
Kerberos Service and DNS Lookups
Virtual Machine
Support for SPARC^® v8 (SPARCstation^®) Processors
Java Platform Debugger Architecture

Introduction

This document summarizes some of the significant changes introduced in J2SE 1.4.1 Platform. See also the following.

Release Notes
Java Community Process Review for 1.4.1 Release Candidate API Specification (Ended September 3, 2002)
Java Community Process Review for 1.4.1 Beta API Specification (Ended July 22, 2002)

J2SE 1.4.1 is available in versions for the 64-bit Intel Itanium processor on Linux Red Hat 7.2 and Windows XP 64-bit edition. These releases are intended only for developers as they begin to work with the IA-64 architecture. They are offered without support and are not for use in production systems nor for redistribution with applications.

Look for the downloads for these versions on the J2SE 1.4.1 download page.

These 64-bit developer releases have the following limitations.

• Applications can be run only in interpreted mode. The platform will run in interpreted mode by default, with no need to supply the -Xint flag on the command line when launching an application. When using the 64-bit versions of the J2SE 1.4.1 platform, the command java MyApp will launch and execute MyApp by interpreting the bytecode. Java HotSpot-technology-based dynamic compilers for 64-bit support is planned for a future release of the J2SE platform.
• The 64-bit versions of J2SE 1.4.1 do not include the Java Plug-in and Java Web Start products.
• The 64-bit versions of J2SE 1.4.1 do not have an installer application. These versions are available only as a tar bundle.

The 32-bit versions of the J2SE 1.4.1 will not work on Intel Itanium machines.

Version 1.4.1 of the Java 2 SDK and Java Runtime Environment include the new Java Web Start 1.2 product. Java Web Start technology enables deployment full-featured applications over the net. Version 1.2 offers several significant enhancements requested by the growing number of Java Web Start users in the industry. See the (1.4.1/docs/guide/jws/index.html)Java Web Start documentation and (1.4.1/docs/guide/jws/relnotes.html)Java Web Start release notes.

The following changes have been made to the Java 2 SDK's javac source compiler.

• The outermost label of a doubly-labelled loop should not be allowed as the target of a continue statement according to the JLS, but previous versions of javac allowed it. As of Java 2 SDK 1.4.1, such code is rejected by the compiler. For example, this is now illegal:

  A:B: while(true) { continue A; }
  

• Previous versions of javac used to discard the left-hand-side of a qualification expression when the right-hand-side is a constant or a static member. That is not correct according to the JLS. javac now correctly evaluates the LHS. Specifically, in an expression such as

  x.y.z
  

  where y is an instance field of x and z is a static field of y, the compiler used to omit the required null pointer check on x.

  In addition, the null check is done for instance constants. For example, in the expression

  x.y
  

  where y is an instance constant member of x, we now check x for null and emit a null pointer exception when it is null.

• Previous versions of javac were not thread-safe when invoked concurrently from multiple threads using a programmatic entry point. As of Java 2 SDK 1.4.1, Javac is now thread safe and can be used concurrently without problems so long as the separate invocations do not attempt conflicting access to the file system.

• The compiler now releases the pointers to its internal data structures after compilation completes, so that using javac inside a java program will not leak space.

• It is not legal to select a type from an expression. The compiler did not previously report violations of this, but as of Java 2 SDK 1.4.1 it does.

• As of Java 2 SDK 1.4.1, the compiler detects all cases of mutually recursive constructors. Previously, the compiler only detected a self-recursive constructor.

• In a class declaration such as

  class A extends B implements C { ...
  

  the compiler used to look up C in the scope of B. That was not correct; as of Java 2 SDK 1.4.1, the compiler looks up C in the enclosing scope.

• In an expression such as

  x.new T()
  

  the compiler used to omit the required null pointer check on the value of x. The compiler now generates that null pointer check.

• In an inner superclass constructor call such as

  x.super()
  

  the compiler used to omit the required null pointer check on the value of x. The compiler now generates that null pointer check.

• For the try-finally language construct in which the finally clause is fairly simple, javac will inline the finally clause instead of using jsr. In the future, javac may become even more aggressive in its inlining of the finally clause.

• The Java 2 SDK 1.4.0 javac compiler incorrectly inserts <clinit> into class files when -g is specified and there is a static final constant variable declaration. An example is java.text.ChoiceFormat. The additional <clinit> causes the computed serializationUID to be different from what is expected, which causes an incompatibility problem. The 1.4.1 compiler does not generate the extra <clinit> methods.

• In J2SE 1.4.0, some of the classes internal to the implementation use assertions. In J2SE 1.4.1, even more are compiled with assertions enabled. Consequently they are compiled with the -source 1.4 flag, which implies the flag -target 1.4, which is reflected in the class files as version number 48.0. The change in target is because assertions use features of the J2SE APIs that were not present in previous releases of the platform.

  While the code generated still complies fully with the JVM specification, in -target 1.4 mode the compiler takes advantage of one feature of the VM that it did not previously use. The VM spec allows the constructor for a class to initialize its fields becore calling the superclass constructor. That is necessary to generate correct code for some cases involving inner classes. The compiler will take advantage of this feature in -target 1.4 (or when assertions are enabled). See 4030374 for the kind of compiler bug whose fix required this change.

The Javadoc tool has has about 2 dozen bug fixes. For details, see (1.4.1/docs/tooldocs/javadoc/whatsnew-1.4.1.html)What's New in Javadoc 1.4.1. Some of the more widely-encountered of these bugs include:

• Fixed bug where it mistakenly documented .class files found on classpath (if they belonged to packages passed in on the command line). (4548768)
• Fixed -use option, which was severely broken. (4496290)
• Fixed -link option to handle absolute paths. (4640745)
• Fixed -encoding option for reading source files. (4661481)
• Fixed {@docRoot} which had been inserting an extra slash "/". (4524350)
• Fixed {@inheritDoc}, which did not work. (4618686)
• Added interface constants to the Constant Field Values list. (4526070)

The following notes and enhancements pertain to the Java Naming and Directory Interface (JNDI). For additional information, see the JNDI documentation (1.4.1/docs/guide/jndi/).

• The LDAP service provider now supports connection pooling. An application can request this feature by setting the "com.sun.jndi.ldap.connect.pool" environment property to "true". See (1.4.1/docs/guide/jndi/jndi-ldap.html#POOL) the LDAP service provider documentation for details.

• The LDAP service provider now supports specification of more than one LDAP URL when configuring access to LDAP servers (bug 4512502). The "java.naming.provider.url" property is used by the LDAP service provider to configure how to communicate with the LDAP server. On releases earlier than the Java 2 SDK, v 1.4.1, the value of this property is a single LDAP URL string that specifies the hostname and port of the LDAP server, and the root distinguished name of the naming context to use. The syntax of the URL is specified by RFC 2255. On the Java 2 SDK, v 1.4.1, the value of this property is a list of space-separated LDAP URLs. The LDAP provider will attempt to use each URL in turn until it is able to create a successful connection using one of them and set the "java.naming.provider.url" property to the successful LDAP URL.

  This change does not affect applications that use a valid LDAP URL as specified in RFC 2255. This change affects only applications that assumed that a space character is valid in an LDAP URL and used such a URL as the value of the "java.naming.provider.url" property. According to RFC 2255, a space character in an LDAP URL must be encoded as the triplet "%20". On the Java 2 SDK v 1.4 and earlier releases, the LDAP provider will accept the space character as part of the URL. On the Java 2 SDK v 1.4.1, the provider will treat the space character as a separator between multiple LDAP URLs. The affected applications might experience "name not found" errors when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to replace each space character in the invalid URL with the triplet "%20".

• The LDAP service provider now supports automatic discovery of LDAP servers via use of DNS SRV records (bug 4512502). The "java.naming.provider.url" property is used by the JNDI/LDAP service provider to configure how to communicate with the LDAP server. Its value is one or more LDAP URLs. An LDAP URL can also be supplied as the name argument to methods in the initial context and be used to resolve LDAP referrals. In these situations, on the Java 2 SDK v 1.4.1, if neither a hostname nor port has been specified but a distinguished name has been specified in the URL (e.g., "ldap:///dc=example,dc=com"), the LDAP provider will use the distinguished name to determine and use the hostname and port of the LDAP server(s) configured in corresponding DNS SRV records, using the algorithm described in http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-08.txt

  If a connection is established using data from DNS, the provider will set the "java.naming.provider.url" property to an LDAP URL constructed using the selected hostname, port and distinguished name.

  If no such DNS records exist, the hostname and port default to localhost and 389, respectively.

  On systems earlier than the Java 2 SDK, v 1.4.1, unspecified hostname and port always default to localhost and 389, respectively; no attempt is made to use DNS SRV records.

  This change affects applications that are deployed in an environment in which DNS has been configured with SRV records to use LDAP servers other than localhost and port 389 and at the same time expect localhost and port 389 to be used without specifying them explicitly in an LDAP URL that contains a distinguished name . The affected applications will use a different LDAP server than expected when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to explicitly specify localhost in the LDAP URL.

• The DNS service provider now supports automatic discovery of DNS servers (bug 4507579). The "java.naming.provider.url" property is used by the JNDI/DNS service provider to configure how to communicate with DNS server(s). If this property has not been set or if its value specifies neither a hostname nor port, then on releases earlier than the Java 2 SDK, v 1.4.1, the hostname and port default to localhost and 53, respectively. Under the same circumstances on the Java 2 SDK, v 1.4.1, the DNS provider will attempt to determine and use the server(s) configured for the underlying platform (on Solaris or Linux, for example, the provider will read the /etc/resolv.conf file). If DNS has not been configured on the underlying platform, the hostname and port default to localhost and 53.

  This change affects applications that are deployed in an environment in which DNS has been configured in the underlying platform to use servers other than localhost and port 53, and at the same time expect localhost and port 53 to be used without specifying them explicitly. The affected applications will use a different DNS server than expected when migrating from Java 2 SDK v 1.4 to Java 2 SDK v 1.4.1. The workaround is for the application to explicitly specify localhost in the URL.

• The DNS service provider now allows the application to control the timeout used in UDP queries (bug 4630910).

The following changes have been made to RMI functionality in J2SE 1.4.1.

• The implementation-specific system property (1.4.1/docs/guide/rmi/sunrmiproperties.html#eagerHttpFallback) sun.rmi.transport.proxy.eagerHttpFallback has been added to allow additional control over when RMI's default socket factory will fall back to HTTP tunneling. This property configures the default socket factory so that any SocketException thrown by an initial (direct) connection attempt will trigger HTTP tunneling; this more "eager" fallback strategy can be useful when dealing with firewalls which deny instead of ignore connection attempts to unauthorized ports.

• In previous releases, the java.rmi.Naming.list (1.4.1/docs/api/java/rmi/Naming.html#list(java.lang.String)) method prepended the scheme rmi: to each name contained in the returned array of strings. The Naming.list implementation now matches the specification, returning an array of names that are URL-formatted, but without the scheme component.

• The java.rmi.server.RemoteServer.setLog (1.4.1/docs/api/java/rmi/server/RemoteServer.html#setLog(java.io.OutputStream)) method now specifies that it throws a SecurityException if the caller does not have permission to set the global call log. The method requires that the calling context has the permission java.util.logging.LoggingPermission("control") to set the log.

• The java.rmi.server.RMISocketFactory.setFailureHandler (1.4.1/docs/api/java/rmi/server/RMISocketFactory.html#setFailureHandler(java.rmi.server.RMIFailureHandler)) method now specifies that it throws a SecurityException if the caller does not have permission to set the global (1.4.1/docs/api/java/rmi/server/RMIFailureHandler.html) java.rmi.server.RMIFailureHandler. The method requires that the calling context has the permission java.lang.RuntimePermission("setFactory") to set the failure handler.

See also the RMI Release Notes (1.4.1/docs/guide/rmi/relnotes.html).

The following are important AWT bug fixes in J2SE 1.4.1.

• 4690831: Game applets fail to repaint properly with Internet Explorer.

• 4627627: Image Rendering causes some applets to fail with release 1.4.

• 4636548/ 4639735: Crash of release 1.4.0 when screensaver on Microsoft Windows 2000 is activated.

• 4379138: Problems on Linux with key events for some dead keys.

• 4627542: Swing applications don't support international keyboards under Linux.

• 4395157: Under Linux on 1.3, can't type "%" in applets.

• 4669873: A drag and drop bug, reported on hopper-beta under Microsoft Windows, caused an application to briefly freeze during DnD and is fixed in the final release of 1.4.1.

See also the (1.4.1/docs/guide/awt/AWTChanges.html)AWT release notes.

The following are important Swing bugs fixes in J2SE 1.4.1.

Focus related bugs:

• 4632782: JPopupMenu may now be prevented from taking focus
• 4628933: Heavy weight windows may lose focus when running on some versions of Microsoft Windows with a remote display application
• 4659800: Default button should follow the focus on Microsoft Windows look and feel
• (1.4.1/docs/guide/swing/SwingChanges.html#JTabbedPane)JTabbedPane and Focus Clarification

Drag and drop related bugs:

• 4513715: Drop no longer clobbers selected text
• 4513638: Cut/copy/drag fixed for JEditorPane with RTFEditorKit
• (1.4.1/docs/guide/swing/1.4/dnd.html#DefaultSupport)Import/export behavior has changed for the JEditorPane component

Miscellaneous:

• 4532517 Workaround for input verifier bug
• 4668963, 4419964: Metal look and feel can now pick up font sizes from the desktop on Microsoft Windows
• 4615396: Some locales will only honor font size from the desktop
• 4668511: Deadlock in JColorChooser
• 4218431: Document that multiple file selection is supported in JFileChooser

See also the (1.4.1/docs/guide/swing/1.4/Post1.4.html)Swing Changes Since J2SE 1.4.0.

The following changes have been made to internationalization functionality in J2SE 1.4.1.

• The EURO variant locales have been removed. They are no longer needed, because the locales for all member countries of the European Monetary Union now use the euro as the default currency.

• A Thai variant locale th_TH_TH has been added, which uses Thai digits for numbers and dates.

• The Cyrillic encodings KOI8-R and ANSI1251 are now supported on the Solaris Operating Environment.

• An input method for the Devanagari writing system has been bundled with the Java 2 Runtime Environment (Java RE) 1.4.1, but it is disabled by default. To enable it, move the file indicim.jar from the Java RE's lib/im directory to its lib/ext directory.

• Several character encodings are newly supported in the java.nio.charset package. For more details, please refer to the Supported Encodings (1.4.1/docs/guide/intl/encoding.doc.html) document.

A change has been introduced in the J2SE 1.4.1 Platform to align the Java platform's charset encoding aliases for Shift JIS encodings with the published IANA assignments. Prior to 1.4.1, the following aliases were provided as alternative aliases for the charset encoding "MS932" (Microsoft Windows codepage 932) within the Java platform:

shift_jis
ms_kanji
x-sjis

From 1.4.1 onwards these aliases will instead refer directly to the encoding with the MIME preferred name of Shift_JIS as defined by IANA:

This charset is an extension of csHalfWidthKatakana by adding graphic characters in JIS X 0208. The CCS's are JIS X0201:1997 and JIS X0208:1997. The complete definition is shown in Appendix 1 of JIS X0208:1997. This charset can be used for the top-level media type "text".

This is required because there is a growing number of applications that interpret the MIME tags for content correctly (in alignment with the IANA alias designations) which requires the J2SE platform to also provide the correct and published interpretation of these tags. This issue is covered within Sun bugID 4556882.

Note this change will not affect the default file encoding chosen by Java runtimes running on Win32 Japanese systems. On Japanese Win32 (running with Japanese locale settings) the default Java platform-chosen encoding will continue to be "MS932", or Microsoft Code page 932, which has a preferred MIME name of "windows-31j"

The following changes pertain to security-related functionality in J2SE 1.4.1.

• Three new security tools were added in the 1.4.1 release of the Java 2 platform: kinit, klist, and ktab. These tools help users obtain, list and manage Kerberos tickets. See the Security Tools (1.4.1/docs/tooldocs/tools.html#security) section of the documentation for more information.
• The Sun SecureRandom implementation now also makes use of an operating system-provided entropy source on Windows platforms, which can improve the startup time of cryptographic applications considerably. Edit the <java.home>/lib/security/java.security to control this feature.
• New root CA certificates with aliases baltimorecodesigningca, gtecybertrustglobalca, baltimorecybertrustca, gtecybertrustca, and gtecybertrust5ca have been added to the <java.home>/lib/security/cacerts keystore file. See (1.4.1/docs/tooldocs/solaris/keytool.html#cacerts)The cacerts Certificates File.

The following notes pertain to Java Plug-in technology enhancements in this release.

• There is now extensive documentation available on how different versions of Java Plug-in, runing with different web browsers and web browser versions, behave when OBJECT, EMBED, and APPLET tags appear on an HTML page. See Encountering OBJECT, EMBED, and APPLET Tags With Different Plug-in Versions and Browsers.
• The Control Panel has been updated with new documentation in the (1.4.1/docs/guide/plugin/developer_guide/control_panel.html)Java Plug-in Developer Guide, and an Update panel has been added for downloading security patches as they become available.
• There is now much more extensive documentation on (1.4.1/docs/guide/plugin/developer_guide/extensions.html)Deploying Optional Packages with Java Plug-in, including a "cookbook" set of instructions and a complete example of deploying the Java Media Framework, along with test links.
• There are more extensive instructions available on installing/registering Java Plug-in for Solaris/Linux with the various Netscape browsers. There is also a script that can be used for automatic registration. Included is documenation on how to uninstall previous versions of Plug-in before installing a new one.
• Http connection timeout information has been added (see Java Runtime Parameters: Default connection timeout in the (1.4.1/docs/guide/plugin/developer_guide/control_panel.html#advanced)Advanced Panel), and a Help button has been added to the Control Panel to provide instant access to information about the Control Panel.
• New attributes have been defined for customizing the applet window while resources are downloading, and these are described in the chapter called (1.4.1/docs/guide/plugin/developer_guide/special_tags.html) Special Applet Attributes in the Developer Guide.
• The section in the Developer Guide called (1.4.1/docs/guide/plugin/developer_guide/using_tags.html) Using OBJECT, EMBED and APPLET Tags in Java Plug-in has a more extensive explanation of version associated with attibute type. There is also additional expanation of versioning related to classid and codebase.
• The chapter called (1.4.1/docs/guide/plugin/developer_guide/java_js.html) Java-to-Javascript Communication in the Developer Guide now explains what the argument Object obj is in various methods related to DOMAccessor, DOMService, and DOMServiceProvider.

In the J2SE 1.4.0 platform, when using host based Kerberos service principal names (for example, nfs/servicehost@java.sun.com), the hostnames in the principal was not converted into lower case. This was in violation of the RFC 1964 Section 2.1.2. This has been fixed in this release and the hostnames are now converted to lower case.

If you are migrating from J2SE 1.4.0 to J2SE 1.4.1 and your DNS lookup returned mixed case hostnames, you should register the Kerberos principal in the Kerberos database with lower case hostnames.

The following enhancements have been made to the Java HotSpot Virtual Machine (VM).

• A deadlock detection utility has been added to the Java HotSpot VM. The utility is invoked by a ctrl+\ (on Linux or the Solaris Operating Environment) or a ctrl-break (on Microsoft Windows) on the command line while an application is running. The utility detects Java-platform-level deadlocks, including locking done from the Java Native Interface (JNI), the Java Virtual Machine Profiler Interface (JVMPI), and Java Virtual Machine Debug Interface (JVMDI).

  When invoked, the utility displays a thread dump to standard out and indicates any Java-platform-level deadlocks it detects. Refer to this sample output. If the application is deadlocked because two or more threads are involved in a cylce to acquire monitors, then the list of such threads and monitors involved in the deadlocks are displayed. Note, however, that this will not find deadlocks involving threads waiting on monitors on which no signal will be forthcoming.

• The following non-standard command-line flags are recognized by the VM.
  • -XX:+UseAltSigs - On the Solaris operating environment, the VM uses SIGUSR1 by default, which can sometimes conflict with applications that signal-chain SIGUSR1. -XX:+UseAltSigs will cause the VM to use signals other than SIGUSR1 and SIGUSR2 as the default. Available beginning in J2SE 1.4.1 on the Solaris Operating Environment.
  • -XX:+UseConcMarkSweepGC - This flag turns on concurrent garbage collection. This collector executes mostly concurrently with the application. It trades the utilization of processing power that would otherwise be available to the application for shorter garbage collection pause times.
  • -XX:+UseParallelGC - This flag enables garbage collection to occur on multiple threads for better performance on multiprocessor machines.

  Each of these new flags is non-standard, as indicated by the fact that they being with -XX, which means that they are subject to change without notice.

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, including 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 (1.4.1/docs/guide/vm/index.html)Java HotSpot VM documentation for information on the Server VM and Client VM.

UltraSPARC^® processors are not affected by this change.

The (1.4.1/docs/guide/jpda/enhancements.html#fsd)full-speed debugging feature of the Java Platform Debugger Architecture now can be used with both the Java HotSpot Client VM and Java HotSpot Server VM. In version 1.4.0, it worked only with the Java HotSpot Client VM.