FULL PRODUCT VERSION :
java version "1.6.0-rc"
java(TM) SE Runtime Environment (build 1.6.0-rc-b99)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b99, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The width of a JComboBox is too narrow under WindowsXP Look&Feel. This results in truncated text (trailing characters are replaced by "...") when the widest combo box item is displayed.



REGRESSION.  Last worked in version mustang

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case and take a look at the text displayed in the JComboBox.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The text "mm" should be displayed on the JComboBox
ACTUAL -
The text "..." is displayed.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;

/**
 * Test to  customer  a bug in JDK6-b99 on Windows XP
 * Displays a JComboBox and a JLabel in a JFrame. The label only has the purpose of making sure that the combo
 * box only occupies as much space as it requires.
 * On JDK6-b99 you will see that the combo box will display "..." instead of "mm".
 */
public class ComboBoxTest {

  public static void main(String[] args) {
    // set windows xp look and feel (on Windows XP platform)
    try {
      UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    } catch (Exception ex) {
      ex.printStackTrace();
    }
    // create and display frame
    JFrame jFrame = new JFrame("JComboBox Test");
    jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    jFrame.setLayout(new BorderLayout());
    jFrame.add(new JComboBox(new Object[]{"mm", "cm"}), BorderLayout.WEST);
    jFrame.add(new JLabel("<------fill----->"), BorderLayout.CENTER);
    jFrame.pack();
    jFrame.setLocationRelativeTo(null);
    jFrame.setVisible(true);
  }
}
---------- END SOURCE ----------

Release Regression From : 1.5
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2006-10-02 17:45:18.0

http://forums.java.net/jive/thread.jspa?threadID=18752&tstart=0
Posted Date : 2006-10-02 18:02:47.0

N/A

  xxxxx@xxxxx   tested it with promted builds. The first build the bug is reproduced on is mustang-b88. The first swing nighlty build it was reporoduced on is 
2006-05-26.mustang. This regression was introduced by the fix for 6382711 [JComboBox incorrectly rendered with alternate WinXP theme]. I think this bug was caused by this change:

WindowsComboBoxUI.java
public void paintCurrentValue(Graphics g, Rectangle bounds,
                                    boolean hasFocus) {
!             bounds.x += 2;
!             bounds.y += 2;
!             bounds.width -= 3;
!             bounds.height -= 4;
----
!             bounds.x += 3;
!             bounds.y += 3;
!             bounds.width -= 5;
!             bounds.height -= 6;
---------------
New bounds.width is smaller than the old one by 2 thus the text is replaced by "..."
Posted Date : 2006-10-02 18:02:47.0

Note that this code has been changed once more since the bug fix mentioned above. But I have confirmed that we're still too small to render the largest item. This needs to be fixed.
Posted Date : 2006-10-04 12:33:51.0

DELETED
Posted Date : 2006-10-13 19:54:35.0

DELETED
Posted Date : 2006-10-13 19:54:35.0

This was supposed to have been fixed by 6439971. Unfortunately, the code doesn't seem to have made it into the code base. Will apply it now.
Posted Date : 2006-10-13 19:56:44.0

This was the result of a merge error. I am submitting a new webrev to address it. Because of concerns of a possible infinite loop with calling super.getPreferredSize() from getMinimumSize() if it is subclassed I am leaving that change from preferred to minimum out.  This means that 6340871 is no longer fixed.
Posted Date : 2006-10-13 23:22:54.0

This bug can seriously affect any application that uses Swing. For example on an input form of a stock broker application the user suddenly may not be able to see what currency value is selected in the form's combo boxes, which may make the whole application unusable. If I was the decision maker, this bug would be fixed before the final release of JDK 1.6.

Please try to fix this for the initial JDK6 release.  It can make so many UIs virtually useless not only visually unappealing.
This very same issue was JUST "fixed" in b96 (see https://jdk6.dev.java.net/files/documents/5490/39211/jdk6-b96.html  bug #6439971)  so according to the evaluation above it was instantly broken in the next build!

I just don't get it! Why does fixing this bug automatically mean delaying mustang? Only fixing the bug should take an engineer about one or two hours. And testing will take another two hours. And if you want to make sure that you do not break any stuff, just roll back the fix for 6382711, which was a really unimportant bug compared to this one. Bureaucracy is necessary in some cases to ensure quality standards, but in this case it seems to prevent creating a top quality product.

And I disagree to the evaluation. I do think this bug is a show stopper. It is basically the definition of a show stopper.

I will not allow my company to deploy Java 6 with this bug, since our users will not be able to use applications with comboboxes correctly.  I suspect my decision will be a common one among people who make these decisions.  Therefore, this is a showstopper, and should be fixed prior to the Java 6 release.

When will Java be open sourced so we can fix these bugs in a timely manner?

To paraphrase Harry Truman "the bug stops here".  So please do not push the bug off to update 1 but handle it with Java 6.  

Like we users have said - please fix this bug.  

Thanks,
Jim Burke

Is it the case that no JComboBoxes will render with anything other than "..."? The elements in this combo box have only 2 characters. This bodes badly for the newest release, as our application has JComboBoxes. Do I tell my company not to update to JDK 1.6?

In my experience this is a problem with ALL comboboxes on Win LnF.. the longest item (or items if they are the same length) are ALWAYS truncated with ....

Basic control functionality and consistency is critical for user acceptance of product, the JComboBox now looks unusable, therefore it is a 'showstopper', so I vote this fixed.

It looks to me like replacing the cellrenderer for the JComboBox with a new BasicComboBoxRenderer
and overriding getPreferredSize to fake a longer text
than you really have gets around the problem, albeit
by making the combobox a little wider than it needs to be.
Does anyone see any problems with this workaround?

       	public Dimension getPreferredSize() {
        	Dimension size;
                String text = this.getText();
                if ((text == null) || (text.equals( "" ))) {
                    size = super.getPreferredSize();
                }
                else {
                	setText(text + "    ");
                    size = super.getPreferredSize();
                    setText(text);
                }
                
                return size;
        	}

Sorry, I didn't check "include a link..." in my posting
of Nov 1 for my proposed workaround.  Please email
me if you can confirm this workaround works or
if you think it's wrong.  Would an alternative workaround
be to override the getListCellRendererComponent
method and *set* the preferred size width wider there?
That's what I initially tried and it seemed to work also,
but I don't think it is as good as overriding
getPreferredSize.  I'm not an expert.  Please let
me know if my workaround (above) is good or not.
Thanks

That still didn't work even though I checked
"Include a link..."
Please email mccormick_bradford@emc.com
with any thoughts about my proposed workaround.