Community
Participate
Working Groups
Build Identifier: 3.5.2 M20100211-1343 The fix for defect Bug 293955 - "valid javadoc url set on user library, but still says no javadoc" - improves the flexibility of the search for details from a javadoc library by making the search insensitive to case. Further work should be done to support accessible javadoc libraries. Accessible javadoc libraries can be generated (or transformed from currently generated files) as XHTML and might not include the anchor that the Java editor is currently looking for: <A NAME="methodName(type1,type2...)"><!-- --></A> A more flexible and robust means of finding the details to be displayed for content assistance would be to use an HTML or XHTML parser (according to the DOCTYPE of the javadoc files. Reproducible: Always Steps to Reproduce: 1. Add the location of an accessible javadoc library to your project property "Javadoc Location" path. 2. Make sure that the jar that implements the APIs described in the javadocs is included in the project classpath. 3. Open a Java class in this project, import one of the classes, declare a new instance, and begin to write code to call one of its methods. 4. Ctrl+Spacebar should provide completions and for any selected completion the details from the javadocs.
Ayush, Please follow up -- Thanks.
Created attachment 170398 [details] Example of an improved format for javadoc This javadoc library is generated from the JDK 1.7.0 source files for these packages: java.lang java.lang.annotation
Javadoc hover for content assist is part of JDT/UI. So moving.
(In reply to comment #3) > Javadoc hover for content assist is part of JDT/UI. So moving. Not really, see org.eclipse.jdt.core.IJavaElement.getAttachedJavadoc(IProgressMonitor).
(In reply to comment #4) > (In reply to comment #3) > > Javadoc hover for content assist is part of JDT/UI. So moving. > Not really, see > org.eclipse.jdt.core.IJavaElement.getAttachedJavadoc(IProgressMonitor). Hmm, my bad. JavadocContents has to be capable of handling XHTML.
Thomas, one question - is the format of the XHTML javadoc always the same vis-a-vis the anchors <A NAME.. ? I was trying to transform an HTML javadoc file to an XHTML one using some online converters and I saw that they preserved the <A NAME anchors as such. While in your attached javadoc there are "id" nodes in place of the anchors. If this is the case (i.e. a javadoc with DOCTYPE XHTML may/may not have <A NAME.. ), depending only on the DOCTYPE to process the javadoc won't be correct.
You can examine the attachment to see what the IBM Javadoc is generating. IBM has special license to modify the code in the com.sun packages, provided that we distribute the changes only internally. Without realizing it would be a problem for Eclipse, we made many changes to generate accessible (WCAG 2.0-compliant) Web pages, so we changed more of the output than would be necessary for simply converting to XHTML.
Created attachment 179823 [details] preliminary patch This patch is a basic implementation of the javadoc parsing when it is in XHTML format, as seen in the sample doc attached in this bug. I've tested it manually using the attached doc and it does work fine i.e. returns the correct doc for a java element. In the absence of a template, this is the best I could do. To make the doc visible in the hovers for content assist and other places, some work will have to be done on the UI side to process the new form of the javadoc we now get. Olivier suggested it'll be a good idea to expose an extension point where someone could contribute their own implementations to process different forms of javadoc.
> To > make the doc visible in the hovers for content assist and other places, some > work will have to be done on the UI side to process the new form of the >javadoc Why? What changed? The IJavaElement.getAttachedJavadoc(IProgressMonitor) API specifies that it returns HTLM. I would expect that JDT Core can handle the additional formats but still returns valid HTML to the client.
(In reply to comment #9) > > To > > make the doc visible in the hovers for content assist and other places, some > > work will have to be done on the UI side to process the new form of the >javadoc > Why? What changed? The IJavaElement.getAttachedJavadoc(IProgressMonitor) API > specifies that it returns HTLM. I would expect that JDT Core can handle the > additional formats but still returns valid HTML to the client. Yup. It still returns valid HTML. But the XHTML format has some extra tags, viz. <ul>, <ol>, hyperlink which were not part of the usual HTML javadoc for a type, field, and method. If these won't cause any problems, then we're good.
> Yup. It still returns valid HTML. But the XHTML format has some extra tags, > viz. <ul>, <ol>, hyperlink which were not part of the usual HTML javadoc for a > type, field, and method. If these won't cause any problems, then we're good. OK. You wrote: "make the doc visible in the hovers for content assist and other places, some work will have to be done on the UI " which made me think that you actually tested it and missed some stuff in the hovers ;-). Note that we could even display XHTML since we show the Javadoc inside a browser control. Only if that control is not available we fallback to some limited display.
Created attachment 179956 [details] proposed patch 2 Moving the javadoc constants for XHTML into a new file, and a few small changes in the constants as observed for XHTML format. Will explore the option of exposing an extension point in jdt core and providing the above patch as an extension.
