<Swing Dev> Patch for NPE at javax.swing.plaf.basic.BasicTreeUI$Actions.page:4470

[Alexander Scherbatiy]

On 11/16/2012 4:10 PM, Jaroslav Tulach wrote:
> Hello Alexander,
> thanks for your reply. The source code for NetBeans TreeView component is
> available here:
> http://hg.netbeans.org/main-
> golden/file/ccea2dfe47eb/openide.explorer/src/org/openide/explorer/view/TreeView.java
> I'll be glad for any review, however I am also positively pleased by your
> answer:
     Is it possible to know from the filled NB issues which NB 
module/component has been used when the NPE occures?
     Or could you point any NB panel where the  TreeView is used.
>>       The ui.getPathBounds(tree, newPath) method definitely can return
>> null so it needs to have this check.
> Should I start working on a webrev, so (in case you don't find any violation of
> good Swing practices in TreeView) we can eliminate this NPE once and forever?
     Yes, please.
> What should be part of such webrev? Just the NPE check? Or do you want some
> test, change in documentation, etc.?
     The fix should check the NPE and may be do some possible default 
actions in this case.
     It is a good idea to add an automated test but it can be possible 
if there are known steps which reproduce the issue.
     At least you can run the test/javax/swing/JTree  automated test to 
check possible regressions.

     Thanks,
     Alexandr.

> Thanks again for your comments.
> -jt
>
>
> Dne Pá 16. listopadu 2012 15:30:00, Alexander Scherbatiy napsal(a):
>> On 11/15/2012 7:58 PM, Jaroslav Tulach wrote:
>>> Dear Swing maintainers,
>>> my name is Jaroslav Tulach and I am maintaining NetBeans explorer - a
>>> component that is using JTree heavily.
>>>
>>>>  From time to time I receive a user report with a NPE from Swing where
>>>> little>
>>> or even no NetBeans code involved. Just today I got
>>> http://netbeans.org/bugzilla/show_bug.cgi?id=222081
>>> We have about 35 other ones (which is not that much given the fact we have
>>> million of users), but still...
>>>
>>> According to
>>> http://statistics.netbeans.org/exceptions/exception.do?id=628832
>>> the report comes from jdk7u9-b05. The source code is here
>>> http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/jdk7u9-
>>> b05/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
>>> and thus it looks like the call on line 4468 to
>>>
>>> ui.getPathBounds(tree, newPath);
>>>
>>> can return null (under some rare and unknown circumstances).
>>>
>>> I can close the bug #222081 as "worksforme", but it is clear that such
>>> error happens from time to time and we don't want our users to face
>>> errors. A simple:
>>>
>>> 4469 if (newRect == null) return;
>>>
>>> would do the trick. One question remains: if I try to donate such patch,
>>> will you accept it?
>>       The ui.getPathBounds(tree, newPath) method definitely can return
>> null so it needs to have this check.
>>       However, such fix can mask the real issue, for example, in the
>> treeState.getBounds() method where the  treeState can be instance of
>> FixedHeightLayoutCache or VariableHeightLayoutCache class.
>>
>>       If it is possible, could you send a code snippet that shows how
>> NetBeans uses JTree? May be it can give a hint what can be wrong in this
>> case.
>>
>>       Thanks,
>>       Alexandr.
>>
>>> -jt