Skip to main content

Horrible JComboBox regression in b99 with WindowsXP L&F

27 replies [Last post]
jansan
Offline
Joined: 2005-02-24

There is a regression in JComboBox that must have been introduced in recent builds. The text of all of the JComboBoxes in our application gets truncated when the item with the longest text is displayed.

Here is a very simple test case (works with JRE 1.5.0 and I am pretty sure it worked with earlier JDK6 builds):

<br />
import javax.swing.*;<br />
import java.awt.*;</p>
<p>/**<br />
 * Test to visualize a bug in JDK6-b99 on Windows XP<br />
 * Displays a JComboBox and a JLabel in a JFrame. The label only has the purpose of making sure that the combo<br />
 * box only occupies as much space as it requires.<br />
 * On JDK6-b99 you will see that the combo box will display "..." instead of "mm".<br />
 */<br />
public class ComboBoxTest {</p>
<p>  public static void main(String[] args) {<br />
    /* set windows xp look and feel (on Windows XP platform) */<br />
    try {<br />
      UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());<br />
    } catch (Exception ex) {<br />
      ex.printStackTrace();<br />
    }<br />
    /* create and display frame */<br />
    JFrame jFrame = new JFrame("JComboBox Test");<br />
    jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);<br />
    jFrame.setLayout(new BorderLayout());<br />
    jFrame.add(new JComboBox(new Object[]{"mm", "cm"}), BorderLayout.WEST);<br />
    jFrame.add(new JLabel("<-------fill------->"), BorderLayout.CENTER);<br />
    jFrame.pack();<br />
    jFrame.setLocationRelativeTo(null);<br />
    jFrame.setVisible(true);<br />
  }<br />
}<br />

This is a horrible bug. Please do not let this bug slip into the JDK6 final release.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jansan
Offline
Joined: 2005-02-24

I conducted some tests with b103 with different font sizes, different screen resolutions, antialiasing switched on and off, and everything works without any problems at all. Great work.

larswestergren
Offline
Joined: 2006-02-20

Ewin, I think that is the third time I read posts by you where you start yelling at people who don't even work at Sun!

Ok, I understand that you are frustrated, we all are at moments, but this constant repeat of your post is not helpful. If it is so critical to you, why don't you fix the bugs yourself!

> and explain why there are so many one vote only bugs fixed, but many other bugs in the bug database with much more votes are ignored for years.

Easy, many bugs remain unfixed because they are high riskc to fix! Fixing them might take a lot of time and change a lot of functionality. Also, unfortunately it is likely that many clients have been written that expect the old functionality, and changing it would break them.

/Lars - not a Sun employee or speaking for them in any way.

ewin
Offline
Joined: 2005-07-15

It is the same old sad story with Sun again and again :-(

If it a GUI issue it doesn't matter much to them :-( If it is a boring GUI issue they couldn't care less :-( It is much more important for them to write one stupid "cool" demo after the other, instead of fixing their bloody software. They have ten year old GUI bugs, important things in real live. But waht happens? Their chief demo writer of course has enough time to write yet another fscking demo http://weblogs.java.net/blog/joshy/archive/2006/10/nasa_maps_in_yo.html , but of course no one in the whole team would care about a broken combobox, broken font rendering or anything broken because is is not "cool". Dammed kids.

Oh, and don't give us the junk about voting in the bug parade. Sun has well documented how much they care about that. See http://java.sun.com/j2se/1.5.0/fixedbugs/fixedbugs.html and explain why there are so many one vote only bugs fixed, but many other bugs in the bug database with much more votes are ignored for years.

benloud
Offline
Joined: 2005-08-09

Calm down. Josh has said he's implemented a fix and tested it, and it works. it just didnt make it in because of a merge error. With the amount of attention this bug is getting, im sure it will make it in.

just dont say Sun doesnt care. Josh has worked hard to make the Win L&F look pixel perfect and has given it a huge makeover. I for one am grateful for his work.

jansan
Offline
Joined: 2005-02-24

Since I am the one who started this thread I feel a bit guilty that it has come to the point that Joshua is being blamed for not fixing bugs (or this particular bug). That's not what I intended, and I think that Josh has done a tremendous job on fixing the Windows Look&Feel (and this is exactly why I care so much about this bug). I just wanted to grab some attention because I thought (and still think) it should be possible to close an easy-to-fix, quite annoying bug when the final release is still two months away.

Josh has done a great job and he is still doing a great job. Provided that this one bug gets fixed, JDK1.6 will be the first ever release that features a Windows Look&Feel that is almost indistinguishable from the original. And I hope Joshua will also find some time in future to do some cool demo stuff next to his main projects.

olsonje
Offline
Joined: 2005-08-10

Josh has every right in the world to do anything he wants in his own time (and for that matter, whatever Sun wants him to do on their time as we aren't paying his salary), and I personally am _very_ grateful for his demo's and the time he invests into something he obviously cares very much about. Attacking him is not proper at all, and honestly, thank you to Josh & all the Sun folks for the work they do get done for us.

As for the bug parade thing, I don't know how they pick what they are working on, but, I do know that there are certain folks working on select parts of the entire thing, such as like Josh does swing, I doubt he touches the Hotspot or Compiler sections because that’s not area of his expertise (big assumption here), so don't think things aren't getting done because they are ignoring them, more then likely its more along the lines of what Person_A can get done in x amount of time, and if they have some lower priority bugs that are set for n time and they have about that much time left that day, why not knock out one of those lower bugs instead of starting something much more complex and stopping partially through it when the next day would allow them to work on it fully without interruption?

And yes, that’s a very simplistic view of it, but I hope you get my point.

joshy
Offline
Joined: 2003-07-02

I'll have a blog on this later with more details, but I would like to clarify one thing right here. The reason this bug was originally put off to u1 has nothing to do with priorities, or me wanting to do another cool demo instead. It has to due with where we are in the release cycle. I am not allowed to put back a low priority bug at this point (remember we are in the the last 5% of a 2 year development cycle). I am not even allowed to put back a high priority bug. Everything must go through many levels of approval to make a change this late because we must ensure that we don't introduce any other regressions. Even a one line change could have effects elsewhere. If we kept just putting bugfixes back for everything then we'd never ship! We have to manage the priorities, and it gets harder and harder to get something in as we approach the final release. That's why your votes on the bug parade are important. Those votes help us find the *right priority*. Because of outside feedback we have been able to revisit this bug. I'll have more details soon. Thanks for your constant vigilance.

infosun
Offline
Joined: 2006-10-13

Josh, all this is accepted by long term java users.
But dont forget the reported bugs! We report many, but only
have 3 Votes (for the hole Java world 5 and the beta 6)

joshy
Offline
Joined: 2003-07-02

For more on the resolution to this bug please see my blog here: http://weblogs.java.net/blog/joshy/archive/2006/10/update_on_bug_6.html

In short, it's fixed in b103.

jjburke
Offline
Joined: 2004-03-16

joshy, thanks for getting this fixed in B103. I tried it and it works flawlessly. Also thanks for getting this navigated through your approval bureaucracy. Reminds me of working in retail where we had September-February code freeze that took an act of god (well a vp anyhow) for any change or install.

Then infosum, hope you take this kindly. Try getting a copy of Strunk and White's "Elements of Style". That will get you points for better grammar in your notes.

Great fixes everyone!

robogeek
Offline
Joined: 2003-06-18

> I wonder if there is a way to use the debugger APIs to the
> VM to do some sort of automated test where you would
> simply put a break point in the code where the decision is
> made to truncate the text and add the "..."

That would work (maybe) for the one instance. But what about the kerjillion other possible bugs which could occur?

Any change to the code has the possibility of introducing a new bug or rebreaking an old bug. And the regression theoretically could be anywhere.

swpalmer
Offline
Joined: 2003-06-10

> > I wonder if there is a way to use the debugger APIs
> to the
> > VM to do some sort of automated test where you
> would
> > simply put a break point in the code where the
> decision is
> > made to truncate the text and add the "..."
>
> That would work (maybe) for the one instance. But
> what about the kerjillion other possible bugs which
> could occur?
>
> Any change to the code has the possibility of
> introducing a new bug or rebreaking an old bug. And
> the regression theoretically could be anywhere.

Your comment seems nonsensical to me. Of course there can be other bugs, so what?
You might as well say that there is no point in having any regression tests because the software can just fail in a new way.

The type of test I suggested is no less valid that the "golden image" tests that are already done... I simply am suggesting that the "breakpoint test" is a viable alternative that might be less fragile than a "golden image" test in some cases. It's just another weapon in the arsenal. I think it could be used for much more than just this one case.

Anyway... I'm guessing that even though JDK6 is stabilizing for the release, the changes are being made simultaneously for update 1 so that a similar burn-in period can be applied to it and the fixes for the "almost show-stopper" issues can get out there ASAP. Is this the case, or has development on update 1 not started yet?

atripp
Offline
Joined: 2003-07-15

> Should I even ask why there is no regression test for
> this, since it keeps coming back?

I don't see how a test for this is possible. You'd have to have something that takes a screen snapshot and intellgently looks at the pixels to see that things are getting cut off. Just by examining the JComboBox component programmatically wouldn't tell you that there's a problem with what's displayed.

trembovetski
Offline
Joined: 2003-12-31

> You'd have to have something that takes a screen snapshot and intellgently looks at the pixels to see that things are getting cut off.

We have many tests which do just that.

Dmitri

jansan
Offline
Joined: 2005-02-24

After downloading the latest build, I can confirm that the bug occurs in build 100, too. Meanwhile I have also filed a bug report (review id 809305).

trembovetski
Offline
Joined: 2003-12-31

Thanks a lot for reporting this. This looks like a regression introduced in JDK6 b88 (most likely by the
for this bug: 6382711).

Your incident has been filed as bug: 6477341 - should appear shortly on bug.sun.com .

Unfortunately chances of fixing this in JDK6 are slim
as only showstoppers are allowed at this stage of
the release, and unless it is decided that this one
meets the criteria, the fix will be have to wait until
JDK6 update 1.

Thanks,
Dmitri

jansan
Offline
Joined: 2005-02-24

Dmitri,

thanks for the information. I am not sure what the definition of a "showstopper" is, but this bug renders many UIs unusable. Just take the simple test case in the bug report. How is the user supposed to know if he has selected millimeter or centimeter?

Also, this bug does not occur in JDK 1.5 and I read somewhere before that regression bugs are showstoppers, so I do have some hope that Sun's qualitiy standards are high enough to make sure the bug gets fixed for the final release.

trembovetski
Offline
Joined: 2003-12-31

I understand your concerns.

Please vote for the bug, and add comments - so that the folks who make the decision on whether to fix it in jdk6 have more input.

Regarding all regressions bugs as showstoppers - it depends on the regression, and the stage of the release it was discovered on. As the release date gets closer, the bar for allowed bugfixes gets higher - each bug fix can potentially introduce another regression, so there must be a cut off somewhere, or the software never gets shipped..

Thanks,
Dmitri

swpalmer
Offline
Joined: 2003-06-10

The sad thing is that this bug has been in JDK6 for a long time. I reported it ages ago. It was apparently fixed once already and *very* recently.

So speaking of bug fixes introducing regressions.. well the system you have now isn't working too well for that anyway. :)

Should I even ask why there is no regression test for this, since it keeps coming back?

Regardless of what Sun thinks, this is certainly a show stopper for my app. Why? Because we have this silly requirement that the text in the UI needs to be readable by our end users...

It's too bad that it's going to be painful for us to hold off on all the nice new features of Mustang because of something silly like this.

Edit: just found 6439971 which was "fixed" in b96.. and then broken again in b97.. sigh...

Message was edited by: swpalmer

trembovetski
Offline
Joined: 2003-12-31

I agree that this is a very bad regression. Not much I could do except for lobbying, though. The bug is currently slated for JDK6u1, I believe.

> So speaking of bug fixes introducing regressions.. well the system you have now isn't working too well for that anyway.

Yeah, it's not perfect. But it would have been worse without it, believe me (speaking from experience with some of the previous releases).

> Should I even ask why there is no regression test for this, since it keeps coming back?[/quote]

I've checked, indeed there were no regression test (a requirement for a putback, actually), and no explanation given why there weren't one. Not good.

Note that it's hard to write reliable automated reg. tests for GUI, though. And manual tests are pretty much useless because we just don't have enough QA people to run them..

Thanks,
Dmitri

Message was edited by: trembovetski

swpalmer
Offline
Joined: 2003-06-10

> > Should I even ask why there is no regression test
> for this, since it keeps coming back?
>
> I've checked, indeed there were no regression test (a
> requirement for a putback, actually), and no
> explanation given why there weren't one. Not good.
>
> Note that it's hard to write reliable automated reg.
> tests for GUI, though. And manual tests are pretty
> much useless because we just don't have enough QA
> people to run them..

Yes I know exactly what you mean.

I wonder if there is a way to use the debugger APIs to the VM to do some sort of automated test where you would simply put a break point in the code where the decision is made to truncate the text and add the "..."

If the break point is hit while running the test, you fail.

The idea being that you can avoid polluting the JRE code with stuff that is only there for testing purposes. E.g. no need for a way to peek at the internals to see if the string is truncated or not... though come to think of it that wouldn't be an entirely unwelcome API for a few Swing components. :)

Thanks for your lobbying efforts. I guess that u1 will be expected in winter 2007?

trembovetski
Offline
Joined: 2003-12-31

> I wonder if there is a way to use the debugger APIs to the VM to do some sort of automated test where you would simply put a break point in the code where the decision is made to truncate the text and add the "..."

That would be hard to implement and maintain, I think. Imagine that the particular could be moved/refactored, etc.

One approach we use in 2D is golden image comparison, but it requires some maintenance (like updating golden images when some correct code changes are made).

I think Swing folks also use similar framework for some of their tests.

> I guess that u1 will be expected in winter 2007?

Sorry, can't give you the exact date.

Dmitri

swpalmer
Offline
Joined: 2003-06-10

> > I wonder if there is a way to use the debugger APIs
> to the VM to do some sort of automated test where you
> would simply put a break point in the code where the
> decision is made to truncate the text and add the
> "..."
>
> That would be hard to implement and maintain, I
> think. Imagine that the particular could be
> moved/refactored, etc.

I'm thinking the point could be tagged in the source somehow with either a special comment or maybe even an annotation. That way the breakpoint would move around with refactorings etc.

> One approach we use in 2D is golden image comparison,
> but it requires some maintenance (like updating
> golden images when some correct code changes are
> made).
>
> I think Swing folks also use similar framework for
> some of their tests.

Yes this is the traditional approach, but as soon as Microsoft changes the skin for the combobox widget the "golden image" breaks. There could be other bug fixes that affect the look of a component (such as margins and font rendering) that would break it in a similar way. It's just a lot harder to maintain.

> > I guess that u1 will be expected in winter 2007?
>
> Sorry, can't give you the exact date.

Not looking for an exact date, just a ballpark as to what the general release schedule for updates is like. I'm assuming it will be a couple months after the initial release at least, but unlikely to be as long as six months.

It's unfortunate that a lot of effort went in to getting the Win LnF pixel perfect in so many areas and then something far more noticeable goes wrong like this.

leouser
Offline
Joined: 2005-12-12

have you tried working around the issue by writing your own renderer?

leouser

swpalmer
Offline
Joined: 2003-06-10

> have you tried working around the issue by writing
> your own renderer?
>
> leouser

No. I'm not sure what it would take and I don't really want to have to hack it at that level.

Is EVERYONE going to work around this issue by writing thier own renderer?
What about applications that are already deployed that will simply start running with a new JRE?

This breaks ALL Swing apps with a JCombobox running the Windows Look and Feel. It's a big deal. I consider it a show stopper without the slightest hesitation... but I've done my part... I reported it, watched it get fixed, watched it get broken again in the very next build (though I wasn't testing frequently enough with JDK6 to notice until it was already reported again here)... and now I've voted for the bug and added my comments.

It's on Sun now to consider the ramifications of releasing Java 6, that they've already touted as having great LnF fidelity improvements for Windows, where now the UIs in many cases won't even be readable. Who cares at this point that the components are no longer off by a few pixels in one dimension or another?

Somebody blogged about the Win LnF improvements a while back and I commented specifically about this bug since it had yet to be fixed from when I first reported it. It happened that internally it had just been fixed at that time. So I was happy and was glad to see all the other "single pixel" fixes as well. Now were right back to having the components aligned just right on Windows, you just can't read the text is all. :)

In my opinion it would make more sense to roll back the "fix" for the skinning issue that broke this, if it's too late to apply a new fix now.

The shortened string may not seem like a big deal at first, until you realize that there are a lot of comboboxes out there with entries like "Mode 1", "Mode 2" where what is cut off is effective ALL of the relevant information, or enough to make the current selection totally ambiguous.

I don't want to sound like I'm putting down the great work that the Swing team has done for Java 6. I'm very thankful for it. But I feel the need to make noise about this issue because, even though it's just one step back amoung many steps forward... this step counts for a lot.

jansan
Offline
Joined: 2005-02-24

I would like to emphasize what swpalmer wrote:

1. The bug is not a cosmetic problem!
2. The bug can make a GUI unusable in these situations:
- You have a combo box with item that only differ at the end ("item1", "item2", "item3", etc.), because in some cases all the user will see is something like "ite...".
- You have a combo box with very short items, like "cm", "mm", "in". In some cases all the user will see is "...".
3. Writing a custom renderer (or changing the size of each combo box) will only work for new applications, but we will rather wait for 1.6.0_1 than having to carry around another dirty hack for the rest of our life.
4. The bug was introduced by a fix for a far less severe bug, that only affected very few users. A rollback of that "fix" would make things much better.

Still one and a half months time to find a solution.

jansan
Offline
Joined: 2005-02-24

We can stop the discussion here. According to the bug evaluation this does not qualify as a showstopper and will not be fixed before update 1. Very frustrating.