This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE Dev (Build 200803170003) VM: Java HotSpot(TM) Client VM, 10.0-b19 OS: Linux, 2.6.24-12-generic, i386 User Comments: Simple: More encapsulated JPanels. More elaborate: I created a new Java Application, and I insertd new JFrame form. Then, I inserted a JPanel in the form (and I manually docked it in the bottom) and I changed the color of this panel to Green. After that, I inserted one more pannel, changed its color to red and I docked it to top of the form. I inserted two JButtons and one panel (and changed its color to yellow) in the upper (red) panel. When I attempted to insert a new panel in the yellow panel (which was contained in the red panel), exception was thrown.
Created attachment 58564 [details] stacktrace
I am sorry, I am not able to reproduce this issue. Could you, please, provide more details. It would be ideal to attach the corresponding .java and .form files (saved in the last good state) and describe _exact_ steps that should be done to see the exception. Thank you in advance.
It is not reproducible after regular (I didn't find scenario) steps. However, I did reproduce it. Just put like 5 panels in the JFrame and play with them: resize, remove, change their order, encapsulate them to each other, ... just play with the panels in the JFrame... Adding a keyword RANDOM
I doubt there is anything random in this problem. The layout algorithm used in GUI builder produce always the same result, but the result may depend heavily on small details (e.g. where exactly is the component dropped etc.) It doesn't help at all to suggest me "just play with the panels in the JFrame...". This bug report is useless without exact steps to reproduce.
Well, first - I adore your attitude. "The bug report is useless" - it was submitted using built-in bug reporter, demand your colleagues. Second, you made a great observation - computers are in principle deterministic machines, so anything that happens there is potentially reproducible and there are definitely no "random" issues (if we don't count the cosmic rays and stuff, that are deterministic as well though). However, if you follow the guidelines from http://www.netbeans.org/issues/describekeywords.cgi, you will see that this issue matches the definition of RANDOM, as it speaks only about ability to reproduce and frequency (that's what random means). When anyone is able to reproduce the issue, he/she will remove the RANDOM keyword, up till now it remains there. Assigning a RANDOM keyword again. If you think the issue is so easy, you will be definitely able to reproduce it from the stack-trace, just like anyone else does. Second, when I work with the IDE, there is like 20 exceptions a day. If I was just a regular user of NB, I would be pretty frustrated. The suggestion was quite accurate - you can get an exception quite often (I don't even send all of them) if you just play with the panels. Finally, I will do my best to reproduce it, as soon as I can manage to do that, I will let you know.
OK, let's clarify my last comment that made you so offended. I don't want to start a flame war or philosophical discussion about randomness in computer science. I believe that RANDOM keyword belongs to issues that are not always reproducible if you repeat the same user gestures in the IDE e.g. the result may depend for example on thread scheduling (e.g. things that user cannot affect). By removal of the keyword I just wanted to point out that this is not the case here. I see that you have a different oppinion on that. Hence, feel free to keep the keyword there if you want to (it doesn't harm anyone). The essence of this comment was to make you aware about subtle differences when placing/resizing/moving components in Free Design. If you concentrate on them then you have a better chances to provide reproducible test cases. > If you think the issue is so easy, you will be definitely able to reproduce it from the stack-trace, > just like anyone else does. Some problems can be identified just from the stack trace and make sure that I always scan the source code to guess what can cause the problem. Unfortunately, it is not possible in GUI builder quite often. The exception is usually thrown by some low-level algorithm that got into an unexpected state and it is not clear (without the knowledge of the context e.g. the form) why this occured and what should be done in this case. This is also the reason why this bug report is not usefull without exact steps to reproduce, unfortunately. Note, that it does not help to tell me to find the problem myself. Why would I need a bug tracking system and quality engineering with this approach?
jstola, you don't need to worry :o) - I was not offended. I was more surprised - the stack trace tells you that it is not an exception, but an assertion error. Furthermore, there are modules and exact line numbers specified. I didn't expect any complications with resolving this issue then. Java.lang.AssertionError at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.fillGroup(SwingLayoutBuilder.java:266) at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.composeGroup(SwingLayoutBuilder.java:232) at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.fillGroup(SwingLayoutBuilder.java:251) at org.netbeans.modules.form.layoutdesign.support.SwingLayoutBuilder.composeGroup(SwingLayoutBuilder.java:232) I submitted the issue using the built-in exception reporter, I could have also just let it go, but " Why would we need a bug tracking system and quality engineering with this approach?". I got the same issue about 3-4 times just yesterday - it appeared intermittently and I didn't manage to reproduce it. > RANDOM: This issue occurs intermittently and cannot be reproduced reliably. If you are at work we can discuss it on coffee break.
Closing the issue as non-reproducible for now. Feel free to reopen if you are still able to reproduce it, but don't forget to provide exact steps to reproduce then. Thank you in advance.
Verified
Reopening - reproduced in NetBeans IDE 6.5 Beta (Build 200808111757) http://statistics.netbeans.org/exceptions/detail.do?id=131399
This issue was reopened by Exception reporter, unfortunately no additional info that could help to reproduce the problem can be found in the report. I still cannot reproduce this :/ Closing for now as WORKSFORME. If anyone manage to reproduce this reliably, please reopen. Thanks
V.
*** Bug 180298 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > This issue was reopened by Exception reporter, unfortunately no additional info > that could help to reproduce the problem > can be found in the report. That just means that the assert statement is inadequate. The form module needs to be fixed to somehow audit actions that are taken by the user and their effect, so that if and when a seemingly impossible situation is encountered, the assertion error includes all the information needed for a developer to diagnose the problem.