Community
Participate
Working Groups
See bug 84728. The IMethod.getParameterNames API documentation says, "Returns the names of parameters in this method. For binary types, these names are invented as 'arg'+i, where i starts at 1 (even if source is associated with the binary)." The last part is not true (see org.eclipse.jdt.internal.core.BinaryMethod.getParameterNames). The JVE uses this API to retrieve parameter names and the invocations associated with the rt.jar reads in 23.6M of data out of src.zip and costs us a considerable performance hit. Note that the src.zip file itself is only 11.8M, so apparently the JDT is reading it multiple times.
Note: The above data was collected with FileMon, available at http://www.sysinternals.com/ntw2k/source/filemon.shtml. It is a very easy to use utility for capturing I/O events.
I see 2 ways to solve this problem: - Fix the spec to say that the attached source is used, and provide another method (e.g. getRawParameterNames()) that return the invented named for binary methods - Fix the implementation, and provide another method (e.g. getSourceParameterNames()) that return the names from the attached source
Given the APIs docs., we will vote for the first option, as to not break those that are relying on the current implementation.
We now calling this in a lazy manner, for which time we will always want the src. name.
Jérôme, Now that bug 110173 is fixed, it would be possible to get the parameter names from the attached javadoc. I will attach a patch for this.
Created attachment 29699 [details] Proposed patch for parameter names from attached javadoc Now we simply need to add the getRawParameterNames() throws JavaModelException method and this PR can be closed.
Once this is done, let me know. I have some regression tests that could be enabled in the AttachedJavadocTests suite.
Created attachment 29719 [details] Proposed patch for parameter names from attached javadoc I changed the API to reflect the fact that the naming starts at arg0 and not arg1, when no name can be retrieved. This is the actual behavior.
Applied patch (thanks Olivier) and added IMethod#getRawParameterNames(). Added tests ClassFileTests#testParameterNames01/02 and testRawParameterNames01/02.
Verified for 3.2 M4 using build I20051212-0010
