Andrei Dmitriev's Blog

J2SE Archives

77 unrequited votes

When there were no other tasks I've gathered a requests statistics on the GridBagLayout class changes. I considered both defects and RFEs. By the way, we seem have to refuse that division and treat each defect now as RFE.

I was surprised by the fact that there are only 14 CRs inquire one or another change in the GridBagLayout class behavior. Believe, we have more defects in this class than are reflected in our defect database. Wow, it seems we should not take the joke about changing the name of that class by replacing first “a” to “u” seriously!

Some of known defects
(4238932, 4126689 ) have already went through a standard procedure on a
contribution forum.
We already accepted the fix for 4222758 and targeted it into Dolphin. Thanks, LeoUser! :)

But the result of our collaboration with developers still can not be considered very successful. Why?

*A couple of words about the compatibility*

The only reason why the patch that is fixing a critical issue can not be integrated into the JDK master workspace is the broken compatibility.

As usual a patch that is developed by an engineer passes reviews, approvals, and comprehensive testing. This process happens in several stages and accomplishes by different teams.

All these efforts are intended for the only one goal – (surprise-surprise!) the programs that worked with previous versions of JDK must keep working with each new version. And we are really trying to follow that rule :)

So, when a user submits a patch via the , that patch is also passing exactly the same standard procedures.

Ideally, we should find 100% possible issues on the testing stage and don't pass them into release. In the end, this is what we expect expanding a testsuite with a new testcase for each bug-fix.

Thus, I mentioned a key term of this article – a testsuite. The more regression tests are in our testsuite – the stronger possibility that we will not miss any issue just before the integration.

The test itself is assigned to verify in program that documentation is in accordance with the implementation. Sometimes it just verifies a reasonable behavior since the documentation for some aspect is absent.

*Documentation*

Usually tests are written based on some existing documentation assertions. In particular, from JavaDoc.

But in some cases the documentation may not be considered good or complete. The GridBagLayout class is the case here. By historical reasons that implementation includes much more nuances than described in the documentation.
Some details may just be missed indeed.
So far, an ordinary developer should rely on the current JDK behavior and design GUI in accordance with his/her current experience.

Therefore a migrating to the next (or just to another) JDK version may cause some unpleasant effects.

A user falls into confusion and asks us to fix it. Or just fix the problem by himself in his particular JDK. :)

Thus, we have a poorly documented (lets call this so:) class and, as a sequence, a lack of test coverage. For example, a recent attempt to integrate a fix for 4238932 led us to “unpatching” that fix after it was integrated into the master workspace because the result really impacted other applications. We didn't find the solution that satisfies both sides. That defect is still opened and awaiting for a contribution! :)

*Solution*

We know that many people use this layout manager. As a library developer I can't spend much time on writing industrial applications that use the GridBagLayout class.

Probably you develop such applications. That is why I came to the following idea. If we could create a reliable testsuite for the GridBagLayout class this testsuite may compensate a lack of documentation. Perhaps this testsuite will greatly help to make changes in GridBagLayout in future. This will also noticeably decrease the risk to broke the fix. We will verify the patch before the users (you) can do the same with released JDK. :)

I don't know how we will interact while creating that GridBagLayout testsuite. Most likely I'll post a new defect on to the peabody forum. (try this one: 6450943) Every interested person would now be able to post a test. Also we need some rules how to design them. The following rules are already in my mind:

1. the test must be as short as possible
2. one should be written on AWT not on Swing. I'm almost sure that any problem with layouting of Swing components might also be reproduced with AWT ones. Actually, I love Swing but it's too hard to look both into AWT and Swing code :) But if you feel that the problem is Swing-specific - feel free to post that test.
3. it must say something like “Test passed” or “Test failed” when finish.

What's your interest in this venture?

*Result*

A functioning test that is included into the testsuite guarantees that none of future fixes will break the test's behavior which in its turn reflects your application! I just realized that there is actually no 100% guarantee to avoid that situation. To be honest we may change something and intentionally break some regression test, however this happens rarely. Nevertheless, the life is an unfair thing itself and I should warn about it.

From our side we are interested in that all applications keep working as it was planned . Moreover, I like that I can review peabody fixes faster. :)

*Conclusion*

At the very beginning I said that “But the result of our collaboration with developers can not be considered very successful.” Should I call the result a collapse? Definitely no. I think those attempts if even they were not very successful gave us an invaluable experience and we can apply it right now.

Thanks,
--Andrei

To Fix or "Will not fix"

Usually developer starts to work on some issues from understanding the problem. A description represents a problem in a general. Unfortunately the actual difficulties of any particular user are hidden behind the common phrases.

A description is intended to be impersonal, which gives to a developer a chance to clearly understand the problem, evaluate it and find the most effective way to resolve.

Priority

The importance of any particular issue is determined according to its priority. The Priority in its turn defines how fast the issue will be processed. (such is the case in an ideal world :))

But the life is very unfair and a user once filled the form (i.e. reported a bug) then has a very limited ability to affect that issue. He couldn't participate in discussion etc.

All comments are truncated from a bug report so a user could only add them via Sun site (look at the bottom of any CR).

It makes an illusion of involvement but these comments are not assigned by internal bug tracking system with a particular bug report.

Yes, it looks rather complicated.

But there is another way to affect developers within Sun.

These lists are generated with respect to users feedbacks. Every registered user could vote for (or against) one or another bug or enhancement. The number of votes is taken into consideration for the defect priority estimating.

The more votes - the higher priority! This is rather simple and might be already known to most users.

However, there is another way : forum.

How could it help to an ordinary user? The point is that all messages from that forum are read by Sun engineers. If even a responsible engineer just skipped a message any other engineer can answer or request a right person to help.

Well, I can share with you a true story from Sun.

Some time ago we've received a request 6404008.

An engineer, responsible for that area has already fixed a similar defect (that is, here is that defect 5039416) and was pretty sure that this is not a defect any more.

And such is the real case: If we look on it with curiosity then we could notice that these defects (well, patches for them) contradict to each other or something like that.

Considering the ponderability of the first defect (it had a lot of votes) we just decided not to fix it in order to avoid users' disappointment and not to change the current behavior. And this is an exact scenario if user submitted a second bug stopped here. But instead he came to forum () and asked a community opinion on this.

His message (well there were a lot of them) were reviewed by our engineers and they initiated the internal discussion.

Finally the problem was described more in detail, a fragment of code that certainly doesn't work with that fix was posted in the forum, and a class of applications affected by that fix was described as well.

At last we re-opened the bug back. Have I already mentioned that the bug was closed as "Will not fix" in the first day of it's life? :)

I should also note a number of votes against that defect. It grew up to 12 in two days.

As far as I understood the colleagues of the submitter also presented their votes for him.

These consolidated efforts lead us to the fix for the critical bug shortly. Lets call a critical bugs those ones which are important to users.

What is this story about?

First of all, we are interested in your opinion on every our change. We want to draw your attention and give you a new capabilities to improve your products, make them more simple and attractive. We hope that our cooperation will be mutually beneficial.

All you need to do is to report a problem to Sun engineers using one of these methods. Believe there are also another ways!

If this problem is really important (you probably know how to increase its priority now :) ), solutions will appear very soon!

Good luck!

This work is licensed under a Creative Commons License.