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.
Summary: | Disabling remote Javadoc inside JavadocHelper.getJavadoc | ||
---|---|---|---|
Product: | java | Reporter: | Kenneth Ganfield <kganfield> |
Component: | Source | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jglick, pjiricka, tzezula, vieiro |
Priority: | P2 | ||
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Mac OS X | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 41443 | ||
Attachments: |
messages.log
profiler snapshot when lenght operation dialog appears |
Description
Kenneth Ganfield
2011-01-24 12:47:11 UTC
Created attachment 105301 [details]
messages.log
attaching messages log file
bumping priority up to p2 because this really makes a lot of functionality such as hints and fix imports unusable for me. The workaround seems to be to type or paste some code, then wait 5 or 10 minutes, then fix imports, which is extremely inconvenient I rarely see the dialog (normally only in case the IDE is swapped off, or is scanning is running). Could you please generate some profile me snapshots so that we can see what is taking the time? Thanks. http://wiki.netbeans.org/FitnessViaPartnership Created attachment 106718 [details]
profiler snapshot when lenght operation dialog appears
adding profiler snapshot
Thanks for the snapshot. The problem is quite clear now: the TreeLoader tries to load javadoc for a class using JavadocHelper.getJavadoc(Element). This method itself may still do a network connection. If this network connection fails after a significant amount of time, which is what seems to happen in Ken's case, the JavadocHelper will try this connection each time again, each time taking the time to fail. I personally do not see a different solution than to allow disabling of the remote Javadoc on JavadocHelper.getJavadoc level: http://hg.netbeans.org/jet-main/rev/81a128e62b1e Tomas worked on this most recently I think. Fix seems reasonable; remote Javadoc is intended for viewing but should not be used for obtaining method parameter names and the like (unless perhaps a cache is implemented). Better would be if -g:vars were used when compiling important APIs, I guess. Can java.source retrieve param names from bytecode where present? I was fixing the code completion. This problem is a bit different, the http request is done from TreeLoader before the tree loader gets the TextStream to be able to check if it's remote. Integrated into 'main-golden', will be available in build *201103090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/81a128e62b1e User: Jan Lahoda <jlahoda@netbeans.org> Log: #194653: really disabling remote javadoc in TreeLoader. *** Bug 196788 has been marked as a duplicate of this bug. *** I'm afraid I'm still seeing this in Product Version: NetBeans Platform Dev (Build 201103120400) Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02-334 System: Mac OS X version 10.6.6 running on x86_64; MacRoman; es_ES (test) Userdir: /Users/antonio/.netbeans/dev A stack trace available at http://netbeans.org/bugzilla/show_bug.cgi?id=196788 Case from http://netbeans.org/bugzilla/show_bug.cgi?id=196788 fixed in jet-main. http://hg.netbeans.org/jet-main/rev/d3285b4c63ea *** Bug 194017 has been marked as a duplicate of this bug. *** |