Community
Participate
Working Groups
We have an eclipse product where we have projects that have java build paths that include a Classpath Container that directs out to an external jar. The classpath container code attaches javadoc to that jar, and we have a class like this: package some.package: public class SomeException extends Exception public abstract class SomeClass public final class InnerClass extends SomeException when our end-users are typing InnerClass ic = new InnerClass([CTRL-SPACE] they just see arg0, arg1 and no javadoc. Note that the CLASS javadoc for InnerClass appears as they hover over the type string "InnerClass". If they hover over the "new InnerClass" portion, they will see: some.package.SomeClass.InnerClass.InnerClass(SomeClass arg0, String arg1, String arg2) which might be where the trouble stems from; technically, yes, the first argument is the pointer to the containing class, but shouldn't the javadoc layer know to unwind that? (I can look at the html file on disk that the javadoc setting resolves to and I can see the constructor documentation in the html) I ventured an educated guess that this might be related to bug 151500 but was asked to file separately.
>I ventured an educated guess that this might be related to bug 151500 but was >asked to file separately. Sorry, it indeed looks likee a duplicate. Can you confirm that your problem is fixed when using 3.7 M1?
Created attachment 187115 [details] two projects as test case
I just attached a test case: two java projects in the zip file. Project "NoJavaDocForInnerClass": Look at PublicAbstractClass, then its inner class InnerFinalException I generated javadoc into its "doc" folder (left behind an ant file to re-gen it), then zipped it up as javadoc.zip. I exported that project as a jar and placed the jar right at the root, as NoJavaDocForInnerClass.jar. Basically, any use of InnerFinalException /from an external archive/ will not show javadoc for its constructor call. The "TestProject" demonstrates this. (its build path entry refers to the workspace, so you should have it good to go)
> Basically, any use of InnerFinalException /from an external archive/ will not > show javadoc for its constructor call. Is that also with 3.7 M1 or newer?
Sorry, I didn't say the most important thing: the test case was created in, and is exported from Eclipse 3.7 M4 (M FOUR) Eclipse for RCP and RAP Developers Version: Indigo Release Build id: 20101216-1529
(In reply to comment #5) > Sorry, I didn't say the most important thing: the test case was created in, and > is exported from Eclipse 3.7 M4 (M FOUR) > > Eclipse for RCP and RAP Developers > > Version: Indigo Release > Build id: 20101216-1529 OK thanks. So that means it's not a duplicate of bug 151500 (or its fix wasn't good enough).
Can reproduce using N20110117-2000.
Just a note re: the change of Version - we ship a commercial product, currently based on Eclipse 3.6.latest, and 3.7 doesn't line up with our next release either, so if feasible, I'd like to ask that this be considered for 3.6 SR2
I think I found the root cause of the problem. The anchor is not well computed in this case. The fix for bug 151500 was about getting the parameter names. In your case, you do get the parameter names, but they are not retrieved from the javadoc (as they should if javadoc would be available), but they are retrieved from the debug info. So the fix for 151500 was right I believe, it was simply not checking from what source the parameter names were retrieved. I am working on finalizing a fix for this. It is surprising that this was not found before. Sounds too late for me for 3.6.2 as this is not a regression over 3.5.2 or 3.4.2. Daniel, you have the last word.
Created attachment 187145 [details] Proposed fix + regression tests
Created attachment 187146 [details] Test cases Unzip these files inside /org.eclipse.jdt.core.tests.model/workspace/AttachedJavadocProject
Released for 3.7M5.
> Sounds too late for me for 3.6.2 as this is not a regression over 3.5.2 or > 3.4.2. > Daniel, you have the last word. I agree.
pity (not allowing it for 3.6 SR2) -- we're working around this by beefing up the class javadoc (the one they get a chance to see, if they are lucky/smart enough to hover over it before the method itself) to tell them that in all constructors string argument 1 is xyz and string argument 2 is something else
Verified for 3.7M5 using build I20110124-1800.
Note: I've taken steps to verify myself, and while the javadoc is fixed when hovering OVER an existing written-out invocation of the exception's constructor, when in content assist and choosing between more than one variant of the constructors, no javadoc informational panel shows! To reproduce, simply add a new constructor, say: /** * javadoc for InnerFinalException(String property, Throwable cause) * @param property the property argument * @param cause the chained exception */ public InnerFinalException(String property, Throwable cause) { } then, you will notice that any call like InnerFinalException e = new InnerFinalException([invoke-content-assist] will display both constructors, but fail to display javadoc during the content assist chooser. Would you prefer reopening this, or a new issue?
> Would you prefer reopening this, or a new issue? Please file a new bug.
