Java Community ProcessSM Maintenance Review 2 for the JavaTM Platform, Standard Edition, Version 6

Introduction

This document provides descriptions of specification changes being made in version 6 of the Java^TM Platform, Standard Edition (Java^TM SE 6).

Version 6 includes a set of new Java Specification Requests (JSRs) that introduce major new functionality. This Maintenance Review does not cover new APIs defined through those JSRs; it documents only smaller changes made under the JCP Maintenance Review process. Moreover, this Maintenance Review does not cover updates to specifications that are contained in Java SE 6 but that are also available stand-alone. Separate Maintenance Reviews will be held for any changes to such specifications.

The descriptions in this document correspond to platform changes made since the release of Java SE 6 Beta. The specification change descriptions are provided for purposes of Java Community Process^SM public maintenance review.

Java SE 6 is a feature release containing significant API changes. The Java SE 6 specification requires a new Java Compatibility Kit (JCK).

Feedback

Please use the following address to provide review feedback on the specification changes described here.

java-se-6-jsr-review@sun.com

Change Descriptions

All specification changes that were made between Java SE 6 Beta and Java SE 6 RC, including trivial changes such as corrections of typographical errors and misspellings, are indicated in the following document, where insertions are conveniently shown in bold and deletions are shown in strike-thru:

Specification Difference Pages

The more significant specification clarifications are described in the following sections of this present document.

Core Libraries

• Beans
• Image
• I/O
• java.lang
• java.lang.management
• java.net
• java.text
• java.util
• java.util.concurrent
• JMX
• Security

User Interface

• AWT
• AWT (2D)
• Swing

Native Interfaces for Tools

• JNI
• JVMTI

Core Libraries

Beans

Define annotation to link constructor parameters to getters

In Java SE 6, the JMX API introduced an annotation that describes the properties supplied to a constructor. Such an annotation is not specific to JMX, but rather a natural extension to how a bean can describe the properties that are needed to create an instance when a no-argument constructor is not appropriate. Consequently, the annotation has been moved out of the JMX API into the beans package, so that the beans persistence mechanism no longer has dependencies on the JMX API.

The annotation javax.management.PropertyNames has been renamed to java.beans.ConstructorProperties. All classes that refer to it have been changed. Support for the annotation java.beans.ConstructorProperties has been added to the class java.beans.MetaData.

This change affects the following classes and methods:

• javax.management.MXBean
• javax.management.PropertyNames: 1 method
• java.beans.ConstructorProperties: 1 method
• java.beans.Encoder.getPersistenceDelegate(Class)
• java.lang.management.LockInfo.LockInfo(String,int)

The RFE report associated with this change is 6176120.

Note: The above changes to the JMX API (javax.management.*) are technically covered by the maintenance reviews of JSR 3, but they are listed here for convenience.

Image

javax.imageio: New ImageIO.getReaderFileSuffixes() method

The ImageIO class has convenience methods for querying the acceptable format names and MIME types associated with the various ImageReaders and ImageWriters. Previously, there were no parallel methods for querying file suffixes as well. These methods have been added in this release.

• javax.imageio.ImageIO.getReaderFileSuffixes()
• javax.imageio.ImageIO.getWriterFileSuffixes()

The RFE report associated with this change is 4703112.

I/O

I/O: Piped{InputStream,Reader} sets buffer size

Piped{InputStream,Reader} uses an internal buffer to store data coming into the pipe. This buffer size used to be fixed at 1024, which was a bottleneck for those applications that would have been better off had they used a different buffer size.

In this release, two new constructors have been added, that take a new parameter to set the pipe's buffer size:

• java.io.PipedInputStream.PipedInputStream(PipedOutputStream src, int pipeSize)
• java.io.PipedInputStream.PipedInputStream(int pipeSize)
• java.io.PipedReader.PipedReader(PipedWriter src, int pipeSize)
• java.io.PipedReader.PipedReader(int pipeSize)
• java.io.PipedInputStream.PIPE_SIZE

The RFE report associated with this change is 4028462.

I/O: Exception chaining constructors added to IOException

Previously, IOException did not have convenience constructors to use with the Exception Chaining feature, unlike many other exceptions. These constructors have now been provided, in the same way as for other subclasses of Throwable.

This change adds the following methods:

• java.io.IOException(String message, Throwable cause)
• java.io.IOException(Throwable cause)

The RFE report associated with this change is 5070673.

I/O: Fixed problem running java.exe in Lithuanian locale

Previously, calling String.toLowerCase() in the Lithuanian locale caused an exception to be thrown. String.toLowerCase() would call Normalizer to perform the locale-sensitive case-mapping, Normalizer would call Win32FileSystem.hashCode(), which would call Normalizer, thus creating an endless loop. In this release, the call to toLowerCase() has been changed to a call to toLowerCase(Locale.ENGLISH), which does not cause this circular code path.

This change affects the following method:

• java.io.File.hashCode()

The bug report associated with this change is 6344646.

I/O: Plugged security hole in the ObjectOutputStream.PutField.write method

The method ObjectOutputStream.PutField.write had a security hole: Untrusted code could use it to acquire references to internal objects of serializable classes whose custom writeObject methods use the ObjectOutputStream.PutField API.

This hole has been plugged by making ObjectOutputStream.PutField.write throw an IllegalArgumentException if the argument is not identical to the enclosing ObjectOutputStream instance (which produced the PutField).

The method java.io.ObjectOutputStream.PutField.write is deprecated.

The bug report associated with this change is 6441274.

java.lang

java.lang: Completed generification of java.lang.Class

Previously, a few methods in java.lang.Class returned arrays of raw types, raw Class objects and raw Constructor objects. Raw types should not be used, so this has now been corrected so that Class returns Foo<?>[] instead of a raw Foo[].

When java.lang.Class was first generified in the J2SE platform 5.0, there were different rules for combining generics and arrays. The rules have since been improved to permit the returning arrays of wildcards. Unfortunately, previously getConstructors could not return Constructor[] since it would not be type safe. This has now been corrected.

This change affects the following three methods:

• java.lang.Class.getInterfaces()
• java.lang.Class.getClasses()
• java.lang.Class.getConstructors()

The bug report associated with this change is 6229784.

java.lang.reflect: Array.newInstance is now a var-arg method

Previously, the last argument of the method java.lang.reflect.Array.newInstance(Class<?>, int[]) was an array that was treated as a list of numbers. In other words, the array was used for aggregation purposes only. In this release, this has been made a var-arg method.

This change affects the following method:

• java.lang.reflect.Array.newInstance(Class, int[])

The bug report associated with this change is 5041975.

java.lang: Parameters in Class and reflect methods made generic

A few of the methods in java.lang.Class and java.lang.reflect.Member had raw types in their signatures. This violated Sun's advice to use generics instead of raw types in order to produce type-safe code.

The signatures of the following methods have been made generic:

• java.lang.Class.getMethod
• java.lang.Class.getConstructor
• java.lang.Class.getDeclaredClasses
• java.lang.Class.getDeclaredConstructors
• java.lang.Class.getDeclaredMethod
• java.lang.Class.getDeclaredConstructor
• java.lang.reflect.Member.getDeclaringClass

The bug report associated with this change is 6404663.

java.lang.management

java.lang.management: New API to return system load average

The system load average is a useful metric for automated tuning. A new method has been added to java.lang.management.OperatingSystemMXBean to return the system load average.

This change adds the following method:

• java.lang.management.OperatingSystemMXBean.getSystemLoadAverage

The RFE report associated with this change is 6336608.

java.net

java.net: URI classes rolled back to the version from the J2SE Platform 5.0

The Java SE 6 platform beta 1 release supported an IRI feature in the class java.net.URI class and conformed to the new URI specification, RFC 3986. However, RFC 3986 is not entirely compatible with the old URI specification, RFC 2396, on which the J2SE platform 5.0 version of the URI class was based. Because of the specification conflicts between RFC 2396 and RFC 3986, in this release the URI API specification has been rolled back to the J2SE platform 5.0 API.

This change removes the following methods:

• java.net.URI.getRawHost()
• java.net.URI.toIRIString()

The bug report associated with this change is 6394131.

java.text

java.text: java.text.DateFormatSymbols.getZoneStrings cannot return an array with m less than 5

The specification for DateFormatSymbols.setZoneStrings() states that the argument must be a two-dimensional array of strings of size n by m, where m is at least 5. However, previously, applications could set the array with rows that have a length of less than 5. This has been corrected so that an IllegalArgumentException is thrown if the length of any row in newZoneStrings is less than 5.

This change affects the following method:

• java.text.DateFormatSymbols.setZoneStrings(java.lang.String[][])

The bug report associated with this change is 6412896.

java.util

java.util: New load(Reader)/store(Writer) interface for Properties class

Previously, the Properties class provided a pair of load/store methods, load(InputStream) and store(OutputStream, string), to input and output the String properties from and to persistent property storage (normally a property file). The Properties class has been extended to support the following scenarios:

• To support non-8859-1 encoding (mainly UTF8) for the Property file used in the ProperyResourceBundle class (see bug report 4919638).
• While the persistent storage behind the InputStream/OutputStream used to be a character-based interface (namely it used the primitive type "char"), instead of converting back and forth between a char stream and iso8859-1 byte stream, a Reader/Writer based load/store interface is preferable.

A new pair of load/store methods with character-based Reader/Writer parameters have been added in this release.

• java.util.Properties.load(Reader)
• java.util.Properties.store(Writer, String)
• java.util.Properties.load(InputStream)
• java.util.Properties.store(OutputStream, String)

The RFE report associated with this change is 4094886.

java.util: Added new java.util.Arrays.binarySearch(a, key, fromIndex, toIndex) methods

Previously, the java.util.Arrays class provided some utilities that operate on arrays of any type, but there was no way to parameterize over primitive types, so each of the methods needed a version for int, a version for float, and so on. It is also common to operate only on some range of elements within the array, so each of these methods needed one version for the entire array and another that operates on a range. However, binarySearch methods that operate on ranges did not previously exist, so they have been added in this release.

This change adds the following methods:

• java.util.Arrays.binarySearch(long[], int, int, long)
• java.util.Arrays.binarySearch(int[], int, int, int)
• java.util.Arrays.binarySearch(short[], int, int, short)
• java.util.Arrays.binarySearch(char[], int, int, char)
• java.util.Arrays.binarySearch(byte[], int, int, byte)
• java.util.Arrays.binarySearch(double[], int, int, double)
• java.util.Arrays.binarySearch(float[], int, int, float)
• java.util.Arrays.binarySearch(Object[], int, int, Object)
• java.util.Arrays.binarySearch(T[],int,int,T,Comparator)

The RFE report associated with this change is 4306897.

java.util: New compressed streams classes added

Previously, there was an input stream to inflate while reading compressed data (InflaterInputStream), but there was no input stream to deflate while reading uncompressed data. Likewise, there was an output stream to deflate while writing compressed data (DeflaterOutputStream), but no output stream that would inflate while writing compressed data.

All examples showing how to compress data before sending it over a network assumed users had an output stream that they could send the data over. If instead, they needed to send data as packets or using a third party API, there was no easy way to do so unless they wrote their own DeflaterInputStream and InflaterOutputStream classes. Such classes have been added to the platform in this release.

• java.util.zip.InflaterOutputStream: 9 methods, 5 fields
• java.util.zip.DeflaterInputStream: 12 methods, 5 fields

The RFE report associated with this change is 4679743.

java.util: Added UTF-8 based property resource bundles

For a long time, the Java SE platform has provided a properties file format that is based on ISO-8859-1, and also provided an escape mechanism for characters that cannot be represented in that encoding. Since J2SE 5.0, the platform has also provided an XML-based properties file format. This format does allow any character encoding to be used. However, XML files are harder to edit, and they take significantly longer to parse.

This release provides a new constructor that takes a Reader instance, so that the clients of the PropertyResourceBundle can provide their properties files in any encoding. This change depends on the equivalent change in the Properties class (see the entry for 4094886, New load(Reader)/store(Writer) interface for Properties class, above).

This change adds the following methods:

• java.util.PropertyResourceBundle(java.io.Reader)
• java.util.PropertyResourceBundle(java.io.InputStream)

The RFE report associated with this change is 6204853.

java.util: Locale defines new constant for the root locale (Locale(""))

The Locale class defines a new constant for the root locale, Locale("", "", ""), for use with the new ResourceBundle.Control API, and for convenience when creating documentation.

This change introduces a new static Locale instance for the root locale:

• java.util.Locale.ROOT

The RFE report associated with this change is 6277243.

java.util: Collection copy constructors made threadsafe

Changes have been made to the Vector, ArrayList, and PriorityQueue collection constructors that both make them accommodate traversals with different numbers of elements than the reported size(), and as a byproduct make them fail less often with concurrently modified non-concurrent ones.

This change affects the following classes:

• java.util.ArrayList
• java.util.Vector
• java.util.concurrent.PriorityQueue

The bug report associated with this change is 6347106.

java.util: java.util.Service name changed

Instances of the java.util.Service class do not represent a service, rather they represent a set of providers of a given service, or an entity that locates and instantiates such providers. Consequently, the class has been renamed to "ServiceLoader", and corresponding changes have been made to method names and the prose in the specification.

This change affects the following methods:

• lookup(Class<T>) becomes java.util.ServiceLoader.load(Class<S>)
• lookup(Class<T>, ClassLoader) becomes java.util.ServiceLoader.load(Class<S>, ClassLoader)
• lookupInstalled(Class<T>) beomes java.util.ServiceLoader.loadInstalled(Class<S>)

There are no substantive changes to the specifications of either the class or the methods. Changes to the prose of the specifications merely reflect the above renamings.

The bug report associated with this change is 6354623.

java.util: NavigableMap/NavigableSet refined

NavigableSet and NavigableMap were added to the Java SE 6 platform in the beta 1 release, to rectify deficiencies in SortedSet and SortedMap. Unfortunately, they did not quite solve the problems. There was no way to get a navigable descending view of a navigable collection. Furthermore, there was no way to get any partial view other than a half-open ascending set or map. These problems have been corrected in this release.

• In NavigableMap, the method Set<Map.Entry<K,V>> descendingEntrySet() has been replaced by NavigableMap<K,V> descendingMap().
• The three "partial view methods", NavigableMap<K,V> navigableHeadMap(K toKey), NavigableMap<K,V> navigableTailMap(K fromKey), and NavigableMap<K,V> navigableSubMap(K fromKey, K toKey) have added parameters to specify whether the endpoints are to be included in the returned view:
  • NavigableMap<K,V> headMap(K toKey, boolean inclusive)
  • NavigableMap<K,V> tailMap(K fromKey, boolean inclusive)
  • NavigableMap<K,V> subMap(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive)

  The removal of the "navigable" prefix here makes for more usable names.

• A new NavigableSet<E> descendingSet() method has been added.
• "Inclusive" parameters are added to the three "partial view" NavigableSet methods:
  • NavigableSet<E> headSet(E toElement, boolean inclusive)
  • NavigableSet<E> tailSet(E fromElement, boolean inclusive)
  • NavigableSet<E> subSet(E fromElement, boolean fromInclusive, E toElement, boolean toInclusive)

The RFE report associated with this change is 6415641.

java.util.concurrent

java.util.concurrent: CopyOnWriteArraySet and CopyOnWriteArrayList equals methods improved

The behavior has been improved of the CopyOnWriteArraySet.equals() and CopyOnWriteArrayList.equals() methods in the presence of concurrent modification of the collection, or of any another concurrent collection.

Previously, it was possible for x.equals(y) to spuriously return true even if no snapshots of x and y were ever equal, and it was also possible for NoSuchElementException to be thrown, in the presence of concurrent modification. The expected behavior of the CopyOnWriteArraySet methods is to operate on snapshots at the point of call. This means that CopyOnWriteArraySet methods should not call size(), and only then access its internal array. However, the implementation of equals(Object) inherited from AbstractSet did precisely that.

The implementation of CopyOnWriteArraySets has been improved so that if s1 and s2 are both CopyOnWriteArraySets, then s1.equals(s2) can only be true if a snapshot of s1 contains the same elements as a snapshot of s2. Similarly for CopyOnWriteArrayLists: l1.equals(l2) can only be true if a snapshot of s1 contains the same elements as a snapshot of s2.

Consequently, in this release the elements returned by an iterator always correspond to a snapshot, thus providing the correct properties.

This change affects the following methods:

• java.util.concurrent.CopyOnWriteArraySet.equals()
• java.util.concurrent.CopyOnWriteArrayList.equals()

The bug report associated with this change is 6330307.

java.util.concurrent: Concurrent collection iterators no longer throw ConcurrentModificationException

Previously, both the concurrent collection classes DelayQueue and PriorityBlockingQueue had iterators that threw ConcurrentModificationException in the presence of concurrent modification. This was inappropriate behavior.

In this release, these two classes iterate over a snapshot returned by toArray() instead of the underlying PriorityQueue.

This change affects the following methods:

• java.util.concurrent.DelayQueue.iterator()
• java.util.concurrent.PriorityBlockingQueue.iterator()

The bug report associated with this change is 6355327.

java.util.concurrent: New methods added to ReentrantReadWriteLock.WriteLock

ReentrantReadWriteLock.WriteLock has similar exclusive use and owner semantics to ReentrantLock. ReentrantLock has methods getHoldCount and isHeldByCurrentThread, but previously ReentrantReadWriteLock did not have such methods. This has been corrected in this release by adding equivalent methods to ReentrantReadWriteLock.WriteLock.

This change adds the following methods:

• java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock.getHoldCount()
• java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock.isHeldByCurrentThread()

The RFE report associated with this change is 6378321.

JMX

The specification changes in the Java SE 6 platform related to the JMX API will be covered in separate maintenance reviews of JSR 3 and JSR 160.

Security

Security: Delegated authentication now supported in the SASL API

Delegated authentication occurs when a user presents another user's credentials to an authority and is successfully validated. Delegated authentication enables a suitably trusted user to assume the identity of another. It is commonly used in Kerberos environments. Delegated authentication is now supported in the SASL API in the Java SE 6 platform.

A new property has been added to the existing set of SASL properties to enable a user's credentials to be directly transferred from an application to the SASL mechanism that performs the authentication. In addition, since JNDI (Java Naming and Directory Interface) uses SASL, this approach has the added advantage of supporting delegation from both JNDI-based applications and from SASL-based applications.

This change adds the following property:

• javax.security.sasl.CREDENTIALS

This property contains a mechanism-specific Java credential object. SASL mechanisms may examine the property's value (for example, by using the instanceof operator) to determine if it is a Java class that they support.

The RFE report associated with this change is 6350547.

AWT

AWT: MouseAdapter now implements MouseMotionListener and MouseWheelListener

The MouseAdapter class should implement all mouse-related interfaces, but previously, only MouseListener was implemented. With this enhancement, java.awt.event.MouseAdapter now also implements interfaces MouseMotionListener and MouseWheelListener.

The RFE associated with this change is 4453162. This enhancement was also made in Swing, with RFE 6416234.

AWT: Drag & drop action negotiation now honors the target's supported actions

During a DnD operation the drag source and the drop target send events to each other. One type of event that is delivered to the drag source is java.awt.dnd.DragSourceDragEvent. The DnD operation may end with one of the resulting drop actions: ACTION_MOVE, ACTION_COPY, ACTION_LINK, or ACTION_NONE.

The target drop action is one of DnDConstants that represents the drop action selected by the drop target.

The user drop action is one of DnDConstants that represents the intersection of the drop actions supported by the drag source and the drop action selected by the user. The user can select an action by pressing the modifier keys.

The expected resulting drop action is the intersection of the user drop action and the target drop action. When the DnD operation is in progress, the mouse cursor is updated according to the expected resulting drop action via the method java.awt.dnd.DragSourceContext.updateCurrentCursor().

The drop target can choose a target drop action that is not equal to the user drop action and perform the chosen action at the end of the DnD operation. Previously, the mouse cursor was NoDrop during the DnD operation. With this fix, the cursor is updated according to the target drop action, and the user drop action should not influence the cursor. Therfore, the visual feedback now matches the expected resulting drop action.

The changes are the following:

• The method java.awt.dnd.DragSourceDragEvent.getDropAction() returns the logical intersection of the target drop action and the set of drop actions supported by the drag source.
• The name of one argument of the method java.awt.dnd.DragSourceContext.updateCurrentCursor(int sourceAct, int targetAct, int status) has been changed.

The bug report associated with this change is 4869264.

AWT: Container.getComponentZOrder() is now non-final

There are certain situations where applications insert components between a Container and the Component being added as a child. For example, a subclass might want to take the passed Component, fetch its parent, and then call super.getComponentZOrder() passing the parent. Previously, this was not possible because Container.getComponentZOrder() was final and could not be extended.

With this enhancement, java.awt.Container.getComponentZOrder() has been made non-final.

The RFE associated with this change is 6333253.

AWT: Improve icon support in Windows

Previously, the AWT API allowed setting only one icon image for the Frame. In addition, icons could be specified for Frames only, not for Dialogs, which meant that owned dialogs inherited icons from parents and ownerless dialogs had the default Java icon.

This enhancement improves icon support by allowing multiple images of different sizes, by supporting transparency, and by ensuring that ownerless dialogs inherit from the parent frame.

The following new methods have been added:

• java.awt.Frame.getIconImage()
• java.awt.Frame.setIconImage(Image)
• java.awt.Window.getIconImages()
• java.awt.Window.setIconImages(List<Image>)
• java.awt.Window.setIconImage(Image)

The RFE associated with this change is 6339074.

AWT: Window() constructor throws HeadlessException instead of IAE in headless mode

Previously, the java.awt.Window(GraphicsConfiguration gc) constructor threw IllegalArgumentException in headless mode. That caused all subclasses (java.awt.Frame, java.awt.Dialog, javax.swing.JWindow, and others) to throw IAE also. With this fix, the constructor throws a separate exception, HeadlessException, which exists for this purpose.

In addition, IAE might have been thrown when constructing Java top-levels, that is, when the owner's graphics configuration is not from a screen device. Therefore, other constructors now also throw HeadlessException.

The following classes have been changed:

• java.awt.Window - 1 method
• java.awt.Frame - 2 methods
• java.awt.Dialog - 14 methods

The bug report associated with this change is 6366441.

AWT: SpashScreen.getGraphics() is now called createGraphics() and returns a Graphics2D

SplashScreen.getGraphics() returns a newly created graphics content for the splash screen overlay surface, which is in fact a BufferedImage. Previously, the method returned a Graphics type, and it was necessary to cast it to Graphics2D to work with alpha channel on the surface properly. With this fix, the method returns a Graphics2D type.

In addition, the method name has changed from getGraphics() to createGraphics() to reflect the fact that a new object is constructed.

The following changes have been made:

• java.awt.SplashScreen.createGraphics() has been added
• java.awt.SplashScreen.getGraphics() has been removed

The bug report associated with this change is 6372061.

AWT (2D)

AWT (2D): java.awt.geom.GeneralPath now has a double version

The java.awt.geom.GeneralPath class in Java 2D provides a flexible way to accumulate and use an arbitrary path composed of the supported PathIterator path segments. Previously, GeneralPath stored its coordinates in a float array, which did not provide enough precision for all applications. With this enhancement, a double variant of GeneralPath is added to the API.

The solution was to add a new base class Path2D with two inner class subclasses, Path2D.Float and Path2D.Double, which represent implementations with float and double precision respectively. The legacy GeneralPath class is now an empty subclass of Path2D.Float. The new Path2D classes are close enough in design to the original GeneralPath design that the GeneralPath class can inherit all of its old implementation from the new classes with only its static members and constructors remaining.

In addition, the GeneralPath class was and continues to be final, but the new Path2D classes can be extended to add functionality. However, note that all implementation methods are final to prevent interference with the operation of a system base class.

The new classes are the following:

• java.awt.geom.Path2D
• java.awt.geom.Path2D.Float
• java.awt.geom.Path2D.Double

The RFE associated with this change is 4172661.

AWT (2D): java.awt.geom classes now implement Serializable

The objects in java.awt.geom have now been made Serializable.

The following inner classes now implement default Serialization:

• java.awt.geom.Rectangle2D.Float
• java.awt.geom.Rectangle2D.Double
• java.awt.geom.Point2D.Float
• java.awt.geom.Point2D.Double
• java.awt.geom.QuadCurve2D.Float
• java.awt.geom.QuadCurve2D.Double
• java.awt.geom.CubicCurve2D.Float
• java.awt.geom.CubicCurve2D.Double
• java.awt.geom.Ellipse2D.Float
• java.awt.geom.Ellipse2D.Double
• java.awt.geom.Line2D.Float
• java.awt.geom.Line2D.Double
• java.awt.geom.RoundRectangle2D.Float
• java.awt.geom.RoundRectangle2D.Double

The following inner classes now implement default Serialization with an additional field from their parent class manually serialized:

• java.awt.geom.Arc2D.Float
• java.awt.geom.Arc2D.Double

The following class now implements a totally custom Serialization format:

• java.awt.geom.GeneralPath

The RFE associated with this change is 4263142.

AWT (2D): New Paint classes for multi-stop gradients

Previously, the GradientPaint class allowed for smooth gradients between two (and only two) colors, which was not sufficient for many applications. This enhancement adds two new concrete implementations of the Paint interface: LinearGradientPaint and RadialGradientPaint. LinearGradientPaint is a more flexible version of GradientPaint that allows for multi-stop gradients involving two or more colors. RadialGradientPaint is similarly flexible, except instead of interpolating the colors in a linear fashion, the colors radiate out from a center point.

In addition, there is a non-user-extendable parent class, MultipleGradientPaint, which contains shared API and implementation. This class also contains two public enums, CycleMethod and ColorSpaceType, which are used to control the behavior of LinearGradientPaint and RadialGradientPaint.

The new classes are:

• java.awt.MultipleGradientPaint
• java.awt.LinearGradientPaint
• java.awt.RadialGradientPaint

The RFE associated with this change is 6296064.

AWT (2D): java.awt.Rectangle methods now protect against overflow conditions

Previously some of the java.awt.Rectangle methods could experience 32-bit integer overflow during their calculations and also when trying to store their answers back into the 32-bit fields. With this enhancement, these methods are now protected against overflow in intermediate calculations and specify the behavior of how the final results will be truncated to 32-bit resolution when stored back into a Rectangle object.

The following methods are affected:

• java.awt.Rectangle.add(int, int)
• java.awt.Rectangle.add(Rectangle)
• java.awt.Rectangle.grow(int, int)
• java.awt.Rectangle.setRect(double, double, double, double)
• java.awt.Rectangle.translate(int, int)
• java.awt.Rectangle.union(Rectangle)

The bug report associated with this change is 6423143.

Swing

Swing: Added LINK support to Swing DnD

Swing now has support for linked data in a drag and drop operation.

The changes are the following:

• The new public field javax.swing.TransferHandler.LINK specifies that data should be linked in a drag and drop operation.
• The action parameter in the method javax.swing.TransferHandler.exportAsDrag(JComponent, InputEvent, int) is documented to include LINK as a possible transfer action initially requested.
• The method javax.swing.TransferHandler.getSourceActions(JComponent) is documented to include LINK as a possible transfer action and to clarify that the method returns a bitwise-or combination of transfer actions.

The RFE associated with this change is 4726410.

Swing: Added a default FileFilter class to JFileChooser

JFileChooser allows users to choose among developer-supplied file filters by providing a FileFilter object. Previously, the FileFilter class was abstract, with no default implementation.

This enhancement provides a default implementation of the FileFilter class. This allows the developer to easily create a FileFilter implementation that filters file types based on file name extensions.

The changes are the following:

• The new class javax.swing.filechooser.FileNameExtensionFilter is the default implementation of the FileFilter class.
• The documentation for the javax.swing.JFileChooser class now specifies the new default implementation class instead of an implementation previously supplied with the examples.
• The documentation for the javax.swing.filechooser.FileFilter class now specifies the new default implementation class instead of an implementation previously supplied with the examples.

The RFE associated with this change is 4800473.

Swing: Improvement to Swing action framework customization

This enhancement makes it easier to customize how a component should respond to property changes on their associated actions. In four classes, the actionPropertyChanged callback method has been changed to be protected instead of package private. This method updates the state of the object in response to property changes in the associated action.

The changes are the following:

• javax.swing.AbstractButton.actionPropertyChanged(Action action, String propertyName)
• javax.swing.JComboBox.actionPropertyChanged(Action action, String propertyName)
• javax.swing.JMenuItem.actionPropertyChanged(Action action, String propertyName)
• javax.swing.JTextField.actionPropertyChanged(Action action, String propertyName)

The RFE associated with this change is 6328849.

Swing: Provided way to automatically create RowSorter for JTable

This enhancement added two new methods to create appropriate sorting objects. The "set" method creates a TableRowSorter object as the table's row sorter; as long as the autoCreateRowSorter remains true, the method creates a new TableRowSorter object every time the model changes. The "get" method returns true if a new RowSorter object should be created when the model changes.

The two new methods are:

• javax.swing.JTable.setAutoCreateRowSorter(boolean)
• javax.swing.JTable.getAutoCreateRowSorter()

The RFE associated with this change is 6341541.

Swing: JtabbedPane now fires state changed events

There were previously certain cases where JTabbedPane did not fire state changed events, and tab selection went to the wrong place. For example, deleting a tab before the selection caused the selection to move to the next tab and no event was fired. In addition, when a Page was selected in JTabbedPane and a property change event was fired to indicate the change to the accessible name, JTabbedPane's accessible name did not really change.

These problems have been corrected as follows:

• The method javax.swing.JTabbedPane.fireStateChanged() is called each time there is a change to either the selected index or selected tab in the JTabbedPane. The method sends a ChangeEvent, with this JTabbedPane as the source, to each registered listener.
• The method javax.swing.JTabbedPane.AccessibleJTabbedPane.getAccessibleName() returns the accessible name of the object.

The bug report associated with this change is 6368047.

Swing: Added the new layout manager, GroupLayout

This enhancement added the new layout manager, GroupLayout, to the Swing API.

The new classes are the following:

• javax.swing.GroupLayout - a LayoutManager that hierarchically groups components in order to position them in a Container.
• javax.swing.GroupLayout.Group - the basis for the two types of operations supported by GroupLayout: laying out components one after another (SequentialGroup) or aligned (ParallelGroup).
• javax.swing.GroupLayout.SequentialGroup - a Group that positions and sizes its elements sequentially, one after another.
• javax.swing.GroupLayout.ParallelGroup - a Group that aligns and sizes its children.
• javax.swing.GroupLayout.Alignment - enumeration of the possible ways in which ParallelGroup can align its children.

The RFE associated with this change is 6375459.

Swing: TransferHandler now allows the developer to choose the drop action

Previously, Swing did not provide a means of querying the drag source's support drop actions and choosing a user drop action other than the default. This enhancement provides this functionality.

First of all, the former TransferHandler.TransferInfo class has been renamed TransferHandler.TransferSupport, since it now contains setter methods and is no longer just informational.

The changes are the following:

• javax.swing.TransferHandler.TransferSupport.getUserDropAction() - new method
• javax.swing.TransferHandler.TransferSupport.getSourceDropActions() - new method
• javax.swing.TransferHandler.TransferSupport.setDropAction() - new method
• javax.swing.TransferHandler.TransferSupport.setShowDropLocation() (replaces TransferHandler.shouldIndicate(), which was removed)
• javax.swing.TransferHandler.TransferSupport.getDropAction() - documentation updated
• javax.swing.TransferHandler.canImport(TransferSupport) - documentation updated
• javax.swing.TransferHandler.importData(TransferSupport) - documentation updated
• javax.swing.JList.getDropLocation() - documentation updated
• javax.swing.JTable.getDropLocation() - documentation updated
• javax.swing.JTree.getDropLocation() - documentation updated
• javax.swing.text.JTextComponent.getDropLocation() - documentation updated

The RFE associated with this change is 6379813.

Swing: Swing's Sorting/Filtering API has been further generified

This enhancement further generifies the Swing Sorting/Filtering API in two ways:

• DefaultRowSorter and TableRowSorter now use Comparator<?> instead of a raw Comparator:
  • javax.swing.DefaultRowSorter.setComparator(int,Comparator)
  • javax.swing.DefaultRowSorter.getComparator(int)
  • javax.swing.table.TableRowSorter.getComparator(int)
• RowFilter has three factory methods that now use type inference:
  • javax.swing.RowFilter.regexFilter()
  • javax.swing.RowFilter.dateFilter()
  • javax.swing.RowFilter.numberFilter()

The RFE associated with this change is 6386223.

Swing: TransferSupport drop-related methods now throw ISE when not a drop

TransferHandler.TransferSupport has a set of methods that are only applicable when the instance represents a drop, that is, when the isDrop() method returns true. Previously, when the isDrop() method returned false, these methods returned -1 or null or a no-op. With this change, the methods throw IllegalStateException if the isDrop() method returns false.

The changes were made in the following methods:

• javax.swing.TransferHandler.TransferSupport.getDropLocation()
• javax.swing.TransferHandler.TransferSupport.setShowDropLocation(boolean showDropLocation)
• javax.swing.TransferHandler.TransferSupport.setDropAction(int dropAction)
• javax.swing.TransferHandler.TransferSupport.getDropAction()
• javax.swing.TransferHandler.TransferSupport.getUserDropAction()
• javax.swing.TransferHandler.TransferSupport.getSourceDropActions()

The bug report associated with this change is 6387479.

Swing: javax.swing.event.MouseInputAdapter extends java.awt.event.MouseAdapter

Previously, the MouseAdapter class in AWT implemented only MouseListener, and Swing had its own interface that combined MouseListener and MouseMotionListener into a single MouseInputListener and associated MouseInputAdapter with an empty implementation.

Now the MouseAdapter class in AWT implements all mouse-related interfaces. (See RFE 4453162.) Therefore, the MouseInputAdapter class in Swing now extends MouseAdapter in AWT.

The class changed is javax.swing.event.MouseInputAdapter.

The RFE associated with this change is 6416234.

JNI

Note: Detailed information for JNI is located in the Java Native Interface Specification.

JNI: JDK1_1InitArgs and JDK1_1AttachArgs are no longer supported

The structure definitions JDK1_1InitArgs and JDK1_1AttachArgs are no longer supported in JNI, but they were still documented.

• The JDK1_1InitArgs definition has been moved from the external interface jni.h to the internal interface jvm.h as the structure JavaVMInitArgs.
• The JDK1_1AttachArgs structure is no longer used at all, and so its definition has been completely removed from the specification.

The bug report associated with this change is 5031222.

JVMTI

Note: Detailed information for JVMTI is located in the Java Virtual Machine Tool Interface (JVM TI) specifications.

JVMTI: Corrected inconsistency between specification and implementation in referrer_index for JVMTI_REFERENCE_STATIC_FIELD

There was an inconsistency between the specification and all known implementations in how IterateOverReachableObjects and IterateOverObjectsReachableFromObject report the referer_index for static fields.

According to the specification, the index is based on the order of the directly declared static and instance fields in the class, but not inherited fields. However, all known implementations use the same definition for static field index as for instance field index, that is, they base the field index on all fields, including those declared in superclasses and superinterfaces.

Since existing tools and applications assume the implemented definition, this inconsistency has been resolved by changing the specification.

• New definition of parameter referrer_index in jvmtiObjectReferenceCallback.
• New definition of type JVMTI_REFERENCE_STATIC_FIELD.

The bug report associated with this change is 6316349.

JVMTI: Added IsModifiableClass query to JVM TI and to java.lang.instrument

The IsModifiableClass query has been added to both JVM TI and to java.lang.instrument to test if a class is modifiable with java.lang.instrument.Instrumentation.retransformClasses or java.lang.instrument.Instrumentation.redefineClasses. This allows an agent to build a list of modifiable classes to pass to these functions.

Previously, if any of the classes in the list was not modifiable, these functions would return an error or exception, thus aborting the entire operation. This effectively prohibited agents from redefining more than one class at a time when unmodifiable classes were present. The performance difference in redefining hundreds or thousands of classes at a time is critical to many applications.

The new class in java.lang.instrument is java.lang.instrument.Instrumentation.isModifiableClass.

The RFE associated with this change for the JVMTI interface is 6306942, and the corresponding RFE for the java.lang.instrument interface is 6331574.

JVMTI: Removed same-name restriction from class loader append methods

Previously, when an agent provided a JAR file with instrumentation classes to be defined by the bootstrap class loader or system class loader of a running system, the JAR file could not contain any classes with the same name as a class that was already loaded by some other loader that used the target loader as its parent for delegation.

This restriction has been removed. The major reason for its removal is that many enterprise applications use complex class loader configurations and there may not be a single parent for delegation. If there are cycles in the loader graph then it is not possible to determine if a loader will ultimately delegate to the system class loader or bootstrap class loader.

The changes are as follows:

• Revised wording for method java.lang.instrument.Instrumentation.appendToBootstrapClassLoaderSearch
• Revised wording for method java.lang.instrument.Instrumentation.appendToSystemClassLoaderSearch
• Removed exception java.lang.instrument.ClassLoaderConfigurationError
• Revised wording for JVM TI function AddToBootstrapClassLoaderSearch
• Revised wording for JVM TI function AddToSystemClassLoaderSearch
• Removed JVM TI error code JVMTI_ERROR_CLASS_LOADER_CONFIGURATION

The RFE associated with this change is 6388987.

JVMTI: Added ResourceExhausted event

A ResourceExhausted event has been added to JVM TI. This event is sent when a VM resource needed by a running application has been exhausted. A bit flag indicates the type of resource which was exhausted: memory, Java platform heap, or thread.

This new event is void JNICALL ResourceExhausted(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jint flags, const void* reserved, const char* description).

The RFE associated with this change is 6456617.