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.
Exception is 100% reproducible on WinXP and Win2K, it isn't reproducible on JDS2, Linux RH9, Sol9, Sol10 The code from MeasureIDEStartupTimeOpenedFilesPrepare.openFiles : --------------------------------------------------------------------------------- public void openFiles(){ String[][] files_path = { {"bsh","Interpreter.java"}, {"bsh","JThis.java"}, {"bsh","Name.java"}, {"bsh","Parser.java"}, {"bsh","Primitive.java"}, {"com.microstar.xml","XmlParser.java"}, {"org.gjt.sp.jedit","BeanShell.java"}, {"org.gjt.sp.jedit","Buffer.java"}, {"org.gjt.sp.jedit","EditPane.java"}, {"org.gjt.sp.jedit","EditPlugin.java"}, {"org.gjt.sp.jedit","EditServer.java"} }; Node[] openFileNodes = new Node[files_path.length]; SourcePackagesNode sourceNode = new SourcePackagesNode("jEdit"); // create exactly (full match) and case sensitively comparing comparator Operator.DefaultStringComparator comparator = new Operator.DefaultStringComparator(true, true); sourceNode.setComparator(comparator); for(int i=0; i<files_path.length; i++) { openFileNodes[i] = new Node(sourceNode, files_path[i][0] + '|' + files_path[i][1]); } // try to come back and open all files at-once, rises another problem with refactoring, if you do open file and next expand folder, // it doesn't finish in the real-time -> hard to reproduced by hand new OpenAction().performAPI(openFileNodes); // check whether files are opened in editor for(int i=0; i<files_path.length; i++) { new EditorOperator(files_path[i][1]); } } --------------------------------------------------------------------------------- org.netbeans.junit.AssertionFailedErrorException: Exception in Path selecting at org.netbeans.jellytools.JellyTestCase.runBare(JellyTestCase.java:143) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:123) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:176) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:127) at org.netbeans.xtest.plugin.ide.MainWithExec.run(MainWithExec.java:194) at org.netbeans.xtest.plugin.ide.Main$2.run(Main.java:277) at java.lang.Thread.run(Thread.java:595) Nested Exception is: org.netbeans.jemmy.JemmyException: Exception in Path selecting at org.netbeans.jemmy.QueueTool.invokeAndWait(QueueTool.java:407) at org.netbeans.jemmy.QueueTool.invokeSmoothly(QueueTool.java:337) at org.netbeans.jemmy.operators.ComponentOperator.clickMouse(ComponentOperator.java:431) at org.netbeans.jemmy.operators.ComponentOperator.clickMouse(ComponentOperator.java:450) at org.netbeans.jemmy.operators.JTreeOperator.clickOnPath(JTreeOperator.java:1126) at org.netbeans.jemmy.operators.JTreeOperator.clickOnPath(JTreeOperator.java:1140) at org.netbeans.jemmy.operators.JTreeOperator.clickOnPath(JTreeOperator.java:1150) at org.netbeans.jemmy.operators.JTreeOperator.clickOnPath(JTreeOperator.java:1159) at org.netbeans.jemmy.operators.JTreeOperator.findPathPrimitive(JTreeOperator.java:2306) at org.netbeans.jemmy.operators.JTreeOperator.findPathPrimitive(JTreeOperator.java:2323) at org.netbeans.jemmy.operators.JTreeOperator.findPath(JTreeOperator.java:612) at org.netbeans.jellytools.nodes.Node.findSubPath(Node.java:373) at org.netbeans.jellytools.nodes.Node.findSubPath(Node.java:364) at org.netbeans.jellytools.nodes.Node.<init>(Node.java:82) at org.netbeans.jellytools.nodes.SourcePackagesNode.<init>(SourcePackagesNode.java:36) at startup.MeasureIDEStartupTimeOpenedFilesPrepare.openFiles(MeasureIDEStartupTimeOpenedFilesPrepare.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at org.netbeans.junit.NbTestCase.runBare(NbTestCase.java:136) at org.netbeans.jellytools.JellyTestCase.runBare(JellyTestCase.java:116) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:123) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:176) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:127) at org.netbeans.xtest.plugin.ide.MainWithExec.run(MainWithExec.java:194) at org.netbeans.xtest.plugin.ide.Main$2.run(Main.java:277) at java.lang.Thread.run(Thread.java:595) Inner exception: java.lang.NullPointerException at javax.swing.ToolTipManager.initiateToolTip(ToolTipManager.java:467) at javax.swing.ToolTipManager.mouseEntered(ToolTipManager.java:424) at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:242) at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:241) at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:241) at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:241) at java.awt.Component.processMouseEvent(Component.java:5497) at javax.swing.JComponent.processMouseEvent(JComponent.java:3093) at java.awt.Component.processEvent(Component.java:5253) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3955) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3803) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at org.netbeans.jemmy.QueueTool$JemmyQueue.shortcutEvent(QueueTool.java:574) at org.netbeans.jemmy.QueueTool.shortcutEvent(QueueTool.java:137) at org.netbeans.jemmy.QueueTool.processEvent(QueueTool.java:117) at org.netbeans.jemmy.drivers.input.EventDriver.dispatchEvent(EventDriver.java:67) at org.netbeans.jemmy.drivers.input.MouseEventDriver.dispatchEvent(MouseEventDriver.java:163) at org.netbeans.jemmy.drivers.input.MouseEventDriver.clickMouse(MouseEventDriver.java:77) at org.netbeans.jemmy.operators.ComponentOperator$2.launch(ComponentOperator.java:433) at org.netbeans.jemmy.QueueTool$QueueAction.run(QueueTool.java:534) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at org.netbeans.jemmy.QueueTool$JemmyQueue.dispatchEvent(QueueTool.java:581) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Please, could you provide more info how to reproduce in NetBeans? We need either a test code to reproduce or manual steps to achieve state when it failed. I have no idea what jEdit is in this "new SourcePackagesNode("jEdit");" means. Also JDK version and screenshot are important. Please, next time attach java files and stack traces to issue. Description field is unreadable when placed inline.
> Please, could you provide more info how to reproduce in NetBeans? I am not sure what exaclty are you asking for ? > We need either > a test code to reproduce or manual steps to achieve state when it failed. The test code : http://performance.netbeans.org/source/browse/performance/test/unit/src/startup Manual steps to reproduce ???? > I have no idea what jEdit is in this "new SourcePackagesNode("jEdit");" means. jEdit is the name of the preopened project > Also JDK version and screenshot are important. JDK = 1.5.0_02(fcs) I'll attach screenshot + jemmy.log file. > Please, next time attach java files and stack traces to issue. Ok, I will. > Description field is unreadable when placed inline. Hmm, Jirka you are the first one asking for attaching instead of placing inline, I used to attach stakk traces and all this stuff to issues, but if it isn't so long , as it is in this case, I am used to place all text inline, everybody are happy with that , except you .... But I promise for jelly I'll do it in the future ;) I would like to highlight one thing, this is 100% reproducible on our test4u machines WinXP and Win2K and 100% works on other OSs.
Created attachment 21053 [details] screenshot
Created attachment 21054 [details] jemmy.log
Created attachment 21055 [details] !!! correct jemmy.log !!!
Created attachment 21056 [details] readable stack trace
As far I as can see, this is not a Jemmy problem. You get a NPE from moving mouse: ava.lang.NullPointerException at javax.swing.ToolTipManager.initiateToolTip(ToolTipManager.java:467) at javax.swing.ToolTipManager.mouseEntered(ToolTipManager.java:424) at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:242) ... That has nothing to do with Jemmy. You got it on [Projects, jEdit] node, I think. There is, probably, no tooltip for the node, that's what I am guessing ...
It works fine in 200503172015 but it doesn't work in 200503201900 What has been changed these days ?
Have you changed jemmy version between 200503172015 and 200503201900? Anyway, I have no idea what happened there. This is not a jemmy bug.
No I haven't . Are there any other changes in Jemmy/Jelly between these two days ? I don't know who is responsible for this issue, do you ? It's not JDK issue, we haven't changed JDK, we haven't changed anything, except build and all libraries , and I think if it's 100 % reproducible you can't close it as INVALID ! Give me time to investigate....
Well, I guess it is something wrong in IDE. Similar issue with the same stack trace (NPE at javax.swing.ToolTipManager.initiateToolTip(ToolTipManager.java:467)) was filed against JDK (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4805978). It was evaluated that getToolTipText method should not be overridden or at least it should not return null anytime. I digged in IDE sources and find several places where getToolTipText() is overridden and returns null (e.g. org.openide.explorer.view.TreeView#getToolTipText). This could be potential root of problems. Maybe it was silently sleeping until recent days. As Marian investigated it started to fail between 200503172015 and 200503201900. The visual effect is a small black point below the cursor (look at attached screen shot or try to move cursor over a file in focused 'Search Results' view).
Could this be caused by Yarda's fix of issue #55332? 2005-03-17 07:57 jtulach * openide/src/org/openide/explorer/view/TreeView.java: #55332: Usual calls to repaint are done in guarded sections, so I am rescheduling the repaintSelection into it as well http://www.netbeans.org/source/browse/openide/src/org/openide/explorer/view/TreeView.java?r1=1.186&r2=1.187 Petr, please evaluate.
Hardly caused by Yarda's change. Yarda's change actually does no rescheduling, he keeps the code in the same (AWT) thread, only wraps it with a Children.MUTEX Moreover, rollbacking the change doesn't change the "dot" behaviour of search window. Why is this a P1? (OK, it affects testability, but is there a data loss? It is reproducible out of the test enviroment?)
Never return null from TreeView.getToolTipText: openide/src/org/openide/explorer/view/TreeView.java,v1.189
verified in NB4.1(200503281924)
> It was evaluated that getToolTipText method should not be overridden > or at least it should not return null anytime. I don't like that evaluation. Every swing component usually return null from the method. If you use setTTT(null), it will unregister itself from the TTM, but even if still registered in TTM, TTM checks the return value of getTTT for null everywhere except one place, so swing both provide null and check for it. Moreover, it is next to impossible to write a component with location-sensitive tips that would "correctly" unregister itself from TTM everytime it would yield a "no tip" (==null) for given location. My fix is incorrect, it causes a display of a small (2x2px) rectangle as a tooltip over areas that had no tooltip before. I'll roll it back.
Is there a better fix? BTW, a small (2x2px) rectangle was there before and after your fix as well. It is probably something different.
Re "small rectangle": Can you reproduce it manually with earlier builds? I do see the rectangle in the screenshot attached on March 23. However, I'm not able to reproduce it when I try to invoke tooltips with the official build from the same day. With the recent build (3/28), on the other hand, I can reproduce it quite reliably and it's pretty annoying. I agree with Petr that this needs to be revisited. Reopening.
Attached screen shots are from build 20050324-0408, JDK1.5.0_02, WindowsXP. I can reproduce it in Projects view in this build.
*** Issue 57091 has been marked as a duplicate of this issue. ***
Created attachment 21176 [details] "Black point" tool tip from navigator.
Created attachment 21177 [details] "Black point" tool tip from search view.
Ok, can see it in Navigator and Search View. Are you saying you can reproduce it with Projects view too? How?
The black point is always a consequence of returning empty String ("") instead of null from getToolTipText(). That is why I claim that returning null is the only correct thing and that the JDM is somehow broken. I can provide you with patched TTM to log interesting events so we can try to find out why it doesn't like nulls on some platforms. BTW: Certainly not a P1 anymore.
Petr, sorry it was filed as P1 because it caused failing Startup Performance tests, and if you rollback your previous fix it will do so. So I would be very happy , and I think you so , if we can measure startup again tomorrow, so rise priority again to P1.
To jchalupa: I CANNOT reproduce it with Projects view. I wrote 'can' by mistake.
Ok, but if you look at the very first attached screenshot from the automated test, you'll see that the tooltip failed to display in the Projects View. So, I suspect that this might point to the problem. Apparently, the automated tests can get the Projects View into the state that cannot be reproduced manually.
Marian, I'm in a violent agreement with you that we need to keep startup benchmarks working. This is why I hotfixed the problem ASAP and I'm not going to rollback the hotfix before we find what's going on. I just concluded the tests are running now so it is not P1 now (the dot thing is P3, right?) I have patched TTM and I need you (or jirka) to run with it (and without my hotfix) to find out what's going on in TTM. I'll attach a jar file that needs to be prepended to the bootclasspath for testing.
Created attachment 21184 [details] A patched TTM, please run the tests with older NB and -J-Xbootclasspath/p:TTM56825.jar
Created attachment 21263 [details] message.log with logs from patched TooltipManager
It seems that the root cause is the test sending events inconsistent with real mouse position/focus. I've rolled back the hot fix, the tests will be fixed by moving the mouse to slightly different location. openide/src/org/openide/explorer/view/TreeView.java,v1.190
We have still the same problem. I can't workarround this NPE, moving mouse to another position before selecting nodes didn't help. It has to be investigated again.move to performance module....
I hope (and it seems like) it has been fixed by my last commit http://performance.netbeans.org/source/browse/performance/test/unit/src/startup/MeasureIDEStartupTimeOpenedFilesPrepare.java?r1=1.18&r2=1.18.2.1
verified