Java Community ProcessSM Maintenance Review
for J2SETM 1.4

Introduction

This site provides details of specification changes being made in version 1.4 ("Merlin") of the JavaTM 2 Platform, Standard Edition (J2SETM). The descriptions on this site correspond to the platform changes that were made since the Beta release of J2SE 1.4 and which are present in the Beta 2 release of J2SE 1.4. Descriptions of post-Beta 2 specification changes will be provided in the future for separate review.

Merlin contains a variety of new features, of varying scale. Major features have been addressed by separate component JSRs (there are thirteen component JSRs in Merlin), but smaller features (such as, for example, new GUI widgets) are being addressed under the JCP maintenance rules.

The major new features of the Merlin release are described in JSR-059 "Merlin Release Contents". However, as that document states:

"This specification will not itself define any new APIs, rather it will reference APIs defined in other JCP Specifications or through the JCP maintenance process."
So, as with the component JSRs, the individual non-JSR API changes are being reviewed separately in the JCP process, in this case through a JCP maintenance review. Similarly to the review process for the Merlin component JSRs, any feature that fails its maintenance review will be dropped from Merlin and removed from the JSR-059 feature list.

Feedback

Please use the following address to provide review feedback on the platform changes described here.
merlin-jsr@eng.sun.com

Change Descriptions

Changes and enhancements to the Java 2 Platform since J2SE 1.4 Beta that are included in J2SE 1.4 Beta 2 are summarized by functional area at the links below. The description of each change includes links to the affected parts of the API specification as well as to any bug reports that are relevant to the change.

Also available are difference files that highlight all changes in the Javadoc API specifications between J2SE 1.4 Beta and J2SE 1.4 Beta 2. See

Specification Difference Files

AWT

Window centering API

Many developers want to be able to center a window on the user's screen. This is most often used for splash screens, and is sometimes used for the application window. This API change addresses this issue with the introduction of the following new methods in java.awt.GraphicsEnvironment:

The bug report that corresponds to this change is: 4463949.

Bad behaviour of a popup window

Prior to merlin, a Window that was not a Frame or a Dialog could not become the active Window; that is, it could not become the Window that contains the focus owner and that is typically distinguished from other Windows by the window manager via special decorations. A corollary of this behavior was that such a Window also could not contain the focus owner. This was fine for Windows that did not contain focusable Components anyway, such as tool tips. However, this specification prevented developers from designing more sophisticated Windows that did contain focusable Components. Because of this design, the AWT was implemented such that showing a Window that was not a Frame or a Dialog (via Window.show() or Window.setVisible(true)) did not change the active Window or the current focus owner. Normally, showing a Window made that Window the new active Window and changed the focus owner to a Component inside that Window.

As part of the Merlin Focus Enhancements project (RFE 4290675), we added to the AWT, in a backward-compatible manner, the ability for a Window that was not a Frame or a Dialog to contain the focus owner. It was our feeling at the time that since the Window class was now on par with Frame and Dialog, the spurious difference in behavior when showing a Window should also be corrected.

Unfortunately, this decision broke numerous applications that assumed that showing a Window did not change the active Window. For example, if a user were typing in a JTextField, and also had the mouse centered over that JTextField, Swing might display the JTextField's JToolTip using the AWT Window class. Prior to merlin, showing the JToolTip did not affect the global focus state of the application and the user could continue to type without interruption. However, in merlin, the JToolTip now steals focus from the JTextField, preventing the user from typing further.

After some discussion, the AWT and the Swing teams have agreed that the Window class should only steal focus if it contains a focusable Component. That way, existing applications that show Windows that do not contain focusable Components (such as heavyweight JToolTips) can be run under merlin without modification. There will still exist an incompatibility with Windows that do contain focusable Components; however, we believe the specification outlined in this document is correct for such applications, and we do not anticipate that developers will complain about the new behavior.

This change updates the specification of the following existing methods in java.awt.Window:

In addition the Focus specification has been updated as well.

The bug report that corresponds to this change is: 4462677.

DataFlavor should not assume all text/* subtypes use the charset parameter

The current DataFlavor implementation assumed that all DataFlavors with a primary MIME type of "text" have either an explicit or implicit charset parameter. If a charset is not specified, then the charset is assumed to be the platform's default. The current data transfer subsystem decodes encoded text using the DataFlavor's charset, and reencodes in the encoding the native platform expects, as specified in the flavormap.properties file.

This process is unnecessary for MIME types which do not support the charset parameter. Indeed, for text types which include binary data, the conversion process could fail, rendering the entire transfer unsuccessful. The most notable subtype which does not use the charset parameter is 'rtf'.

This change updates the DataFlavor API to accommodate text DataFlavors which do not support the charset parameter, and updates the implementation accordingly.

As for unrecognized subtypes, such as those beginning with 'x-' and the numerous vendor-specific text subtypes, the most compatible approach is to use the charset parameter only if it is specified explicitly. If no charset parameter is specified, no default should be assumed.

Update the specifications of the following, existing methods of java.awt.datatransfer.DataFlavor

Change the specification of the flavormap.properties file format.

The bug report that corresponds to this change is: 4425746.

Replace Window.applyResourceBundle, deprecate ComponentOrientation.getOrientation(RB)

The ComponentOrientation work in J2SE 1.2 introduced the methods java.awt.ComponentOrientation.getOrientation(ResourceBundle), java.awt.Window.applyResourceBundle(ResourceBundle), and java.awt.Window.applyResourceBundle(String). These methods are confusingly defined and use design patterns that we do not want to promote.

This API change consists of the following:

The bug report that corresponds to this change is: 4363689.

Provide more access to text layout functionality

In class java.awt.Font:

The bug report that corresponds to this change is: 4403152.

Deprecated focus methods

The bugtraq report that corresponds to this change is: 4476300.

The new focus subsystem, introduced in this release, introduced a new architecture and a new terminology for handling keyboard focus in sophisticated AWT and Swing applications. Prior to this project, many of the focus-related APIs were inconsistent in usage and termonology, were improperly documented, and led to poorly designed UIs. Now that the new architecture is in place, the most egregious of these APIs has been deprecated.

The following constants and methods have been deprecated:

ActionEvents (and Other Events) Need Timestamps

The bugtraq report that corresponds to this change is: 4434193.

The new focus architecture includes a type-ahead mechanism that ensures that subsequent KeyEvents that follow a KeyEvent that initiates a focus transfer are not delivered until the transfer is completed. The design for this feature is based on the UTC timestamps of the various events. Events with timestamps later than that of the initiating event are enqueued pending resolution of the transfer; events with earlier timestamps are not.

To implement this feature, the focus code keeps track of the timestamp of the event currently being handled. If a focus change is initiated during this handling, the timestamp is available for use. However, if the current event does not have a timestamp, then the current system time is used. This time is usually too far ahead of the time that the event actually occurred to be of any real use. As a result, the type-ahead mechanism fails, and KeyEvents are delivered before the focus transfer is completed.

The most common case where we encountered this problem was with ActionEvents. ActionEvents are high-level, semantic events generated in response to underlying InputEvents. While the InputEvents had timestamps associated with them, the ActionEvents did not. The ActionEvent API has therefore been expanded to accomodate a timestamp and the implementation has been updated so that an ActionEvent's timestamp is equal to that of its underlying InputEvent.

The following methods have been added to ActionEvent:

The following ActionEvent methods were modified:

The getWhen method was added to InvocationEvent.

The InvocationEvent constructors InvocationEvent(Object, Runnable) and InvocationEvent(Object, Runnable, Object, boolean) were modified.

A new constructor InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo) was added to InputMethodEvent, as well as the getWhen method.

The following InputMethodEvent constructors have been modified:

Finally, the following methods were added to EventQueue:

Window Centering API Required for Multiscreen Support

The bugtraq report that corresponds to this change is: 4463949.

Xinerama-aware applications running on multi-headed systems have caused problems which have resulted in a variety of bug reports. Some multi-headed environments use monitors with little or no borders, which can be butted up against one another such that the resulting effect is one mammoth display. In this case, a "properly" centered window may span multiple screens. Other multi-headed environments use regular CRT monitors, with several inches of packaging between the actual display areas. In this case, a window spanning multiple screens produces a disconcerting effect, especially if the window cannot be dragged onto one monitor or the other (the Solaris login screen, for example). In short there was no way to tell where to center a window in a Xinerama environment.

To address this problem, the X group has added API which allows Xinerama users to specify where they want "centered" windows to be centered, and allows developers of Xinerama-aware applications to code accordingly.

Prior to this release, the way to center a window has been to center it within the bounds of the default GraphicsDevice, like this: 

     bounds = getDefaultScreenDevice().getDefaultConfiguration().getBounds();
     frame.setLocation(bounds / 2 - size of window / 2);
This code would center the windows "correctly" on Xinerama systems where windows should be centered to the entire Xinerama coordinate space.

As of this release, post 4356756-fix JDKs will center windows "correctly" on Xinerama systems where windows should be centered within the first display.

To accomplish this, the getCenterPoint method has been added to GraphicsEnvironment .

This method works as follows on various platforms:

As of 1.4, the correct code for centering is: 

     frame.setLocation(getCenterPoint() - size of window / 2);

The other method added to GraphicsEnvironment is getMaximumWindowBounds. Both getCenterPoint and getMaximumWindowBounds throw a HeadlessException when in Headless mode.

New InputEvent Key Modifiers

The bugtraq reports that corresponds to this change are: 4387938 and 4421515.

Previously, the InputEvent modifiers had the same values for keyboard and mouse buttons. In certain situations there was no way to distinguish which one was pressed or when more than one was held simultaneously. These situations included cases when more than one mouse button was down at the same time, or when a modifier key was used to modify a mouse event.

To address this deficiency, the following constants were added to InputEvent:

The following methods were added to InputEvent:

The class spec for MouseEvent was updated. The following constants were also added to MouseEvent:

These methods in MouseEvent were added:

DragSourceDragEvent has the new method getGestureModifiersEx.

Drag and Drop

Drag source now provided with mouse coordinates

The Swing Team has requested the ability to alpha-blend a Drag and Drop drag cursor with the underlying application image. This would allow an application to support translucent drag icons, similar to those available on the Macintosh and Windows 2000 GUIs. Unfortunately, this was not previously possible because of two design deficiencies in the Drag and Drop API:
  1. A drag source was not provided with mouse pointer coordinates during a drag operation. This prevented the drag source from grabbing the correct bits from the screen to blend into the drag cursor image.
  2. The previous listener API provided mouse move notifications only when the cursor is inside a drop target. The API must be able to send notifications for any mouse move during the course of a drag, regardless of the cursor's position.

To address (2), we introduce a new Listener that provides notification of any mouse move during a drag.

This release introduces a new API that allows developers to register Listeners with DragSource objects using the standard JavaBeans-style add and remove methods. Such Listeners will receive drag source events for drag operations recognized by DragGestureRecognizers associated with that DragSource.

Even though most applications share a singleton DragSource instance among all conceptual drag sources, this design is still valid because for most applications a single DragSourceListener is sufficient. If there is a need to register different Listeners for different drag sources, the API allows developers to create several DragSource instances, each associated with its own conceptual drag source, and register different Listeners with them.

Finally, the previous specification for DragSourceListener and DragSourceAdapter was incorrect by specifying that listeners are notified of drop site-related events only when the mouse is inside a Java DropTarget. In fact, the implementation will also notify the listeners if the mouse is inside a native drop site.

This API change includes the following:

The bug report that corresponds wth this change is 4422345 .

DnD Event Targeting Update

Unlike normal mouse event targeting, DnD event targeting previously ignored the rule that lightweight Components which do not have an appropriate listener installed for the event type should behave as though they do not exist. That is, the event should fall-through the Z-order to the first Component that has an installed listener.

In the previous implementation, drag notifications were always dispatched to the top-most Component under the mouse cursor. If this Component does not have an associated drop target, these notifications are discarded. This design had two major flaws:

  1. We have to ignore a Swing glass pane during drag notification targeting, because it would consume all drag notifications otherwise. This prevents developers from using a Swing glass pane as a drop target. (BugId 4435403)
  2. To implement drop support on a compound Component, such as a JColorChooser, such that the Component would accept a drop anywhere inside of it, developers are forced to install drop targets on all descendants of the compound Component. This is unwieldy and inefficient. (BugId 4426794)
This API change modifies DnD event targeting so that it follows the same procedure as normal mouse event targeting. Drag notifications are now dispatched to the top-most Component under the mouse cursor with an active drop target. This scheme will more readily satisfy developers' needs, and will resolve the two bugs discussed above in an efficient and elegant way.

This API change updates the following specifications:

The bug report that corresponds to this change is: 4426794.

CORBA

POAOperations.reference_to_servant now throws WrongAdapter

There is an editorial error in the POA IDL in the CORBA 2.3.1 specification. The consolidated IDL for the POA incorrectly lists the operation 
	ObjectId reference_to_servant( in Object reference ) raises (
	    ObjectNotActive, WrongPolicy )

The raises clause should also include WrongAdapter, as explained in section 11.3.8.22 of CORBA 2.3.1. The WrongAdapter exception should be raised if regerence_to_servant is called on an object reference that was not created by the POA instance on which reference_to_servant is invoked.

This API change modifies org.omg.PortableServer.POAOperations.reference_to_servant to throw WrongAdapter.

The bug report that corresponds to this change is: 4469446.

javax.rmi.CORBA.Tie.deactivate() update

Method javax.rmi.CORBA.Tie.deactivate() now throws java.rmi.NoSuchObjectException()

The bug report that corresponds to this change is: 4483095.

resolve_str() no longer throws "AlreadyBounds" Exception

Accordining to the Interoperable Naming Service specification (http://cgi.omg.org/cgi-bin/doc?ptc/00-08-07) org.omg.CosNaming.NamingContextExt.resolve_str() should not throw org.omg.CosNaming.NamingContextPackage.AlreadyBound Exception. This API change makes this so.

The bug report that corresponds to this change is: 4476212.

org.omg.CosNaming.NamingContextHelper.narrow()

org.omg.CosNaming.NamingContextHelper.narrow() no longer throw sorg.omg.CORBA.BAD_PARAM exception explicitly in the method signature. org. omg.CORBA.BAD_PARAM is a Runtime exception and hence has no effect on the end user.

The bug report that corresponds to this change is: 4483533.

I/O

ObjectOutputStream.PutField.write() now deprecated

ObjectOutputStream.PutField.write() should not have been declared public, since it is only used internally by ObjectOutputStream, and cannot be used externally in its current form without causing application errors.

This API change deprecates ObjectOutputStream.PutField.write() in favor of ObjectOutputStream.writeFields(), which has always been the correct way of writing PutField data.

The bug report that corresponds to this change is: 4289070.

java.lang

Specification update for java.lang.ClassLoadergetSystemClassLoader()

Java Web Start needs a way to provide customized application class loading behavior in the Java runtime environment in which it runs downloaded applications. It currently does this by loading the applications using it's own ClassLoader implementation. However, compatibility problems have arisen due to the fact that this class loader is different from the one returned by the ClassLoader.getSystemClassLoader() method.

This change introduces a way for applications to provide their own customized system class loader which can extend the behavior of the default system class loader provided by the JRE. The change allows the new customized system class loader to be returned by the ClassLoader.getSystemClassLoader() method.

The specification of getSystemClassLoader() has been updated to check for the new java.system.class.loader system property.

The bug report that corresponds to this change is: 4372945.

Static factories in primitive wrapper classes shouldn't promise new object

The various static factory methods in the primitive wrapper classes (valueOf and to*String) often promise returning a newly allocated object. One of the chief advantages of static factories over constructors is that a new object does *not* have to be returned. This is a harmful overspecification that is easy to correct. The specification is harmful since it forces implementations to allocate objects unnecessarily. For example, with the current specification, calling valueOf(0) a million times will result in the allocation of 1 million Integer object, precluding an implementation from memoizing common arguments and returning the same immutable Integer representing zero. Additionally, from a source inspection, some methods do not follow the documented contract, in particular Boolean.toString and Integer.toString.

Changing the JavaDoc to remove this requirement doesn't require any Java code be modified. If another implementation actually follows the spec, it will follow the revised spec as well. Current users are unlikely to rely on this property of the existing specification.

This set of changes allows library implementors the flexibility to follow current best practices recommendations. The following toString and valueOf method specifications have been updated to remove promises of returning newly allocated objects. Other aspects of the spec remain unchanged.

java.lang.Float:

java.lang.Double java.lang.Boolean java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Character java.lang.String

The bug report that corresponds to this change is: 4469477.

Spec update for String.indexOf/lastIndexOf

The empty string handling of String.indexOf was inconsistent with the empty string handling of String.lastIndexOf. Also, the specification for these two methods was previously vague and contradictory. The specs for each of String.indexOf and String.lastIndexOf have been rewritten to be precise and self-consistent.

The bug report that corresponds to this change is: 4276204.

New method public Throwable.setStackTrace

System programmers who wish to cleverly sculpt the stack trace of a Throwable instance previously had very limited tools at their disposal: there was just the fillInStackTrace method, which can only replace an exception's existing stack trace with a snapsnot of that of the currently executing thread. Before 1.4, this limitation hadn't really stood out, because there was not a public API for portably describing the detailed contents of a stack trace anyway, so the ability to set an exception's trace to the currently executing one was about as much as one could expect. In 1.4, however, there is now a public API for more-or-less portably describing and accessing the detailed contents of a stack trace: the new StackTraceElement class and the new getStackTrace method on Throwable. In addition, this stack trace data is now part of Throwable's serialized form, so the trace of an exception deserialized from a byte stream can be arbitrary, with frames from other VM incarnations with different classes, etc. With the possibility of arbitrary exception stack traces originating from deserialized data, there should be corresponding enhancement to the API for mutating stack trace data beyond just the existing fillInStackTrace method.

This API change adds the following new public method to java.lang.Throwable:

The bug report that corresponds to this change is: 4010355.

java.util

java.util.ResourceBundle corrupts the value set with setParent()

In J2RE releases 1.2.2 and earlier, subclasses of java.util.ResourceBundle were able to set their parent resource bundles by calling setParent from their constructor, and subsequent calls to obtain objects from the resource bundle would be able to find objects in the parent bundle. The reimplementation of ResourceBundle in 1.3 eliminated this "feature" by always setting the bundle's parent after its construction, and the far more complete specification of ResourceBundle in 1.4 doesn't allow this capability. However, the elimination of this "feature" is seen as a regression by a number of developers.

This API change updates the specification for getBundle(String, Locale, ClassLoader), to say that whenever it succeeds, it calls the previously instantiated resource bundle's setParent method with the new resource bundle, unless the previously instantiated resource bundle already has a non-null parent.

The bug report that corresponds to this change is 4396021.

Adjustments to TimeZone and SimpleDateFormat

  1. Custom time zone ID in TimeZone

    Currently (Pre-1.4), TimeZone.getTimeZone() gives the same name "Custom" as the ID to all TimeZone objects that have been created with a custom time zone ID string, such as "GMT-08:00". Currently, therefore TimeZone.getTimeZone(otherTimeZone.getID()) always creates a "GMT" time zone since "Custom" can't be found as a valid time zone ID. It should return a TimeZone that is equal to otherTimeZone (unless otherTimeZone has been modified after its instantiation).

    Also, the spec of the custom time zone ID syntax is unclear. Use of "Custom" for a created TimeZone is not specified in the API spec. Locale dependencies are not described.

  2. Time zone formats in SimpleDateFormat and TimeZone.getDisplayName()

    SimpleDateFormat specifies that parse() accepts "GMT+hours:minutes" and "GMT-hours:minutes". However, the current implementation accepts other formats, "GMT+hours", "GMT-hours", "GMT+hhmm", "GMT-hhmm", "+hhmm", and "-hhmm". The spec has to clarify the format syntax.

    This API change addresses these issues with the following:

The bug report that corresponds to this change is 4322313.

java.util.regex

As the beta release was examined by experts, several very good points were brought to our attention for the improvement of the java.util.regex package. Since this package is new it makes sense fix these items now before compatibility becomes a concern.

See also:

This set of API changes cover the following: 
  1. Removed support of conditionals (?(cond)yes|no) as this is an
     experimental feature in Perl.
  2. Added support for \G
  3. Removed < and > as metacharacters since they conflicted too easily with
     commonly used literals in HTML and XML, etc.
  4. Removed vertical tab and form feed as line terminators. Added a new
     UNIX_LINE mode that only recognizes \n as a line terminator.
  5. Added Matcher.find(int startAt) as asked for in 4474290
  6. Now interpreting dangling ] and } as literals like Perl does
  7. Took out the unsupported families error message
  8. Class Node no longer implements Cloneable
  9. Changed the way backrefs are parsed to more closely match the way Perl
     interprets them.
  10. Removed the 'cut' operator signified by '!'.
  11. Implemented Perl's (?x) which is a comments mode where space and comments
      can be embedded in a regular expression
  12. A new character class syntax that allows union and intersection of
      character classes:
      X union Y         [X[Y]]
      X intersect Y     [X&&Y]
      X subtract Y      [X&&[^Y]]
  13. Changed the ^ metacharacter so it will not match after a string
      ending newline, since it does not in Perl.
  14. Changed the replacement string syntax from $(n) to $n and allowed
      escaping of $ to be more like Perl.
  15. All the group constructs starting with (? should be pure groups and
      should not capture text.

The bug report that corresponds to this change is 4482696.

Java 2D

New methods for managing accelerated memory

On some systems, the memory available for accelerated images is very limited. The images created with VolatileImage are sometimes stored in this type of memory. An offscreen image that is the same size of the display might occupy all of the memory not already used by the onscreen image. Prior to this release, users of accelerated offscreen images could not predictably flush an image in accelerated memory that is no longer needed. The new GraphicsDevice.getAvailableAcceleratedMemory method returns the number of bytes of available accelerated memory. The new VolatileImage.flush method releases all system resources consumed by the offscreen image.

The bugtraq report that corresponds to this change is 4424958.

Java Platform Debugger Architecture

Support For Debugging Other Languages

The Java Platform Debugger Architecture has been extended so that non-Java programming language source, which is translated to Java programming language source, can be debugged in the future. The table below describes the new APIs and APIs with comments that have changed. These JPDA API changes have been added at the request of the Expert Group for JSR-045 "Debugging other Languages". JSR-045 is defining a full framework for debugging other languages on top of the Java VM. The JPDA API changes have been reviewed and agreed to by the JSR-045 Expert group.

New APIs APIs with Changed Comments
JVMDI
GetSourceDebugExtension  
JDWP - ReferenceType (2) Command Set
SourceDebugExtension Command (12)  
JDWP - VirtualMachine (1) Command Set
SetDefaultStratum Command (19)  
JDI - VirtualMachine interface
void setDefaultStratum(String stratum)  
String getDefaultStratum()  
JDI - ReferenceType interface
String sourceNames(String stratum) String sourceName()
String sourcePaths(String stratum)  
List allLineLocations(String stratum, String sourceName) List allLineLocations()
List locationsOfLine(String stratum, String sourceName, int lineNumber) List locationsOfLine(int lineNumber)
List availableStrata()  
String defaultStratum()  
String sourceDebugExtension()  
JDI - Method interface
List allLineLocations(String stratum, String sourceName) List allLineLocations()
List locationsOfLine(String stratum, String sourceName, int lineNumber) List locationsOfLine(int lineNumber)
JDI - Location interface
  class comment (strata defined)
int lineNumber(String stratum) int lineNumber()
String sourceName(String stratum) String sourceName()
String sourcePath(String stratum)  
String sourcePath()  

Swing

Ability to disable Swing DropTarget

In 1.4 Swing added support for a TransferHandler on JComponent. Once set this will add a DropTarget to the JComponent. As adding a DropTarget may affect existing applications there needs to be a way to turn off registration of this DropTarget.

To address this issue, this API change updates the specification of javax.swing.JComponent.setTransferHandler.

The bug report that corresponds to this change is 4485914. This change supersedes RFE 4422171.

JList.getFirstVisibleIndex() & getLastVisibleIndex() in RTL orientation

The javax.swing.JList.getFirstVisibleIndex method previously always returned the index of the cell in the upper-left corner of the JList regardless of the list's component orientation. This was very unnatural in right-to-left component orientation and it's desirable that this method returns the index of the cell in the upper-right corner. The javax.swing.JList.getLastVisibleIndex methods have been changed likewise. It now returns the index of the cell in the lower left corner in right-to-left component orientation.

The bug report that corresponds to this change is 4485772.

JList offers option to layout horizontally then vertically

As per 4308384 JList now supports laying out vertically, then horizontally. It should also support laying out horizontally then vertically. To accomodate, this API change adds the following constants to JList: The following methods in JList have updated specifications: The following method specification in javax.swing.plaf.basic.BasicListUI has also been updated:

The bug report that corresponds to this change is 4460016.

TransferHandler Actions registered by UI

As part of our new work in merlin support for drag and drop was added to Swing. As drag and drop is esentially another way for the user to copy/paste data Swing provided bindings in its Action infrastructure to accomodate this. In order for the UIs to offer the ability to override these Actions, as well as the end user, the UI should be installing the Actions. In order to do this we now expose methods to obtain these Actions.

This API change adds the following to javax.swing.TransferHandler

The bug report that corresponds to this change is 4460011.

JTabbedPane.remove(Component) can throw IllegalArgumentException

As per 4287053 JTabbedPane was modified to throw exceptions in a method that it previously didn't. As this is causing NetBeans problems, this API change reverts the behavior.

See the javadoc for javax.swing.JTabbedPane.remove

The bug report that corresponds to this change is 4454342.

JFormattedTextField constants now follow java naming conventions

The following constants (introduced in 1.4 Beta) defined by JFormattedTextField previously did not follow the java naming conventions: 
    public static final int CommitValueOnFocusLost = 0;
    public static final int CommitOrRevertValueOnFocusLost = 1;
    public static final int RevertValueOnFocusLost = 2;
    public static final int PersistValueOnFocusLost = 3;
These constants have been changed to: 
    public static final int COMMIT = 0;
    public static final int COMMIT_OR_REVERT = 1;
    public static final int REVERT = 2;
    public static final int PERSIST = 3;

The bug report that corresponds to this change is 4468474.

JFormattedTextField should treat replace as an atomic edit

The swing text components use the class javax.swing.text.Document to model the text. This class exposes two methods to manipulate the content, insertString and remove. Replacing text is then handled as two operations, remove and then an insert. This can trip up JFormattedTextField. For example if validation happens on every edit the initial remove may not result in a valid edit and thus not be allowed, where as if the replace operation was seen as one edit it may be allowed.

The following has been added to AbstractDocument:

Similarly javax.swing.text.DocumentFilter has the new method

And javax.swing.text.DocumentFilter.FilterBypass has the new method:

The bug report that corresponds to this change is 4431047.

RTL component orientation, Tab movement is always Left To Right

The fix for 4337273 introduced new behavior for a component's setLocale method. This behavior was intended to apply to all Swing components. It was implemented by overriding java.awt.Component.setLocale in javax.swing.JComponent.setLocale. Unfortunately, the original proposal failed to recognize that a number of Swing components aren't subclassed from JComponent. These components are JFrame, JDialog, JWindow and JApplet.

This API change consists of the following:

In javax.swing.JApplet, javax.swing.JDialog, javax.swing.JFrame and javax.swing.JWindow, override java.awt.Component.setLocale(Locale) and document the effect of Locale changes on other locale related properties.

The bug report that corresponds to this change is 4419914.

ColorChooserPanels now have the ability to specify a mnemonic

This API change consists of the following:

javax.swing.colorchooser.AbstractColorChooserPanel now has the following new methods:

javax.swing.colorchooser.DefaultRGBChooserPanel now overrides the following methods to look up the value from the defaults table: The bug report that corresponds to this change is 4415678.

Specification update for JPopupMenu.insert(Action a, int index)

JPopupMenu.insert(Action a, int index) throws IllegalArgumentException when index is negative. However, the javadoc for this method previously failed to mention any exceptions. Behavior at null Action was also unspecified. The specification for this method has been updated to address these issues.

The bug report that corresponds to this change is 4389492.

JFormattedTextField and related classes are now Serializable

JFormattedTextField and the classes introduced with it previously were not serializable. This API change makes javax.swing.text.DefaultFormatter, javax.swing.text.DefaultFormatterFactory, and javax.swing.JFormattedTextField.AbstractFormatter implement java.io.Serializable.

The bug report that corresponds to this change is 4383386.

JWindow constructors introduced in 1.3 are not consistant with existing constructors

For 1.3 a handful of constructors were added to JWindow to support multi-headed configuration. Two of these take a Window argument. Unfortunately they are not consistant with the existing JWindow constructors, in that if the Window argument is null, they should use the Swing shared offscreen Frame.

This API change updates the javadoc spec to reflect that this no longer throws an IllegalArgumentException, but instead uses shared parent if null.

In javax.swing.JWindow.java:

The bug report that corresponds to this change is 4370840.

Added mnemonics to tabbed panes

Keyboard accessibility to tabbed panes is awkward for people with disabilities. Adding mnemonics to tabbed panes makes keyboard navigation much easier.

This API change adds the following to javax.swing.JTabbedPane:

The bug report that corresponds to this change is 4284674.

Floating toolbar now placed in JDialog on Windows

JToolBar, when dragged out of its container, was previously placed into an instance of JFrame. An instance of JDialog seems to be a more reasonable container. This API change consists of the following:

Class javax.swing.plaf.basic.BasicToolBarUI:

The bug report that corresponds to this change is 4231629.

New set/getIconTextGap methods in javax.swing.AbstractButton

AbstractButton, the superclass of the button implementations in Swing, allows developer to specify an Icon and text to draw. It previously did not allow the developer to specify the amount of space as JLabel does. This API change adds the following methods to javax.swing.AbstractButton: The bug report that corresponds to this change is 4079889.

AbstractButton.configurePropertiesFromAction now honors ACTION_COMMAND_KEY Property

The bugtraq report that corresponds to this change is: 4457940.

Previously, the AbstractButton methods configurePropertiesFromAction(Action) and configurePropertiesFromAction(Action, String[]) did not honor the ACTION_COMMAND_KEY property. That has now been addressed. This affects the javadoc for the configurePropertiesFromAction methods in the following subclasses of AbstractButton:

Further support for new AbstractDocument.replace method

The bugtraq report that corresponds to this change is: 4458513.

As part of RFE 4431047, a replace method was added to AbstractDocument. In order to allow this method to call remove and insertString (the only methods defined in the interface for mutating a Document), the restrictions on when writeLock may be invoked have been relaxed. This allows replace to be compatible with old versions of AbstractDocument that only override remove and insertString.

JPopupMenu.setVisible(true) now throws HeadlessException in Headless mode

The bugtraq report that corresponds to this change is: 4401222.

When the new headless mode was introduced, JPopupMenu.setVisible(true) was implemented to throw NullPointerException when called in headless mode. It has now been fixed to throw HeadlessException instead, to indicate that this operation cannot be performed in headless mode.

DefaultTableModel now allows a null for name argument

The bugtraq report that corresponds to this change is: 4474094.

The methods DefaultTableModel.addColumn(Object) and DefaultTableModel.addColumn(Object, Vector) did not previously allow null for the name argument - they threw an IllegalArgumentException. As it is possible to set the column name to null via other means (using constructors, or directly manipulating the field), the addColumn methods now also allows a null value.

JFrame, JDialog, and JApplet no longer override processKeyEvent

The bugtraq report that corresponds to this change is: 4462408.

Swing supports the option of registering key bindings on JComponents. In previous releases it was necessary for Swing top level components ( JFrame, JDialog, and JApplet) to override processKeyEvent (defined in java.awt.Component) to activate these bindings if the focus was ever on one of these top level components. With the addition of java.awt.KeyEventPostProcessor and Swing taking advantage of this ( RFE 4389332), it is no longer necessary for these methods to be overridden in the Swing top level components. As of this release, these methods have been removed at the top level and are now inherited.

Document Headless exceptions for JWindow constructors

The bugtraq report that corresponds to this change is: 4483258.

Though the headless mode was added to this release, two JWindow constructors did not indicate that HeadlessException may be thrown. This has been fixed in the doc for Window(Window, GraphicsConfiguration) and JWindow(GraphicsConfiguration).

Delayed Drag-and-Drop class loading for Swing/AWT

If you add a dropTarget to a parent Container, and one of the children also adds a dropTarget to itself, the parent Container will not get notification. Because of the new Drag-and-Drop support, JTextComponents add dropTargets to themselves, which affects the dropTarget of any parent Containers of the JTextComponents. This should not normally be a problem, but it is possible that it will cause backward compatibility problems for some existing applications. To address the possibility of backward compatibility problems, the Swing implementation now recognizes system property suppressDropSupport. The value of this property is "false" by default. For applications in which the new drag-and-drop support causes backward incompatibility problems related to drop targets, this system property's value can be set to "true". No change has been made to the public API.

The bug report corresponding to this change is 4422171.

VM

Signal chaining facility

The Java 2 SDK, Standard Edition, (J2SDK) v1.4 contains a new signal chaining facility. Signal chaining enables the Java Platform to better interoperate with native code that installs its own signal handlers.

The signal-chaining facility has two components.

The signal-chaining facility was introduced to remedy a problem with signal handling in previous versions of the VM. Prior to version 1.4, the VM would not allow pre-installed signal handlers for SIGBUS, SIGSEGV, SIGILL, SIGFPE, SIGPIPE, and SIGUSR1. Those signal handlers could conflict with the signal handlers used by the VM. An application cannot change signal handlers itself, for example in JNI code, because then some signals generated by the VM would not be handled by the VM.

The new signal-chaining facility in J2SDK 1.4 supports pre-installed signal handlers by saving any preinstalled signal handlers at the time the VM is created. If the signals are raised later, the VM invokes the pre-installed handler.

The signal-chaining facility also links and loads shared library libjsig.so with applications. This library ensures that calls such as signal(), sigset(), and sigaction() are intercepted so they won't actuall replace the VM's signal handlers. Instead, these calls will save the new signal handler. Later when the signal is raised, the VM will call into libjsig.so to retrieve and invoke the saved handler.

The signal-chaining facility was introduced to address Request for Enhancement number 4381843.

Internationalization

Revised Member Names in java.text.Bidi

The following members of class java.text.Bidi have been renamed in the Beta 2 release: 
FLAG_DIR_DEFAULT_LTR -> DIRECTION_DEFAULT_LEFT_TO_RIGHT
FLAG_DIR_DEFAULT_RTL -> DIRECTION_DEFAULT_RIGHT_TO_LEFT
FLAG_DIR_LTR -> DIRECTION_LEFT_TO_RIGHT
FLAG_DIR_RTL -> DIRECTION_RIGHT_TO_LEFT
isLTR -> isLeftToRight
isRTL -> isRightToLeft
baseIsLTR -> baseIsLeftToRight

This change was introdoced to address bug 4421986.

SimpleDateFormat pattern checking

The java.text.SimpleDateFormat class now checks its pattern in the consturtor or the applyPatttern method rather than during formatttin and parsing, and may thus throw exceptions for null or invalid patterns earlier. This change was made for 4326988.

Reflection
The specifications for java.lang.reflect's Method.invoke() and Constructor.newInstance() APIs are effectively descriptions of the implementation in the Classic VM. In particular, they specify an order of operation of certain necessary run-time checks to ensure that the invocation or instantiation may proceed. It certain implementations of these APIs it is more efficient to reorder some of these run-time checks, which can result in a different exception being thrown than in the Classic VM implementation if more than one of the run-time checks would fail. (See bug 4457255.)

The preferred API style in the Java libraries at large is to leave unspecified which exception will be thrown if the conditions allow more than one to be thrown. This change respecifies Method.invoke() and Constructor.newInstance() to follow this style.

The bug report associated with this change is 4462062.

Security

JSSE API Specification Clarifications

All affected classes are in the javax.net.ssl package.

HttpsURLConnection has several methods which assume a connection and handshaking has already occurred before they are called. Previously, nothing was specified if these methods are called before the connection is made. In each case, we're adding an IllegalStateException (Unchecked RuntimeException) to handle this situation:

This is directly analogous to the behavior of other methods on java.net.URLConnection which throw IllegalStateException if they are called before the connection is made.

HttpsURLConnection had two other issues. If someone tries to set the default or per-instance hostname verifiers and/or SSLSocketFactories, nothing was specified if the argument is null. This has been changed to return IllegalArgumentException.

In the SSLServerSocket, the following behavior was always implied, but never specified. The following description has been added to the class description: 

 * SSLServerSockets contain several pieces of state data
 * which are inherited by the SSLSocket at
 * SSLSocket creation.  These include data
 * such as the enabled cipher suites, whether client
 * authentication is necessary, and whether created sockets should
 * begin handshaking in client or server mode.  The state 
 * inherited by the created SSLSocket can be
 * overriden by calling the appropriate methods before handshaking
 * begins.

and in each method which is affected by this:

we've added the following text: 

     * SSLSockets inherit this setting.

SSLSockets.setEnabledCipherSuites() throws an IllegalArgumentException if one of the listed ciphersuites is not supported. SSLServerSocket does the same, but this was never documented.

SSLServerSocket.setNeedClientAuth previously said that "By default, clients do not need to provide authentication information."

That was bogus and has been removed. When the SSLSockets are created from the SSLServerSockets, they inherit the data values, and SSLSocket was never documented to have this behavior.

It is up to the creators of the sockets to decide what the default settings are.

In SSLSocket.setUseClientMode() the intent was that once the socket has done it's handshaking, the mode is permanently set on the socket and cannot be changed. This was previously misdocumented. Its method specification has been updated.

This issue is directly related to the previous.

In SSLSocket.setNeedClientAuth()/setWantClientAuth(), we have removed the IllegalArgumentException if the socket is not in server mode.

setWantClientAuth() is a method new to merlin, there is no problem here. Since this is a runtime Exception, there are no binary backward compatility issues with setNeedClientAuth.

In SSLServerSocket.setEnabledCipherSuites, null was specified to accept system defaults. This was a bug, and has been taken out.

This was never implemented in any of the Reference implementations.

In SSLSocket, the specification of when handshaking begins has always been implied, but was never previously stated. We have updated the class description to be more specific. The same applies for the getSession method.

SSLSession.getValue()/putValue()/removeValue() now throws IllegalArgumentException when presented with null arguments.

SSLSession.getValueNames() was underspecified in that it didn't specify what should be returned if there are no objects bound into the session.

In SSLContext.init(KeyManager[] km, TrustManager[] tm, SecureRandom random), it was never stated as to what would happen if you passed in several keymanagers of the same underlying type. For example, if 3 X509KeyManagers were passed in, should each of the three be consulted in order, or should only the first be used. The design originally intended that only the first instance of a particular type of key or trust manager be used. For example, if the application passes in 3 key managers which all implement the X509KeyManager interface, only the first would be used by the X509KeyManager infrastructure.

Some of the X509KeyManager & X509TrustManager methods previously did not specify what to return on error conditions. To be consistent with other methods in these classes, null should is now returned.

X509KeyManager.getCertificateChain()/getPrivateKey() now specify what to do if the aliases don't exist:

X509TrustManager.getAcceptedIssuers() previously didn't specify what to do there are no accepted issuers. In this case, it's perfectly acceptable to have a possibly empty array, so we now specify this.

These changes were made as part of enhancement number 4423074.

New methods in X509Certificate

Extended key usage field is used in X509v3 certificate to indicate one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension field. RFC 2459: "Internet X. 509 Public Key Infrastructure Certificate and CRL Profile" specifies that if extended key usage field is flagged as critical, applications must check to make sure the certificate is only used for a purpose consistent with its setting.

In order to fix 4427888, we need to access this field.

Previously, there was no public API in java.security.X509Certificate to obtain information from the extended key usage field. This API change adds a new public method to return such information.

We also change the exception thrown by two new methods introduced in Merlin to be consistent with the newly proprosed getExtendedKeyUsage method signature.

API Change:

Add the following method in java.security.cert.X509Certificate:

The following two methods are introduced in Merlin. They used to throw UnsupportedOperationException. After evaluating getExtendedKeyUsage method, we've decided to supply default implementations for them as well. Thus makes it necessary for these two methods to throw CertificateParsingException. This is also more consistent with the signature of getExtendedKeyUsage method.

This fix was done as part of enhancement 4427888.

Fix/improve exceptions thrown by java.security.cert.TrustAnchor

A few improvements/fixes have been made to the exceptions thrown by the TrustAnchor constructors:
  1. The constructors previously threw InvalidAlgorithmParameterException which was not appropriate to the abstraction of this class, since it is not an algorithm.

    This API change makes them throw IllegalArgumentException (an unchecked exception) instead, since these error cases are due to invalid values being passed in.

  2. TrustAnchor(String, PublicKey, byte[]) should also throw an exception if the caName is incorrectly formatted (not RFC 2253 compliant).
API changes:
  1. Changed TrustAnchor(X509Certificate, byte[]) to not throw InvalidAlgorithmParameterException and declared it to throw IllegalArgumentException instead (only in javadoc)
  2. Changed TrustAnchor(String, PublicKey, byte[]) to not throw InvalidAlgorithmParameterException and declared it to throw IllegalArgumentException instead (only in javadoc). Also changed it to throw an IllegalArgumentException if the caName parameter is incorrectly specified.
This was done as part of enhancement number 4475114.

X500Principal, X509Certificate and X509CRL unnecessarily threw checked exceptions

1. javax.security.auth.x500.X500Principal has 2 constructors and 1 method that previously threw checked exceptions, but do not need to:

in the case of the constructors, if the input name is incorrectly formatted or improperly specified, the documentation now specifies that an IllegalArgumentException will be thrown.

in the case of getEncoded, this method should normally succeed. Failure would constitute a rare occurrence and would warrant a RuntimeException to be thrown.

2. java.security.cert.X509Certificate has 2 methods that previously threw checked exceptions, but do not need to:

these methods should normally succeed. Failure would constitute a rare occurrence and would warrant a RuntimeException to be thrown.

3. java.security.cert.X509CRL has 1 method that previously threw a checked exception, but does not need to:

This method should normally succeed. Failure would constitute a rare occurrence and would warrant a RuntimeException to be thrown.

The above methods have been updated to address these issues.

This was done as part of enhancement number 4475278.

X509Certificate.getSubject* methods specification update

java.security.cert.X509Certificate contains two methods retrieving the Subject DN from the certificate: neither previously documented the correct behavior if the subject value is empty. The above methods now document that they will return java.security.Principal objects whose getName() implementations return an empty string ("") if the subject value is empty.

This was done as part of enhancement number 4474914.

X509Certificate now returns X500Principal

Previously, when applications would call: 
    java.security.Principal getIssuerDN()
    java.security.Principal getSubjectDN()

the returned class was vendor-specific and therefore applications can not interoperate efficiently. By returning the new public javax.security.auth.x500.X500Principal class, applications can rely on a common public X500Principal class.

getIssuerX500Principal has also been added to X509CRL.

This API change involves the following:

X509Certificate:

X509CRL:

This was done as part of enhancement number 4433469.

X500Principal equals & hashCode specification updates

The equals and hashCode methods of javax.security.auth.x500.X500Principal were previously underspecified.

There were not enough details in the javadoc for these methods for a vendor to produce an interoperable implementation that supports the general contract of the Object.equals and hashCode methods.

A correct DN equality implementation is crucial for applications that depend on it for security purposes, such as issuer/subject name chaining in the PKIX certpath validation algorithm and authorization checks in JAAS.

This API change specifies a canonical String representation of an X.500 Distinguished Name. The equals and hashCode method descriptions have been changed to depend on the canonical format and as a result preserve the general contract of Object.equals and hashCode.

This was done as part of enhancement number 4459925.

New X500Principal constructor

This API change adds an X500Principal(InputStream) constructor which reads an ASN.1 DER encoded X500Name from the InputStream and leaves the pointer at the next available byte in the InputStream. More often than not, a user will be reading the contents of an X.509Certificate from an InputStream - having a constructor that reads the X500Name from anywhere in the stream is very useful.

This was done as part of enhancement number 4426033

JSSE (JavaTM Secure Socket Extension)

API to set specific protocol versions for SSLServerSocket

As part of resolving another RFE 4273544 (JSSE Request for function forceV3ClientHello), we have provided APIs to enable specific protocol(s) for an SSLSocket. This RFE is to provide a similar API for SSLServerSockets.

Please see RFE 4479741 Need an API to set specific protocol versions for SSLServerSocket

This API change adds the following methods to javax.net.ssl.SSLServerSocket.

This was done as part of enhancement number 4479741.

SSLSessionContext now accessible from SSLContext

A SSLSessionContext represents the set of SSLSessions available for reuse during the handshake phase of the establishment of new SSLSockets.

In the previous JSSE API, a SSLSessionContext could only be obtained from a SSLSession, which is available after the handshake negotiation is over.

This API change adds two new methods to the SSLContext class to obtain the SSLSessionContext instances for the client and server SSLSession caches associated with the SSLContext.

javax.net.ssl.SSLContext

SSLContextSpi.java

This was done as part of enhancement number 4473210.

New methods for selecting secure socket protocols

New methods were added to SSLSocket and SSLServerSocket to allow developers to select exactly which secure socket protocols (such as SSLv3 and/or TLSv1) are to be used on the socket.

This was done as part of enhancement number 4478803.

Request for function forceV3ClientHello

Previously our JSSE implementation sent major version 3 and minor version 0 (TLS version 1.0) in the SSL connection request. For compatibility reasons, we sent a SSLv3 Hello request encapsulated in the SSLv2 Hello format.

There has been requests from customers to be able to send major version 3 and minor version 0 (SSL 3.0) as well as force using SSLv3 Hello instead of SSLv3 Hello request encapsulated in SSLv2 Hello format.

This API change adds the following new methods in javax.net.ssl.SSLSocket:

New methods in interface SSLSessionContext

There are new API methods in the javax.net.ssl.SSLSessionContext interface, which allow API users to set/get session cache size limit and a limit on session reuse timeout.

This was done as part of enhancement number 4366807.

Changes to X509TrustManager methods

The X509TrustManager isClientTrusted and isServerTrusted methods were renamed checkClientTrusted and checkServerTrusted, respectively. If the certificate chain is not trusted by this TrustManager, the checkClientTrusted and checkServerTrusted methods throw an exception rather than return a boolean (like the former methods did). This allows implementations to ascertain the underlying cause for failure of the trust decision. Note: X509TrustManager is new to the J2SDK, v 1.4.

This was done as part of enhancement number 4329114.

Changes to HostnameVerifier verify method

The negotiated SSLSession is now passed to the HostnameVerifier verify method instead of the received certificates. The SSLSession can then be queried for the negotiated ciphersuite, the exchanged certificates, and so on. Note: HostnameVerifier is new to the J2SDK, v 1.4.

This was done as part of enhancement number 4484246.

Networking

Unable to change default java.net.Authenticator implementation

Previously, the default authenticator used by the networking protocols in java.net could only be set once. The fix for this is to change the specification for Authenticator.setDefault() so that the default authenticator can be changed.

The bug report associated with this change is 4472302.

Unconnected socket creation methods

The javax.net.SocketFactory abstract class is used to create sockets. However SocketFactory previously had no API to permit an unconnected socket to be created. An unconnected socket is necessary in order to avail of the new java.net.Socket.connect method in Merlin permits a connect timeout to be specified.

This API change adds the following:

Class javax.net.SocketFactory:

Class javax.net.ServerSocketFactory:

The bug report associated with this change is 4414843.

HTTP digest authentication

The HTTP digest authentication implementation has been updated to support proxies as well as origin servers, and has also been updated to provide all capabilities defined in RFC2617, except for the auth-int mode.

A number of system properties have been added which modify the behavior of the digest authentication mechanism. These are identified in the Networking Properties document.

This change was made to address bug report 4432213.

Change to format of literal IPv6 addresses

In J2SDK 1.4 Beta 2, the specification is more explicit with regard to IPv6 literal addresses handling. This change was made in order to adhere to IETF standards RFC 2373 (IPv6 address architecture) and RFC 2732 (literal IPv6 addresses in URLs) as well as to minimize potential backward compatibility problems with existing applications that use newly acquired IPv6 addresses. The basic rule is: in the context of URL/URIs, including 'codebase' defined in the context of Java classloaders and SocketPermissions, RFC 2732 is followed; in all other cases, RFC 2373 is used.

In methods getByName(String host) and getAllByName(String host) of classes InetAddress and Inet6Address, if 'host' is specified in literal IPv6 address, the formats defined in RFC 2373 are accepted. For method getHostAddress(), the full form will be returned. The full form is defined as x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. This form is chosen because it is unambiguous when used in combination with other textual data.

In the URL and URI classes, for componentized constructors, when the 'host' parameter is expressed as a literal IP address, it should be enclosed in square brackets ('[' and ']') as specified by RFC 2732. However, the literal IPv6 address format defined in RFC 2373 is also accepted. The getHost() method returns the host name of this URL. The format of the host conforms to RFC 2732 -- for a literal IPv6 address, this method will return the IPv6 address enclosed in square brackets ('[' and ']').

In class SocketPermission, if the host specification contains a literal IPv6 address, the format defined in RFC 2732 should be used -- the IPv6 address should be enclosed in square brackets ('[' and ']'). However, to minimize backward compatibility problems with existing applications using IPv6 addresses, all unambiguous cases are resolved automatically by the class.

These changes were made to address bug reports 4440955 and 4451522.

Name change for getByAddr methods

New methods getByAddr introduced in the InetAddress and NetworkInterface classes in J2SE 1.4 Beta are called getByAddress in J2SE 1.4 Beta 2.

This change was introdoced to address bug 4469966.

New method URL.getDefaultPort

The Java Community Process maintenance review material for J2SE 1.4 Beta contained this item:
New method URL.getPort allows applications to obtain the default port number for a URL based on the scheme/protocol. The bug report associated with this change is 4332284.
This item contains a typo: the name of the new method is getDefaultPort rather than getPort.

Accessibility

New constant in javax.accessibility.AccessibleContext

This API change adds one static final String to javax.accessibility.AccessibleContext:

The bug report that corresponds to this change is 4491475.

New constants in javax.accessibility.AccessibleRole

Class javax.accessibility.AccessibleRole has the following new constants.

The bug report that corresponds to this change is 4487122.

New interface AccessibleExtendedTable

Assistive technologies for people with disabilities cannot map the row and column in a table to the index in the table using the javax.accessibility.AccessibleTable interface. Many assistive technologies need this information to display the table contents correctly.

This API change adds a new interface: javax.accessibility.AccessibleExtendedTable and the implementation of this interface in javax.swing.JTable.

The bug report that corresponds to this change is 4395722.

AccessibleExtendedComponent.getAccessibleKeyBinding

Interface AccessibleExtendedComponent has a new method, getAccessibleKeyBinding, to return key bindings associated with an object.

AccessibleRole New Constants

Class AccessibleRole contains the following new constants:

Accessibility Support for HTML Object Tags

This release adds accessibility support for HTML object tags. CTRL-t and SHIFT-CTRL-t navigate to the next and previous component, respectively, associated with an object tag in an HTML document. CTRL-SPACE activates the default action associated with the component.

Support for Tracking HTMLEditorKit Keyboard Link Traversal

Assistive technologies needed a way to track HTMLEditorKit keyboard link traversal. The constant AccessibleContext.ACCESSIBLE_HYPERTEXT_OFFSET was added to support this feature.

Assistive Technologies Property

The javax.accessibility.assistive_technologies property specifies the assistive technologies to load into the JVM.

Screen Reader Property

The javax.accessibility.screen_reader_present property, when set to true, lets the Java platform libraries know that a screen reader is present on the system. Application developers can check this property. If an application is self-voicing and a screen reader is present, developers can turn off the self-voicing.

Swing Component Interaction with IDEs

To make it easy for IDE's to allow developers to identify and set key accessibility properties, enhancement 4285960 has been implemented through changes to Javadoc comments by ensuring that there are suitable @beaninfo tag in the component source to identify the properties that are important to accessibility and should be exposed when introspection occurs.

Implement AccessibleJComboBox for the new JComboBox implementation

This enhancement, 4303297, was an implementation-only change, with no changes to the API.
Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.