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.
Another problem today; somewhat similar to issue #47423 but not quite the same. 040820 custom, 1.5 b62. I had opened AntBasedTestUtil.java (ant/project) and gone to the method countTextDiffs. Putting the caret on the method call in Difference[] diffs = dp.computeDiff(r1, r2); I tried to use Alt-G. Nothing happens. Code completion on the method shows that the method is recognized, but no Javadoc is displayed - as if there were no sources available. But sources *are* available, in diff/src. (UnprojectizedSourceForBinaryImplTest in apisupport/project tests this exact example; the test passes for me.) So I start the IDE with a test user dir (the same used for issue #47423) - open just ant/project, open AntBasedTestUtil.java, try to use Alt-G etc. from that method call. Does not work. Then I shut down the IDE and start it with logging enabled for the NBM project type. Had to kill the IDE during early startup due to some deadlock (filed separately), then it started OK. Now Alt-G works on that method call, and code completion shows the correct Javadoc. The NBM project logging indicates that the correct classpath was indeed created for ant/project/test/unit/src. However UnprojectizedSourceForBinaryImpl, which would be responsible for serving diff/src as the source equiv to jar:file:/space/src/nb_all/nbbuild/netbeans/ide4/modules/diff.jar!/, was never called as far as I can tell. So I don't know what is going on here exactly. This class of problem is often difficult to reproduce from scratch. There needs to be some logging flag (e.g. ErrorManager category) I can turn on to get more information. In particular, when the editor fails to do anything as a result of Alt-G, or fails to find Javadoc for a method or class, it should (optionally) log a precise description of why it did not find anything suitable.
Adding Martin to CC, might be related also to javacore.
Could be a javacore issue; hard to tell. There are other circumstances where code completion simply fails to work, sometimes - in a variety of different ways, from not showing any completion popup at all, to not having the right Javadoc, etc. In general it is hard to make a test case because it often begins working if you simply restart the IDE, yet I see some sort of bug like this every day I work with the IDE. Would be invaluable to have some kind of diagnostic mode so that I could produce more useful bug reports. Just disabling the code completion features when something goes wrong is probably the best thing from an end user perspective, but it hides the root causes of a lot of bugs.
Yes, I agree that some sort of diagnostics could help us to find out what exactly went wrong during the context evaluation. I think that we could log some shorter messages for the cases when the completion cannot go on. E.g. Variable 'x' declaration not found. Type 'X' not resolved. Method 'm(String,int)' of type 'X' not found. etc. Dusan will work on this.
Debug messages added to code completion (available when IDE is run with the "org.netbeans.editor.debug.completion.failures" property set to true). Checking in JMIUtils.java; /cvs/editor/src/org/netbeans/modules/editor/java/JMIUtils.java,v <-- JMIUtils.java new revision: 1.45; previous revision: 1.44 done Checking in NbJavaJMICompletionQuery.java; /cvs/editor/src/org/netbeans/modules/editor/java/NbJavaJMICompletionQuery.java,v <-- NbJavaJMICompletionQuery.java new revision: 1.29; previous revision: 1.28 done
Running IDE with debug messages, it seems that I found the root cause of your problems. These problems should affect all projects that compile class files to the same directories with their sources (case of diff module). Since extents are created in MDR per source root, there are extents that can contain two JavaClass elements of the same name. Resolving such name, it is not deterministic whether the class index returns JavaClass element that comes from *.java file or *.class file. In case of "bad luck", the element based on *.class is returned which provides no position info (Alt-G does not work) nor JavaDoc. Reassigning to javacore for further evaluation.
Fixed. Checking in src/org/netbeans/modules/javacore/JMManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v <-- JMManager.java new revision: 1.48; previous revision: 1.47 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/javacore/scanning/ClassUpdater.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/ClassUpdater.java,v <-- ClassUpdater.java new revision: 1.6; previous revision: 1.5 done
*** Issue 47777 has been marked as a duplicate of this issue. ***
Reorganization of java component