Gustavo Muñoz - justavo, kanchenjungo, zipi

GIF is a very common image format but, due to IP issues, the platform has never supported writing GIF files. Now that the relevant patent has expired we should fix this long-standing sore spot.

No new classes or methods are required here; the bulk of the changes merely revise the specification of the javax.imageio package to require support for writing the GIF format.

Allow Java applications to access helper applications registered in the native desktop. An application should be able to display an arbitrary URL in a new window in the user’s preferred browser, launch the user’s preferred mail composer to create and send a mail message, and display files via viewer programs chosen by MIME type or file extension (e.g., Acrobat Reader for PDF files).

Splash screens are a standard part of modern GUI applications. Their primary purpose is to provide feedback to the user that the application is starting up. By employing a polished and professional splash screen, an application can occupy the user’s attention and assure the user that the application will soon be ready. Second, splash screens can provide marketing information. Finally, splash screens are sometimes required for legal reasons to present copyright information, third party logos, etc.

It is possible to employ Swing or AWT to create splash screens for Java applications today. The main purpose of a splash screen is to provide feedback during application startup, however, so the delay between the moment an application is launched and the moment when the splash screen appears should be minimal. Before a pure Java splash screen can be displayed the application loads and initializes the JVM, the AWT subsystem, perhaps Swing, and also possibly some application-dependent libraries. This imposes a multi-second delay, so a pure Java splash screen cannot satisfy these timing requirements.

This feature will implement initial splash-screen display in native code, prior to the actual launching of the VM. It will support GIF, JPEG and PNG format images, including transparency (GIF, PNG) and animation (GIF). Splash-screen images can be specified on the command line or, more usually, in a header in the application’s JAR manifest file. The splash screen will be removed automatically when the application displays its first window.

This feature will also provide a simple Java API for controlling the splash screen once the application has started.

This feature will not have any impact on startup time if the splash screen is not used.

From its introduction AWT has only offered one type of modal dialog: Whenever a dialog window is displayed then all windows in the application are blocked. Other toolkits and platforms offer different dialog modalities, which developers are now expecting. OS X, e.g., makes extensive use of window-level modality, in which only the parent window of a modal dialog is blocked.

Another important missing feature is the ability to exempt a particular window from being blocked by modal dialogs at all. A widely distributed help system for java applications, JavaHelp, has been suffering from this problem for years. Modal dialogs shown from the application completely disable the help window, thereby making it useless.

Every modern desktop has a “system tray” or equivalent where native applications can display icons to notify the user of application events or allow access to extra functionality for applications that don’t have to be constantly visible in main window on the desktop. System-tray support is one of the key user-interface elements whose absence makes Java applications look less appealing than native applications.

This feature will define a cross-platform API for system trays that can be reasonably implemented on all known windowing systems.

Third parties need to be able to add support for new locales to the JRE. This feature will define a new set of “pluggability” APIs so that an existing JRE can be augmented with additional locale data.

The getAvailableLocales methods of most existing locale-sensitive classes will return any newly-added locales, and their getInstance methods will return appropriately-localized objects. The data behind the following classes will be extensible:

java.text:	BreakIterator, Collator, DateFormat, DateFormatSymbols, DecimalFormat, DecimalFormatSymbols, NumberFormat
java.util:	Currency, Locale, TimeZone (text only, not zone data)

The main benefit of such extensibility is that third parties will be able to provide support for locales for which Java SE platform implementors lack the necessary expertise.

This feature will not revise the java.util.Calendar class along similar lines since that class is not well-suited to supporting non-Gregorian calendars. Pluggable locale support for calendars may be considered in a future release if and when a more general date/time API is introduced.

The ResourceBundle class is in need of several minor enhancements:

• A way to remove a bundle from the cache so that it can be reloaded, e.g., in a long-running application;
• A way to support bundles in arbitrary non-standard formats, e.g., XML;
• A way for developers to define their own bundle search strategies; and
• A way to define resource bundles without having to declare them as public classes.

This feature will address these requirements by breaking the current fixed bundle-loading process into its constituent parts so that applications can customize the behavior of each part via callback methods. The bundle cache and its behavior, which was previously implicit, will also be made explicit as well as customizable.

An API for normalizing Unicode strings. The ability to transform Unicode strings into one of the standard normal forms is important for text processing and for supporting various external standards such as internationalized domain names and XML canonicalization.

To enable the creation of GUI layouts that are independent of any particular look-&-feel, and to enable more intuitive layout managers and development tools, this feature will extend Swing to provide APIs for

• Determining the preferred distances (i.e., gaps) between components depending upon the guidelines for a given look-&-feel, and for
• Determining the position of text baselines and arranging for components to be aligned vertically on their text baselines.

Currently it’s difficult for programmers to use drag-&-drop with Swing—only a small handful of Swing components have easy-to-use drag-&-drop support. There are two major problems:

• A drop location is indicated by moving the selection around within the component under which drag-&-drop is occurring. This fires unnecessary selection events, is not customizable, and is hardly ever what the user wants.
• Swing provides no support at all for customizing what data can be inserted at what locations in the component. User code is provided very few details about the actual transfer when asked whether or not it can accept it, it’s only asked once (not based on position in the component), and it’s given the same sparse information when it’s time to import the data.

This feature will define new APIs to allow user code to specify one of several new drop modes on components that support drops. This will provide more flexible ways to insert data and will allow drop locations to be indicated without affecting selection. Drop locations will be calculated based on the drop mode and will be returned to user code during drag-&-drop operations.

Currently tabs can contain only an icon, text, or HTML. Many modern applications, e.g., Mozilla, now support a richer user experience with tabbed panes that can only be done in Swing if we allow arbitrary components to be added to a tabbed pane. This will make it possible, e.g., to have both a text label and a close button on each tab.

It’s very common for developers—especially in the corporate world—to want to sort, filter, and highlight the contents of JTables. It’s unnecessarily hard to do so, however, hence developers typically wind up either rolling their own or using a third-party sorting framework. This feature will add this missing functionality to Swing.

To effectively create a Swing application one needs to use multiple threads, especially when interacting with remote resources such as databases or web services. Swing is not thread safe, however, which makes this a daunting and arduous task.

The SwingWorker class makes multi-threaded Swing programming much easier. It was originally published on java.sun.com more than six years ago and since that time many developers have requested that it be integrated into the platform.

It’s presently difficult, though possible, to print the contents of a Swing text component as a document rather than as a printed rendering of the component itself. This feature will integrate basic printing support into the JTextComponent class.

A large percentage of Java developers also use scripting languages. While the Java language is suitable for many tasks, and especially for writing robust, long-lived applications, scripting languages are useful for many other tasks.

JSR 223 defines a framework for connecting interpreters of arbitrary scripting languages to Java programs. It includes facilities for locating the available scripting engines, invoking scripts from Java code and vice versa, and making Java application objects visible to scripts. The framework is divided into two parts, the Scripting API and an optional Web Scripting Framework. This feature will incorporate just the Scripting API into this version of the Java SE platform.

There will be no requirement that any particular scripting language be supported by the platform; implementors may choose to include support for the scripting language(s) of their choice as they see fit.

To support the implementation of leak detectors and other kinds of heap-analysis tools this feature will extend JVMTI, the Java Virtual Machine Tools interface, and JDWP, the Java Debug Wire Protocol, to support the retrieval of information about all instances of a given class, and all objects referring to a particular instance, within a running virtual machine.

Sometimes it’s necessary to connect a monitoring, debugging, or profiling tool to a running virtual machine that was not started with any of the special command-line flags that enable such connections.

This feature will extend the JVMTI and java.lang.instrument specifications to support the starting of agents in an already-running VM.

Both JVMTI and java.lang.instrument were designed to support multiple simultaneous independent tool agents. If more than one such agent is attempting to insert instrumentation, however, then they will interfere with each other. These existing interfaces are also flawed in that they model the process of instrumenting a class as a replacement operation, so it’s not always possible for a transformer to access the original bytecodes of the class it’s transforming nor is it possible to safely remove instrumentation once a tool’s task is finished.

This feature will address these problems by extending these interfaces to support an event-based retransformation operation.

An update to the Java class-file format to add support for the “split verification” architecture pioneered in the Java ME platform (see JSRs 30 and 139). This technique enables improved performance as well as a higher level of confidence in the Java security model since the runtime verification logic is itself easier to prove correct.

It’s often the case that arrays cannot be sized accurately before they are filled. This implies a resizing operation via the System.arrayCopy method, which is not statically type-safe and whose order of arguments is notoriously difficult to remember. If the initial allocation of the array is generous enough, moreover, the copy operation might be performed infrequently enough to make testing haphazard, raising the likelihood of post-release bugs.

This feature will add convenience methods to the java.util.Arrays class that will make it easier to expand, or contract, the size of an array by providing operations that both allocate a new array and copy data in from an existing array.

Users have long wanted the ability to have bi-directional variants of queues and lists, along with iterators that visit their elements in a descending direction.

This feature will define two new interfaces, Deque and BlockingDeque, along with basic implementations. It will also retrofit existing interfaces and classes to support these new interfaces where appropriate.

This is a community contribution from past members of the JSR 166 Expert Group.

Users want sorted collections (sets and maps) with more capabilities, in particular the ability to search bidirectionally, and to find elements strictly less than or greater than a given element.

This feature will extend each of the existing SortedSet and SortedMap interfaces with a new interface, NavigableSet and NavigableMap, respectively, and provide concurrent implementations of these new interfaces. It will also retrofit existing interfaces and classes to support these new interfaces where appropriate.

This is a community contribution from past members of the JSR 166 Expert Group.

Developers have long been asking for a way to discover the amount of free space in a filesystem and for methods to manipulate file attributes. These requests will eventually be addressed fully by JSR 203, but in the meantime the lack of even basic functionality in these areas is causing lots of frustration.

As an interim measure this feature will add a handful of new methods to the java.io.File class to support

• The discovery of the amount of free disk space, in bytes, in the filesystem partition named by a given File instance; and
• The examination and modification of simple cross-platform file attributes including readability, writability, and executability.

The Java math libraries do not include many of the IEEE 754 recommended low-level functions for manipulating and examining floating-point values. These functions are needed for both implementing and testing floating-point libraries. This feature will add the core IEEE-recommended functions scalb, getExponent, nextAfter, nextUp, and copySign for both float and double types.

Several members of the JSR 166 Expert Group have continued working to refine and extend the interfaces and classes defined by that specification. This feature will integrate a set of minor fixes and additions including, but not limited to:

5057341	TimeUnit needs additional enum constants for longer durations
5073546	Minor ConcurrentHashMap constructor spec tweaks
6237968	Add AbstractQueuedLongSynchronizer
6267833	Incorrect method signature ExecutorService.invokeAll()
6275329	Add lazySet methods to atomic classes
6277663	Improve extensibility of thread pools
6330307	Improve CopyOnWriteArraySet, CopyOnWriteArrayList equals methods

Many Java applications require the ability to prompt for a password without revealing the password on the screen. GUI applications can do this today, but command-line applications cannot, at least not without resorting to native code and JNI.

This feature will define a new API for interactive console I/O that can disable character echoing while reading passwords.

Practical experience with annotations has identified situations in which it’d be useful to be able to access the names of method and constructor parameter names. This is particularly relevant to JSRs 181 (Web-Services Metadata) and 224 (JAX-WS 2.0), but it may also be of use in other JSRs such as 255(JMX 2.0) and 274 (Design-Time API for JavaBeans).

This feature will provide access to the names of constructor and method parameters at runtime via the reflection API. To do this effectively will probably require the introduction of a new core annotation, or perhaps a meta-annotation, to identify constructors and methods whose parameter names should be recorded in class files. Otherwise this feature would only work with class files containing full debug information; such class files are larger than is desirable in production settings.

The JAR file format was extended in J2SE 1.3 to support a standard way of specifying pluggable “service providers.” Many subsystems in the platform now use this mechanism, including image I/O, input methods, naming, networking, new I/O, printing, security, sound, and XML. Many of these subsystems use an implementation-internal utility class for looking up services and instantiating providers; there is no standard API offering such functionality.

This feature will refine the internal utility class as needed and then promote it into the java.util package. This will make it easier for both internal and external developers to make use of the JAR-file service-provider feature, which has become very widely used.

Existing facilities for diagnosing synchronization problems, and in particular the ThreadInfo class, only report information about object monitors; they do not report on the java.util.concurrent locks introduced in the J2SE 5 release. This will make the diagnosis of synchronization problems much more difficult as applications begin to make use of these new types of locks.

This feature will extend the existing monitoring APIs to provide diagnostic information about all types of monitors and locks.

Additional metadata about a Model MBean can be provided via Descriptors. A descriptor can be attached to a ModelMBeanInfo object to describe the MBean itself as well as to instances of the various ModelMBean*Info classes to describe the components of the MBean.

This feature will generalize the specification so that descriptors can be associated with all types of MBeans, not just Model MBeans. This will make it much easier to communicate various kinds of metadata such as

• Resource bundle names and keys that localize descriptions and other text in an MBeanInfo object,
• Constraints on attribute and parameter values,
• Units and other descriptive information, and
• Additional metadata from other, related management models (e.g., SNMP OIDs or CIM qualifiers).

Feature 371 proposes adding descriptor support to all types of MBeans. This allows instances of MBeanInfo and associated classes to include arbitrary extra information beyond the fixed fields that are currently defined.

Given that descriptors will be available for Standard MBeans, and that the MBeanInfo class for a Standard MBean is derived from a Java interface, it would be convenient to be able to add annotations to the Java interface to define the descriptor contents. This would provide an immediate way for a tool that generates Standard MBeans from an existing management model to include information from the model in the generated MBean interfaces, rather than in separate files, and for clients of the generated MBeans to retrieve this information in an obvious way.

This feature will define a generic mechanism by which users can define custom annotations that map to specific descriptor fields.

A persistent problem with JMX modeling is that one often needs a type that is an atomic snapshot of a collection of values, e.g., ThreadInfo, but clients of the model cannot be required to have that type present—especially since the type might change between versions.

Open MBeans are one solution to this problem but they are, unfortunately, difficult to use. The J2SE 5 release introduced the notion of MXBeans, but these were only implemented for the platform’s built-in MBean server. This feature will add full support for MXBeans to the base JMX infrastructure.

Domain names on the Internet are moving beyond ASCII. This feature will add support for internationalized domain names as specified by RFCs 3490, 3491, and 3492.

URIs on the Internet are moving beyond ASCII too. This feature will add support for internationalized resource identifiers as specified by RFCs 3986 and 3987.

Many applications need more information about the capabilities and current state of the underlying system’s network interfaces than is currently provided. This feature will extend the existing NetworkInterface class to include, at least, the following kinds of information:

• Broadcast address
• Subnet mask
• MAC/hardware address
• MTU size
• State (i.e., up or down)
• Is multicast supported?
• Is this the loopback interface?
• Is this interface’s address dynamic?
• Is this a subinterface (i.e., a virtual address)?

J2SE 5 introduced a CookieHandler API so that applications could control how cookies are managed on the client side of an HTTP connection. No implementations of this abstract class were provided, however, so application developers were left to roll their own.

This feature will define a simple implementation of the CookieHandler API that’s sufficiently customizable to meet the needs of most applications.

The XML Signature standard is a key part of Web Services Security. It’s therefore required by JSR 224 (JAX-WS 2.0), though it’s also useful in its own right.

This JSR will define a service-provider API that allows a Java program to select and invoke a Java language compiler programmatically, retrieve errors and other messages in a structured fashion, and access the dependency information computed by the compiler. This will fulfill a longstanding request from many Java tools vendors.

The specification will not mandate the inclusion of a Java language compiler in a Mustang JRE; it will merely permit it.

This JSR will define a standard API to support the processing of JSR 175 annotations.

As with JSR 199, the Java Compiler API, the specification will not require that a Mustang JRE support annotation processing; it will merely permit it.

JSR 250 will define a small set of common annotations that will be available for use in other specifications. Some of the annotations are specific to the Java EE platform. This feature will incorporate just those annotations that are relevant to the Java SE 6 platform and are of use in other component JSRs such as JSR 224 (JAX-WS 2.0).

JDBC 4.0 is the latest revision of the core Java database access standard. The highlights of this version are:

• Automatic driver loading via the Java SE service-provider mechanism;
• Annotations that ease the development of applications that manipulate data in relational (table) form rather than via an object/relational mapping;
• Support for SQL ROWIDs;
• Enhanced support for BLOBs and CLOBs;
• SQL/XML support, as defined in SQL:2003; and
• Improved connection management.

This feature will integrate JDBC 4.0 into the Java SE platform.

JSR 173 defines a streaming-parser API for XML. Streaming parsers, also called “pull” parsers, offer performance competitive with existing SAX parsers but an interface that’s much easier to use. StAX is also a foundational technology for JSR 222 (JAXB 2.0) and JSR 224 (JAX-WS 2.0).

JSR 181 defines a simplified programming model for Web Services based upon a set of annotations. These annotations are used by JSR 224 (JAX-WS 2.0).

JSR 222 is a major revision of the JAXB 1.1 specification. Its primary goals are

• Full support for W3C XML Schema;
• The ability to bind existing Java classes, which may include customizing annotations, to an XML schema generated from those classes;
• Simplified bindings that leverage the language features introduced in Java SE 5; and
• The portability of JAXB-generated classes across different implementations.

This feature will integrate JAXB 2.0 into the Java SE platform.

JSR 224 is a major revision of the JAX-RPC 1.1 specification. Its primary goals are

• Full integration with JSR 222 (JAXB 2.0);
• Support for the latest Web Services standards, including SOAP 1.2, WSDL 2.0, and the WS-I Basic Profile 1.1;
• Improved ease-of-development via annotations that will simplify the most common development scenarios;
• Support for client-side asynchronous operations; and
• The portability of JAX-WS-generated classes across different implementations.

This feature will incorporate the core and client portions of the JAX-WS 2.0 specification into the Java SE platform.

The JAF is a simple data typing and registry framework. It provides standard services for determining the MIME type of an arbitrary piece of binary data, encapsulating access to it, discovering the operations available on it, and instantiating an appropriate bean to perform those operations.

The JAF is required by JSR 224 (JAX-WS 2.0), though it’s also useful in its own right.

PROCESS NOTE: The JAF specification predates the Java Community Process. Some minor revisions were recently proposed under JSR 925.