|
Swing Changes and New Features for JavaTM 2 SDK, Standard Edition, v 1.4 |
Project Swing |
This document contains information relevant to all 1.4.* releases. For information specific to 1.4.1 and 1.4.2, see Swing Changes Since Java 2 SDK, Standard Edition, v 1.4.
Certain features, typically ones that have a large impact on Swing, have been extensively written up in separate documents. The following link to these documents:
JTabbedPane with scrollable tabsJSpinnerJFormattedTextFieldPopup and PopupFactory Each section contains changes for a set of related classes. Most
of the sections are focused on the classes that are part of a single
Swing component like JEditorPane or JTable.
Each API change is associated with a link to a report on the
Java Developer Connection (JDC) Bug Parade , where you'll find
the original bug or RFE ("request for enhancement") that motivated
the change. In this document you'll also find the following information
for each API change:
BoxJButtonJComboBoxJFileChooserJInternalFrameJListJOptionPaneJPopupMenuJPanelJRootPaneJScrollBarJScrollPaneJTabbedPaneJTableJTextComponentJTreeRepaintManagerSpringLayoutBox now descends from JComponent
The bugtraq report that corresponds to this change is: 4304100.
Historically, the superclass for
Boxhas beenComponent. SinceBoxdid not descend fromJComponent, you could not use it like a normal Swing component, for example, you couldn't set the borders, or issuerevalidate. Not only this, but changing visibility, or other similiar visual properties, on a standard Swing component typically triggers arepaintorrevalidate, butBoxdid not conform to this behavior. As of this release,BoxandBox.Fillernow descend from theJComponentsuperclass and therefore behave more like standard Swing components.BoxLayout Now Supports Right-to-Left and Bottom-to-Top Component Orientations
The bugtraq report that corresponds to this change is: 4140833.
BoxLayoutdid not consider theComponentOrientationof theContainerit is laying out. Other AWT layout managers were made to do this when theComponentOrientationfeature was added in JDK 1.2. Adding this feature toBoxLayoutmakes it useful for programs that support Middle East locales. BecauseBoxLayoutis also used internally by other Swing components, such asJOptionPane,JToolBarandJMenuBar, adding this feature is also necessary for these components to supportComponentOrientation.To support this functionality, the constants
LINE_AXISandPAGE_AXIS, and the constructor,BoxLayout(Container, int), were added toBoxLayout.There were also changes to several methods in
SizeRequirements:
calculateTiledPositions(int,SizeRequirements,SizeRequirements[],int[],int[],boolean)calculateTiledPositions(int,SizeRequirements,SizeRequirements[],int[],int[])calculateAlignedPositions(int,SizeRequirements,SizeRequirements[],int[],int[],boolean)calculateAlignedPositions(int,SizeRequirements,SizeRequirements[],int[],int[])
Default Button Follows the Focus on Windows LAF
The bugtraq report that corresponds to this change is: 4659800.
With this bug, introduced in 1.4.0, the default button did not always follow the focus. This has been fixed in 1.4.1.
New Control of Highlighted Characters
The bugtraq report that corresponds to this change is: 4138746.
AbstractButtonandJLabelboth allow the developer to set a character, called the mnemonic, that can be used to perform an action when typed at the keyboard. The javadoc for these methods states that the first case-insensitive occurrence of the character is decorated. While this suits most developers, often times a different occurrence of the character needs to be highlighted. For example: in Notepad, 'a' is the accelerator for Save As, but the second 'a' is decorated. Developers need a way to be able to specify this.This is solved with the new
AbstractButton.setDisplayedMnemonicIndexandJLabel.setDisplayedMnemonicIndexmethods. Once you have specified a mnemonic, via thesetMnemonicorsetDisplayedMnemonicmethods, you can then change the character that is highlighted via thesetDisplayedMnemonicIndexmethod. There are also newAbstractButton.getDisplayedMnemonicIndexandJLabel.getDisplayedMnemonicIndexmethods. Finally,drawStringUnderlineCharAthas been added tojavax.swing.plaf.basic.BasicGraphicsUtils.
AbstractButton.configurePropertiesFromAction Now Honors ACTION_COMMAND_KEY Property
The bugtraq report that corresponds to this change is: 4457940.
Previously, the
AbstractButtonmethodsconfigurePropertiesFromAction(Action)andconfigurePropertiesFromAction(Action, String[])did not honor theACTION_COMMAND_KEYproperty. That has now been addressed. This affects the javadoc for theconfigurePropertiesFromActionmethods in the following subclasses ofAbstractButton:
PopupMenuListener Added to JComboBox
The bugtraq report that corresponds to this change is: 4287690.
Many developers have requested support for listeners to be notified when a combo box's drop down menu is popped up, dismissed, or canceled. Applications could use these listeners to lazily populate the combo box's model with items.
This feature wasn't provided in earlier versions of Swing because there was some, probably academic, concern about supporting a listener for a feature (the drop down menu) that some look and feel implementations might not provide. All of the look and feels that are shipped with Java, and all of the ones we've come across, do use a drop down menu to show all of the combo box items. Some developers have resorted to non-portable hacks to get the menu state change notifications.
For this release, we added a
PopupMenuListenertoJComboBox. So long as the underlying look and feel supports an item menu, this listener can be used to perform actions before and after the combo box menu appears. Several newJComboBoxmethods were required to support this feature:public void addPopupMenuListener(PopupMenuListener l) public void removePopupMenuListener(PopupMenuListener l) public void firePopupMenuWillBecomeVisible() public void firePopupMenuWillBecomeInvisible() public void firePopupMenuCanceled()
The bugtraq report that corresponds to this change is: 4231298.
JComboBoxpreviously configured a renderer for every item it displayed. For large lists this could take quite a while. Instead, developers needed the ability to specify a prototype that all cells match, so that the prototype is only checked once instead of every cell. For this release,getPrototypeDisplayValueandsetPrototypeDisplayValuehave been added toJComboBox.
The bugtraq report that corresponds to this change is 4394300.
Previously, public API for
JComboBoxand its UI delegates contained javadoc which described the details of its implementation. Refactoring and bug fixing over the course of its history had made this javadoc out of date. The javadoc has been checked and revised so that it describes the behavior of the method rather than the implementation details. Also, some of the javadoc for "protected" methods and fields which should really have been private have been removed so that overriding or calling these methods are not encouraged.The doc has been changed for
JComboBox,ComboBoxModel,MutableComboBoxModel,javax.swing.plaf.basic.BasicComboBoxUI,javax.swing.plaf.basic.ComboPopup, andjavax.swing.plaf.basic.BasicComboPopup.
JFileChooser Windows Look and Feel Improved
The bugtraq report that corresponds to this change is 4290709.
Although Swing's
JFileChooserclosely resembles the Microsoft Windows common file dialog under the Windows look and feel, there are several deficiencies for which we have received complaints. In particular, the Microsoft Windows aesthetics guide mentions the following:If you cannot use the [common] Open and Save As dialog boxes, you should incorporate the following features into your open and save dialog boxes to ensure that they are consistent with the shell, the Windows accessories, and other applications:
- Support the same namespace hierarchy as the shell; that is, Desktop should be at the root of the hierarchy, followed by all folders and objects on the desktop, including My Computer, My Network, and so on. [...]
- Support shortcuts (also known as shell links). [...]
- Display filenames with the corresponding icons and filename extensions removed, as the shell does.
- Allow the user to browse the network hierarchy directly.
- Make sure that all of your dialog boxes (not just your open and save dialog boxes) use only nonbold fonts. [...]
The first four points are not possible in Swing without additional API support from the AWT. The AWT common file dialog is also currently an unacceptable solution for the following reasons:
- It cannot be embedded into a frame or dialog like JFileChooser.
- Filename filter is not implemented and is difficult to implement on Windows.
The new functionality is accomplished by adding the following public methods to the
javax.swing.filechooser.FileSystemViewclass, providing file and directory information beyond the scope of theFileclass:public boolean isTraversable(File f) public String getSystemDisplayName(File f) public String getSystemTypeDescription public Icon getSystemIcon(File f) public boolean isParent(File folder, File file) public File getChild(File parent, String filename) public boolean isFileSystem(File f) public boolean isFileSystemRoot(File dir) public boolean isDrive(File dir) public boolean isFloppyDrive(File dir) public boolean isComputerNode(File dir) public File createFileSystemRoot(File f) public File[] getRoots()The
isTraversablemethod has been removed fromjavax.swing.plaf.basic.BasicFileChooserUI.BasicFileViewso that the superclass's implementation is used.
createListSelectionListenerhas been added tojavax.swing.plaf.metal.MetalFileChooserUI.Also,
javax.swing.plaf.basic.BasicDirectoryModelhas the following changes:public void intervalAdded(ListDataEvent e) public void intervalRemoved(ListDataEvent e) public void renameFile(File oldFile, File newFile)
New Ability to Specify Characteristics of Open Directory Button in JFileChooser
The bugtraq report that corresponds to this change is 4318785.
Look and feels need the ability to specify the text, tooltip text, and mnemonic for the button used to open a directory in
JFileChooser.To support this, several constants and methods were added to
plaf.basic.BasicFileChooserUI:protected int directoryOpenButtonMnemonic = 0; protected String directoryOpenButtonText = null protected String directoryOpenButtonToolTipText = null protected boolean isDirectorySelected() protected void setDirectorySelected(boolean b) protected File getDirectory() protected void setDirectory(File f)Multiple File Selection Supported
The bugtraq report that corresponds to this change is 4218431.
Multiple file selection was added to
JFileChooserin the 1.4 release, but the javadoc forsetMultiSelectionEnabledwasn't updated until the 1.4.1 release.
JInternalFrame Now Truncates Titles That are Too Long
The bugtraq report that corresponds to this change is 4134077.
Previously, the title of an internal frame would not be clipped if it was too long. This would lead to the title displaying over parts of the icons, as well no visual feedback to the user that the title had been clipped. To solve this,
BasicInternalFrameTitlePane.getTitlewas added.JInternalFrame Titles in Windows Look and Feel May Now be Rendered with a Gradient
The bugtraq report that corresponds to this change is: 4389209.
To implement this correctly, we needed to create a class,
com.sun.java.swing.plaf.windows.WindowsInternalFrameTitlePane, which extendedjavax.swing.plaf.basic.BasicInternalFrameTitlePane, but overrode the paint routine to render the gradient when appropriate. The best way to get code-reuse was to break out the portion of the paint method which paints just the background and override just that inWindowsInternalFrameTitlePane. The methodpaintTitleBackgroundwas added tojavax.swing.plaf.basic.BasicInternalFrameTitlePane.
New Support for Tooltips for Images in JEditorPane
The bugtraq report that corresponds to this change is: 4252169.
In previous releases it was not possible for
ImageView(theViewresponsible for rendering images in aJEditorPane) to show tooltip text because there was no way for aViewto influence the tooltip text that is displayed for aJTextComponent. In this release, if the theJTextComponentdoesn't have a tooltip, then the view under the mouse is asked to provide one. If thatViewcorresponds to an HTML element with an ALT attribute, then the tooltip text is the value of that attribute.To make it possible for
Views to affect the tooltip text, a number of methods were needed.getToolTipTextwas added tojavax.swing.plaf.TextUIso that it is possible to get the tooltip text for a particular location.JTextComponent'sgetToolTipTextmethod then forwards to theTextUI, assuming a tooltip was not set on theJTextComponent.
getToolTipTextwas also added tojavax.swing.text.View. The default implementation ofView.getToolTipTextwill forward the request to theView's child at the given location. To make it easy to determine the child at a particular location,getViewIndexwas added toView.The
Viewimplementation invokesgetViewIndexand thengetToolTipTexton the childView.ImageViewthen overridesgetToolTipTextand returns the value from the ALT attribute of itsAttributeSet.ImageView Class is Now Public
The bugtraq report that corresponds to this change is: 4233811.
The package private class
javax.swing.text.html.ImageViewis now public so that it can be extended.
New HyperlinkEvent Read-Only elementOffset Property
The bugtraq report that corresponds to this change is: 4182124.
The HTML package exposes a way for developers to determine when the mouse moves over a link via the
HyperlinkEventandHyperlinkListenerclasses. Often times developers need a way to extract information from the document when theHyperlinkListeneris notified. There was previously no way for a developer to determine the position in the document aHyperlinkEventrepresents. To remedy this the constructorHyperlinkEvent(Object, EventType, URL, String, Element)and the methodgetSourceElementwere added toHyperlinkEvent.
HTMLFrameHyperlinkEventextendsHyperlinkEvent, which already defines the methodgetSourceElement. Since the superclass now defines this method, thegetSourceElementjavadoc was removed fromHTMLFrameHyperlinkEvent(the method is now inherited):HTML Parser Change: Whitespace Reporting
The bugtraq report that corresponds to this change is: 4241788.
The semantics of the HTML parser (
javax.swing.text.html.parser.Parser) have slightly changed to better match that of the browser (NetscapeTM and Internet Explorer). While no API was changed, those using the parser may notice a slight difference in the reporting of whitespace. Here is how things have changed: ifstrict(an instance variable ofjavax.swing.text.html.parser.Parser) ==false(the default) an instance variable is used to try and mimic the behavior of Netscape and Explorer.The problematic scenarios are:
'<b>blah <i> <strike> foo'which can be treated as:
'<b>blah <i><strike>foo'as well as:
'<p><a href="xx"> <em>Using</em></a></p>'which appears to be treated as:
'<p><a href="xx"><em>Using</em></a></p>'When a tag that breaks flow, or trailing whitespace is encountered an instance variable is set to true. From then on, all whitespace is ignored. The instance variable is set back to false the first time a non whitespace character is encountered.
Improved Support for Writing HTML Forms
The bugtraq report that corresponds to this change is: 4200439.
The HTML support provided in the J2SETM has never correctly supported writing out form elements. This was due, in large part, to the way that forms were modeled. To better match the document object model (see DOM at www.w3.org) we have changed how the forms are modeled internally. Previously, any attributes of a form would be stored in the
attributeSetof all of the children character elements. As of this release, an element is created to represent the form, better matching that of the HTML file itself. This allows for better modeling of the form, as well as consistent writing of the form.This affects developers that relied on forms being handled loosely. As an example, we would previously treat the following invalid HTML:
<table> <form> </table> </form>as:
<form> <table> </table> </form>With this release, we instead treat it as:
<table> <form> </form> </table>
Static DefaultPainter in
javax.swing.text.DefaultHighlighterClass is NowFinalThe bugtraq report that corresponds to this change is: 4328938.
Prior to this release, the static field
DefaultPainterofjavax.swing.text.DefaultHighlighterwas not final. This was a potential security problem. For this release, it is nowFinal.
PlainDocument Constructor is Now Public
The bugtraq report that corresponds to this change is: 4220001.
Prior to this release, the
PlainDocument(AbstractDocument.Content)constructor was protected. This meant that developers wishing to use the constructor had to subclass. This constructor was intended to be public, and is now public in this release.JEditorPane.scrollToReference Method is Now Public
The bugtraq report that corresponds to this change is: 4304676.
JEditorPane.scrollToReferencewas protected for no good reason. This method is intended to be useful without having to subclass, as such it has been made public in this release.Document.getText Method Now Allows for Partial Returns
The bugtraq report that corresponds to this change is: 4156650.
For efficiently accessing the content of a text document,
Documentdefines the methodgetText(int, int, Segment). Unfortunately, there has been no way for the caller to determine if the receiver could efficiently satisfy the request. For example,GapContentcould efficiently implement the request as long as the request didn't span the last edited spot of the document (the gap). To facilitate efficient access of the content, the methodssetPartialReturnandisPartialReturnhave been added toSegment. The current semantics ofDocument.getTextstill hold, but for more efficient use callers should invokesegment.setPartialReturn(true)and be prepared to get back a portion of the document at a time.
JEditorPane Now Provides HTML Accessibility Support
The bugtraq report that corresponds to this change is: 4303259.
Assistive technologies for people with disabilities require programmatic access to the contents of
JEditorPaneusing the Accessibility API. Previously, the only access was to hypertext links. This API change provided accessibility to all HTML components using the Accessibility API.
javax.swing.text.html.HTMLEditorKitnow implementsjavax.accessibility.Accessible.
JEditorPanenow implementsgetAccessibleContext().
Further Support for New AbstractDocument.replace Method
The bugtraq report that corresponds to this change is: 4458513.
As part of RFE 4431047, a
replacemethod was added toAbstractDocument. In order to allow this method to callremoveandinsertString(the only methods defined in the interface for mutating aDocument), the restrictions on whenwriteLockmay be invoked have been relaxed. This allowsreplaceto be compatible with old versions ofAbstractDocumentthat only overrideremoveandinsertString.
New showInputDialog Methods
The bugtraq report that corresponds to this change is: 4226644.
Prior to this release, if programs wished to display a simple input dialog containing a textfield with a default string, they had to invoke the complex
JOptionPane.showInputDialogmethod which requires seven parameters. Two new methods,showInputDialog(Object, Object), andshowInputDialog(Component, Object, Object), make it more convenient to create and display simple input dialogs.JOptionPane Now Supports ComponentOrientation
The bugtraq report that corresponds to this change is: 4265463.
JOptionPaneneeded to support right-to-left layout. This was a bug fix and no actual API was required, however, the class spec forJOptionPaneandjavax.swing.plaf.basic.BasicOptionPanehave been updated.JOptionPane now uses Non-Resizable Dialogs
The bugtraq report that corresponds to this change is: 4829588.
As of release 1.4.0,
JOptionPaneis changed to use non-resizable dialogs. As a result, the dialogs displayed by manyJOptionPanemethods have slightly changed. The first two changes are desirable:A side effect of this change appears in the handling of extra-long text. Previously, long text was clipped, showing "..." at the end, as the dialog was restricted to the size of the screen. Now, extra-long text can cause the dialog to be sized larger than the screen in order to accomodate all of the text. Keep watching bug 4829588 to see how this undesirable behavior is resolved.
- The dialogs are, obviously, no longer resizable.
- The dialogs no longer show the system menu icon (that typically appears in the upper-left corner of the dialog on a left-to-right system).
JPopupMenu and Focus
As of this release, showing a
JPopupMenucauses focus to transfer to the parentJRootPane. This was done so thatJPopupMenus would support keyboard traversal ( 4212563). This may cause problems for applications that are doing validation on focus lost. If this affects you, it is recommended that in thefocusLostnotification you check the temporary property of theFocusEventand, iftrue, do nothing. In situations where you don't wantJPopupMenuto grab focus, there is unfortunately no way to disable this in the current release. In release 1.4.1 the decision to transfer focus is based on the focusability of theJPopupMenu. Refer to bug 4632782 for details.JPopupMenu Now Supports Key Bindings
The bugtraq report that corresponds to this change is: 4212563.
Previously,
JPopupMenudidn't support key bindings. The arrow keys, mnemonics, the enter key, and escape did not work with aJPopupMenuunless it was used as part of a compound component (like aJMenuor aJComboBox).This behavior can be traced to the fact that
JPopupMenudid not always gain focus, and could therefore not getKeyEvents. It was previously not possible for light weight toolkits, such as Swing, to request focus and indicate that the focus change was temporary. The new focus architecture solved this problem, and Swing can now request a temporary focus change. Fixing this bug required making theJPopupMenuget focus so that the key bindings can be processed. Consumers that had previously not expected focus changes need to update their code to check the temporary property of theFocusEvents.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 throwNullPointerExceptionwhen called in headless mode. It has now been fixed to throwHeadlessExceptioninstead, to indicate that this operation cannot be performed in headless mode.
New setUI, getUI Methods
The bugtraq report that corresponds to this change is: 4226238.
The
setUI/getUImethods were not implemented forJPanel, even though its look and feel is defined by pluggable look and feel (plaf). Seejavax.swing.plaf.basic.BasicPanelUI.java, for example.
JTabbedPane and Focus
The new focus specification states that focus requests on components that are not showing will fail. This can have subtle side effects. One such side effect is that requesting focus from a
ChangeListenerassociated with aJTabbedPanemay fail. At the same time, theChangeListeneris notified that the component is not currently visible and therefore the focus request fails in the same situation that it probably worked under the previous release. If you are running into this situation withJTabbedPaneit is suggested you make the component visible before requesting focus. Other situations may require different approaches.New indexAtLocation Method in JTabbedPane
The bugtraq report that corresponds to this change is: 4241787.
Prior to this change, there was no way for client programs to convert a coordinate location to a particular tab in a tabbedpane. This made it difficult to implement special event handling on a
JTabbedPane(like popping up a menu over a tab).The method indexAtLocation has been added to
JTabbedPane.New Mnemonic Support for Accessing Tabs in JTabbedPane
The bugtraq report that corresponds to this change is: 4284674.
The panes of a
JTabbedPanedid not previously allow for mnemonics. To facilitate this, the methodsgetDisplayedMnemonicIndexAtandsetDisplayedMnemonicIndexAthave been added.Exceptions Thrown by JTabbedPane Now Consistent
The bugtraq report that corresponds to this change is: 4287053.
The
JTabbedPaneclass is a container that has many methods which take an integer index as a parameter. Unfortunately, these methods weren't inconsistent with their approach to throwing exceptions (some methods check/throw, some don't). Additionally, the javadoc was in error - it stated that anIllegalParameterExceptionwas thrown when in fact anArrayIndexOutOfBoundsExceptionwas thrown (by the underlyingVector).Any method which takes an index that must be in the valid range from 0 to tabCount-1 now documents that it throws an
IndexOutOfBoundsException(note: the underlying code continues to throwArrayIndexOutOfBoundsExceptionfor compatibility reasons).The following doc change:
* @exception IndexOutOfBoundsException if index is out of range * (index < 0 || index >= tab count)will be applied to the followingJTabbedPanemethods:public String getTitleAt(int index) public Icon getIconAt(int index) public Icon getDisabledIconAt(int index) public String getToolTipTextAt(int index) public Color getBackgroundAt(int index) public Color getForegroundAt(int index) public boolean isEnabledAt(int index) public Component getComponentAt(int index) public int getDisplayedMnemonicIndexAt(int index) public Rectangle getBoundsAt(int index) public void setTitleAt(int index, String title) public void setIconAt(int index, Icon icon) public void setDisabledIconAt(int index, Icon icon) public void setToolTipTextAt(int index, String toolTipText) public void setForegroundAt(int index, Color foreground) public void setBackgroundAt(int index, Color background) public void setEnabledAt(int index, boolean enabled) public void setComponentAt(int index, Component component) public void setDisplayedMnemonicIndexAt(int tabIndex, int mnemonicIndex)The same exception handling will be added to the following methods which previously did nothing:
public void setSelectedIndex(int index) public void remove(int index)
DefaultTableModel.moveRow Specification Clarified
The bugtraq report that corresponds to this change is: 4144295.
In JDK 1.3, the
moveRowmethod inDefaultTableModelwas documented in such a way that it did not clearly define whether the row atstartIndexor the row atendIndexrow would end up attoIndex. By inference from the examples, it appears that thestartIndexshould end up attoIndexwhen moving rows downward and theendIndexshould end up attoIndexwhen moving rows upward.That said, the implementation of
moveRowhad a bug such that whenever the number of rows being moved was more than one - the rows would end up in somewhat arbitrary positions and would not even be contiguous after the move. Bug 4144295 noted that the implementation did not even perform the example in its specification: themoveRow(1, 3, 5)example in practice left the vector in the following state:a|C|e|B|D|f|g|h|i|j|kThe new implementation makes the observation that this operation is a simple rotation of elements between bounds that can be calculated from the inputs.Since the previous implementation did not work we have taken the opportunity to simplify the definition to one where the
startIndexis always moved to thetoIndex, with all other elements appearing aftertoIndexin the same order that they were originally. Note that this performs the same operation as the previous implementation in the only case where it worked - when a single row was being moved.The new implementation does not throw an exception when
endIndexis less thanstartIndex- it does nothing instead having satisfied the implied contract to move all rows,r, wherestartIndex <= r <= endIndex.Typing into a JTable Now Transfers Focus to the Cell
The bugtraq report that corresponds to this change is: 4274963.
The Excel application automatically gives focus to underlying editors when a user presses an alphanumeric key. We have received over 200 JDC votes requesting that we offer this behavior in
JTable. While we can't change the default behavior for reasons of backwards compatibility, in this release we have added the new property,surrendersFocusOnKeystroke, to address this request. The new methodssetSurrendersFocusOnKeystrokeandgetSurrendersFocusOnKeystroksupport this feature. The default behavior remains unchanged.DefaultTableModel Now Allows a Null For Name Argument
The bugtraq report that corresponds to this change is: 4474094.
The methods
DefaultTableModel.addColumn(Object)andDefaultTableModel.addColumn(Object, Vector)did not previously allownullfor thenameargument - they threw anIllegalArgumentException. As it is possible to set the column name tonullvia other means (using constructors, or directly manipulating the field), theaddColumnmethods now also allows anullvalue.
DefaultTreeModel Now Allows a Null Root
The bugtraq report that corresponds to this change is: 4264897.
DefaultTreeModelnow allows anullroot node . Previously, the javadoc forTreeModelspecified that anullroot was valid, butDefaultTreeModelwould not allow one.DefaultTreeModelnow allows setting anullroot, as well as anullroot in the constructor. The javadoc forsetRoothas been revised to reflect the change.Added First Letter Navigation to JTree
The bugtraq report that corresponds to this change is: 4284709.
Often times users wish to navigate to cells in a
JTreeusing alphanumeric keys. To facilitate this, a method namedgetNextMatchhas been added toJTree.BasicTreeUIinstalls aKeyListenerthat invokes this method as keys are typed on the keyboard.
ListDataEvent.toString Now Provides Useful Information
The bugtraq report that corresponds to this change is: 4134085.
Developers often rely on the
toStringmethod for useful debugging information. UnfortunatelyListDataEvent'stoStringmethod did not really provide anything useful. For this release, it has been changed to return something useful.JList Now Supports First Letter Key Navigation
The bugtraq report that corresponds to this change is: 4284709.
Often times users wish to navigate to cells in a
JListusing alphanumeric keys. To facilitate this,getNextMatchwas added toJList.BasicListUIwill then install aKeyListenerthat will invoke this method as keys are typed to update the selection.JList Items May Now be Arranged Horizontally
The bugtraq report that corresponds to this change is: 4460016.
JListpreviously only allowed laying out its cells vertically, that is:1 2 3 4Numerous users have asked for the ability to lay out the list horizontally, something like:
1 3 2 4or1 2 3 4To achieve this, three constants are added to
JList,VERTICAL,VERTICAL_WRAP, andHORIZONTAL_WRAP. The methodsgetLayoutOrientationandsetLayoutOrientationare also added toJList. The javadoc for theJListmethodsgetScrollableTracksViewportHeight,getScrollableTracksViewportWidth,getScrollableBlockIncrement, andgetPreferredScrollableViewportSizeare updated accordingly. Likewise, the javadoc forgetPreferredSizeinjavax.swing.plaf.basic.BasicListUIis updated.
JColorChooser.setPreviewPanel doesn't remove the old one
The bugtraq report that corresponds to this change is: 4759306.
When calling this method the default PreviewPanel was not removed from the colorChooser, though the new panel was added. This resulted in strange artifacts. This has been fixed in release 1.4.2.
Deadlock in JColorChooser Fixed
The bugtraq report that corresponds to this change is: 4668511.
This bug when encountered in 1.4.0, caused a deadlock that would hang the entire application. This has been fixed in 1.4.1.
JFrame.setDefaultCloseOperation Can Now Throw SecurityException
As of release 1.4.1, the
setDefaultCloseOperationmethod inJFramemay now throwSecurityException.Metal Can Now Pick up Font Sizes from the Desktop on Microsoft Windows
The bugtraq reports that correspond to this change are: 4419964 and 4668963.
Prior to this release, the
DefaultMetalThemeignored the font size information from the Windows desktop. As of release 1.4.1,DefaultMetalThemecan use the font sizes specified in the Windows desktop. This can be disabled using the system propertyswing.useSystemFontSettings. An additional part of this bug is that our Windows look and feel was picking up the wrong fonts for a handful of components; this has been fixed.Some Locales Will Honor Font Size Only from the Desktop on Windows
The bugtraq report that corresponds to this change is: 4615396.
On Microsoft Windows, with the
WindowsLookAndFeel, in certain locales we only honor font size from the desktop. This has been addressed in 1.4.1.Document Which Properties a Look and Feel May Ignore
The bugtraq report that corresponds to this change is: 4420209.
Some look and feel implementations may ignore certain properties which affect the look and feel. With this release, the documentation for certain methods has been modified to indicate that these properties may be ignored by some look and feels. Also, the class spec for
UIManagerand the documentation for thejavax.swing.plaf.metalpackage were modified to specify that the Java look and feel is the default look and feel. This modification affects only documentation.The affected methods are:
javax.swing.AbstractButtonjavax.swing.JButtonjavax.swing.JCheckBoxjavax.swing.JColorChooserjavax.swing.JComboBoxjavax.swing.JFileChooserjavax.swing.JInternalFramejavax.swing.JListjavax.swing.JPopupMenujavax.swing.JProgressBarjavax.swing.JSplitPanejavax.swing.JTablejavax.swing.text.JTextComponentjavax.swing.JToolBarjavax.swing.JTreeSwingConstants Now Define NEXT and PREVIOUS
The bugtraq report that corresponds to this change is: 4175466.
SwingConstantsdefines constants that are used throughout Swing. A common UI operation is to locate the next/previous item in a sequence; as such,SwingConstantsnow defines constants forNEXTandPREVIOUS.New Way to Process Bindings for Swing Components from a non-Swing Component
The bugtraq report that corresponds to this change is: 4344900.
Swing has an elaborate infrastructure to support associating actions with particular key strokes. This means that when the user types a character the action executes. The processing of these events is triggered from within
JComponent.processKeyEvent(processKeyEventis overridden fromjava.awt.Component). As the processing of these actions occurs withinJComponent, there was previously no way for developers to process bindings from within non-JComponentsubclasses that get focus. To facilitate this, aprocessKeyBindingsmethod was added toSwingUtilities.Auditory Feedback for Swing Components
The bugtraq report that corresponds to this change is: 4290988.
Note: Due to a handful of bugs in the sound package we default to playing no sounds. If you would like to turn on sounds, you can do the following:
UIManager.put("AuditoryCues.playList", UIManager.get("AuditoryCues.allAuditoryCues"));Previously, Swing components did not provide the same auditory feedback as native components on many platforms. MALF2, a set of modifications to Swing's PLAFs, is primarily intended for use as an output-only, non-speech audio user feedback mechanism. The MALF2 project is important from the perspective of Swing/JFC and the Java platform's goal of tight user interface integration with the underlying platform. The MALF2 project ensures that a user's experience with a native application and a Swing/JFC application is identical with regard to the auditory user feedback.
The implementation centers around adding API to
BasicLookAndFeelto support loading anActionMapcontainingActions that play sounds. VariousBasicComponentUIimplementations then invokeactionPerformedon theActionat the appropriate time to play the sound. For example,BasicMenuItemUIusesdoClickto perform the action. WhileBasicLookAndFeelplays sounds using the Java Sound API, subclasses can use an alternative method. For example,WindowsLookAndFeelmaps the Strings toRunnables by way ofToolkit.getDefaultToolkit().getDesktopProperty(), to provide integration with the sounds provided by Windows.The
ActionMapcontaining the sounds can be accessed viaBasicLookAndFeel.getAudioActionMap. WhengetAudioActionMapis first invoked, it performs the following:
- The default entry
auditoryCues.cueList(anObject[]) is used to determine a list of sounds to load.- Each entry in the array is passed to
createAudioActionto obtain theActionresponsible for playing the sound.- The
Objectpassed intoBasicLookAndFeel.createAudioActionis used to look up a path to a sound file from the defaults table that can be loaded by Java Sound.- When one of the
BasicComponentUIs classes wishes to play a sound, it invokesBasicLookAndFeel.playSound, passing in theAction.BasicLookAndFeel.playSoundinvokesactionPerformedon theActionif the name of theActionis contained in the defaults entryAuditoryCues.playList.This architecture allows the developer numerous ways to customize the sounds that are played:
- The sounds associated with a particular
JComponentcan be manipulated by changing theActionin theActionMapassociated with theJComponent, eg:ActionMap map = menuItem.getActionMap(); map.put("MenuItem.commandSound", differentActionToPlaySound);- The sounds used by all
Components of a particular type can be changed by manipulating the defaults table, eg:UIManager.put("MenuItem.commandSound", "pathToNewSoundFild");- Developers creating a custom look and feel may override one of the
BasicLookAndFeelmethods to load the sounds in an alternative manner, or perhaps play the sounds in a different way.Alternatively, the set of sounds to be played can be manipulated by way of the defaults entry
AuditoryCues.playList. ThisObjectarray contains the keys in the defaults table indicating which sounds to play.MetalLookAndFeeldefines this to be:This has the effect of turning on only the sounds thatnew Object[] {"OptionPane.errorSound", "OptionPane.informationSound", "OptionPane.questionSound", "OptionPane.warningSound" }JOptionPanesupports.JMenu Updated to Work with New Focus Architecture
The bugtraq report that corresponds to this change is: 4371580.
The new focus architecture introduced via RFE 4290675 allows for developers to request a temporary focus change. The request is done through the protected
ComponentmethodsrequestFocus(boolean)orrequestFocusInWindow(boolean). These two methods are protected as they are not meant for general use, but only for implementors of lightweight toolkits, such as Swing. Swing is architected in such a way that code in different packages needs to temporarily request focus; as such, the parent class of all Swing Components,JComponent, needs to exposerequestFocus(boolean)andrequestFocusInWindowas public.New Support for Changing ComponentOrientation in Tree of Components
The bugtraq report that corresponds to this change is: 4337186.
With the bulk of the Swing components paying attention to their
ComponentOrientationproperty, we now need two features to make it easier to manage theComponentOrientationsettings of an entire hierarchy of components. It should be easy to set entire hierarchies of components to a consistentComponentOrientationsetting using the newSwingUtilitiesmethodapplyComponentOrientation(Component c, ComponentOrientation o).New Access to Desktop Properties
The bugtraq report that corresponds to this change is: 4290973.
As part of the Windows look and feel update, a method was added to
LookAndFeel,getDesktopPropertyValue, to facilitate accessing desktop properties.New Method to Offset Rectangle by Component's Insets
This was actually added as part of the update to
JProgressBarto support an indeterminate state. The bugtraq report that corresponds to this change is: 4290717.The new method is
calculateInnerArea(Component, Rectangle)has been added toSwingUtilities.New API for Mouse Wheels
The bugtraq report that corresponds to this change is: 4356268.
Wheel mice, with a scroll wheel as a middle mouse button, are increasingly popular. This proposal provides for built-in Java support for scrolling via the mouse wheel, as well as a new wheel event listener so developers can customize mouse wheel behavior.
A new class,
MouseWheelListener, and a new interface,MouseWheelEvent, have been added. The constant,MOUSE_WHEEL_EVENT_MASKhas been added toAWTEvent.AWTEventMulticasterhas three new methods:mouseWheelMoved,add, andremove.Componenthas two new methods:addMouseWheelListener, andremoveMouseWheelListener.ScrollPanealso has two new methods:setWheelScrollingEnabledandisWheelScrollingEnabled. Finally,Robothas the new methodmouseWheel.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, andJApplet) to overrideprocessKeyEvent(defined injava.awt.Component) to activate these bindings if the focus was ever on one of these top level components. With the addition ofjava.awt.KeyEventPostProcessorand 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
JWindowconstructors did not indicate thatHeadlessExceptionmay be thrown. This has been fixed in the doc forWindow(Window, GraphicsConfiguration)andJWindow(GraphicsConfiguration).Known Input Verifier Bug
The bugtraq report that corresponds to this change is: 4532517.
We've recently found an input verifier bug that has been causing problems for some of our users. Under 1.4, the
shouldYieldFocusmethod does not allow side-effects such as popping up anOptionPane.We do have the following workaround:
public boolean shouldYieldFocus(JComponent input) { if (verify(input)) { return true; } // According to the documentation, should yield focus is allowed to cause // side effects. So temporarily remove the input verifier on the text // field. input.setInputVerifier(null); System.out.println("Removed input verifier"); // Pop up the message dialog. String message = "Roll over the 'JButton1' with mouse pointer " + "after closing this dialog.\nIt sometimes behaves correctly " + "for the first time\n but repeating action brings incorrect " + "behaviour of button."; JOptionPane.showMessageDialog(null, message , "invalid value", JOptionPane.WARNING_MESSAGE); System.out.println("Showed message."); // Reinstall the input verifier. input.setInputVerifier(this); System.out.println("Reinstalled input verifier"); // Tell whomever called us that we don't want to yield focus. return false; }
Focus Bug When Simultaneously Running Windows and a Remote Display Application
In certain circumstances showing a heavy weight Window that is not focusable causes focus to be lost. This specifically happens when running flavors of Windows and a remote display application, such as Reflection-X, at the same time. Note that this bug was filed against release 1.4, but is fixed in 1.4.1. Refer to bug 4628933 for details.
New Multi Implementation of RootPaneUI
The bugtraq report that corresponds to this change is: 4338458.
The classes in
javax.swing.plaf.multiare used to multiplex between multiple look and feels. This is typically used by assistive technologies that use an auxiliary look and feel to provide additional information, such as auditory information. There is currently no implementation in multi forRootPaneUIwhich makes using an auxiliary look and feel problematic.The new class
javax.swing.plaf.multi.MultiRootPaneUIhas been added.Support for Look and Feels to Provide Window Decorations
The bugtraq report that corresponds to this change is: 4290471.
AWT recently provided API such that
Windows may be undecorated. That is, when undecorated is true, theWindowwill not render any widgets for closing, moving, or resizing. As such, Swing has made it possible for the look and feel to render decorations for Windows.This feature is primarily supported in
javax.swing.JRootPane, but we encourage developers to use the switches provided injavax.swing.JFrameandjavax.swing.JDialog.The following changes were made to
JRootPane:public static final int NONE; public static final int FRAME; public static final int PLAIN_DIALOG; public static final int INFORMATION_DIALOG; public static final int ERROR_DIALOG; public static final int COLOR_CHOOSER_DIALOG; public static final int FILE_CHOOSER_DIALOG; public static final int QUESTION_DIALOG; public static final int WARNING_DIALOG; public void setWindowDecorationStyle(int style) public int getWindowDecorationStyle()Not all look and feels support the window decoration style; the method
getSupportsWindowDecorationshas been added tojavax.swing.LookAndFeelto provide a way for look and feels to indicate whether they support this behavior.The methods,
isDefaultLookAndFeelDecorated(), and setDefaultLookAndFeelDecorated have been added toJFrame.The methods,
isDefaultLookAndFeelDecorated(), and setDefaultLookAndFeelDecorated have also been added toJDialog.
JScrollBar Now Overrides setUI
The bugtraq report that corresponds to this change is: 4213298.
JScrollBardid not previously override thesetUImethod. For this release, it has been changed to conform to this behavior.
JScrollPane Supports New MouseWheelListener
This was implemented as part of the mouse wheel support. This section only documents the changes to
JScrollPane, for details of the other changes refer to this section. The bugtraq report that corresponds to this change is: 4356268.The methods
isWheelScrollingEnabledandsetWheelScrollingEnabledwere added toJScrollPane.A new protected inner class,
MouseWheelHandler, was added tojavax.swing.plaf.basic.BasicScrollPaneUI. The relevant method in this inner class ismouseWheelMoved. Finally, the new methodcreateMouseWheelListenerhas been added toBasicScrollPaneUI.
New VolatileImage Support
The bugtraq report that corresponds to this change is: 4363288.
The Java 2D team has implemented a new
VolatileImagemechanism that has the ability to take advantage of hardware acceleration forImagegraphics and blit-to-screen operations.By default, Swing uses double-buffering to paint the contents of GUI components (by rendering into an offscreen image and then copying that image to the screen) and has been changed to take advantage of the new
VolatileImagesupport.The double buffer that Swing uses to do painting is obtained from the
RepaintManagerby using the methodgetOffscreenBuffer. Since aVolatileImageobject requires special handling (to test for failure conditions), we could not simply change this method to return aVolatileImagesince there may be existing code out there that invokes this method and does not implement this additional handling. Therefore, we have added a method,getVolatileOffscreenBuffer, tojavax.swing.RepaintManagerto specifically return aVolatileImageobject.
New SpringLayout Class
The bugtraq report that corresponds to this change is: 4290203.
This release introduces the new layout manager,
SpringLayout.See How to Use SpringLayout in The Java Tutorial for examples of using
SpringLayout.
|
Copyright © 2002 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: swing-feedback@java.sun.com. This is not a subscription list. |
Java Software |