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.
[dev jul 08] 1. Create build with -Dmodules=editor,java,classfile,java/api,javadoc and start on fresh userdir. 2. Mount nb_all/openide/src sources (plain local filesystem). Wait for background parser DB update to finish (watch CPU activity). 3. Create a new Java source and open it in the editor. Type new DataFolder and Alt-Sh-I to import org.openide.loaders.DataFolder. Type new DataFolder().add and scroll to void addSecondaryEntry(MultiDataObject.Entry fe) No Javadoc is displayed, though the source code has Javadoc. Inner class problem? The header for the popup that would show Javadoc (above "Javadoc not found...") shows protected final void addSecondaryEntry(org.openide.loaders.MultiDataObject$Entry fe) Same for removeSecondaryEntry. Other methods seem fine. P.S.: If you have apisupport/apidocs also enabled, so that the prebuilt OpenAPIs.jc[bs] is there, it seems that the package-private MultiDataObject.removeFile(FileObject) is also listed, though I have no idea why. Probably a separate bug. Neither of OpenAPIs.jc[bs] mentions this method (I searched in binary, and it was built with public + protected levels), so it must have been picked up by the automatic scan.
fixed in [maintrunk] /cvs/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java,v <-- NbCompletionJavaDoc.java new revision: 1.21; previous revision: 1.20 DIFF: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java.diff?r1=1.20&r2=1.21 Yes, Jesse. The problem was in the inner class. Parameter type was represented as Class$InnerClass, that's why ClassElement.getMethod didn't find the method with the parameter with '$'. Do you think, this bug should be integrated into release 34 branch also?
I think this is a reasonable candidate for a release34 merge - it is unambiguously a bug (not just "undesirable behavior") and the fix looks pretty simple. By the way I think there is a small problem in the patch, if I understand correctly - consider an inner class of an inner class, e.g. void org.somepkg.someMethod(Outer$Middle$Inner) Will this get completed properly? I think the if-statement with innerMarkPos should really a while-loop or something like that. Compare String.replace(char,char) which would do the right thing.
Thanks Jesse, I refined the fix for replacing and applied the fix for constructors also. /cvs/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java,v <-- NbCompletionJavaDoc.java new revision: 1.22; previous revision: 1.21 DIFF between version 1.20 and 1.22: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java.diff?r1=1.20&r2=1.22 Mila or Jesse, please review and approve this fix for release 34. Thanks.
I'm not exactly qualified to review the diff (esp. 2nd half) but it looks sensible. For clarity, I would change getBoldName to move the decl of StringBuffer sb and the return statement inside the if-clause, but the semantics is the same. If you want to put this in 3.4, please post to reviewers@netbeans.org as usual.
I have refactored the getBoldName. /cvs/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java,v <-- NbCompletionJavaDoc.java new revision: 1.23; previous revision: 1.22 Complete diff between versions 1.20 and 1.23: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java.diff?r1=1.20&r2=1.23 Mila, could you please review it? Thanks.
I have reviewed the fix and it should be OK.
integrated into [release34] /cvs/editor/src/org/netbeans/modules/editor/java/NbCompletionJavaDoc.java,v <-- NbCompletionJavaDoc.java new revision: 1.20.8.1; previous revision: 1.20
Resolved for 3.3.x or earlier, no new info since then -> closing.