You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@netbeans.apache.org by GitBox <gi...@apache.org> on 2019/11/09 20:24:50 UTC

[GitHub] [netbeans] zimmi edited a comment on issue #1548: [NETBEANS-1396] Missing code completion and Javadocs in maven projects with classifier

zimmi edited a comment on issue #1548: [NETBEANS-1396] Missing code completion and Javadocs in maven projects with classifier
URL: https://github.com/apache/netbeans/pull/1548#issuecomment-552133026
 
 
   After some digging, here are my findings. The algorithm to find the javadoc goes as follows:
   
   1. If there is source for the code element attached, try to use that first (this happens in [ElementJavadoc::getElementDoc](https://github.com/apache/netbeans/blob/master/java/java.sourceui/src/org/netbeans/api/java/source/ui/ElementJavadoc.java#L742)).
   
   2. If there is no source attached or finding the requested code element in the source fails, try to use the javadoc.
   
   3. If there is no source or javadoc and the code element is a method, recurse upward the type hierarchy.
   
   4. If everything failed, display the "Attach Javadoc..." popup.
   
   I think the order is sensible, changing it would probably be too disruptive.
   
   I traced the execution after requesting javadoc for `stage.setScene(scene)` to [ElementHandle::resolveImpl](https://github.com/apache/netbeans/blob/master/java/java.source.base/src/org/netbeans/api/java/source/ElementHandle.java#L177), where the method signature the user clicked on  (`{ "javafx.stage.Stage", "setScene", "(Ljavafx/scene/Scene;)V" }`) does not match the signature parsed from Stage.java (`{ "javafx.stage.Stage", "setScene", "(LScene;)V" }`). The reason the parameter from the JavaFX source is not fully qualified is because javac reports it as `TypeKind.ERROR`, see [ClassFileUtil](https://github.com/apache/netbeans/blob/master/java/java.source.base/src/org/netbeans/modules/java/source/usages/ClassFileUtil.java#L277).
   In fact, javac reports **every** reference type from Stage.java as `TypeKind.ERROR`, even types like `String` that are not part of the JavaFX source. I haven't checked yet, but I assume this is also the reason why source navigation fails (notice that only jumping to methods that take reference types fails, others work fine).
   
   About `stage.show()`: No reference type parameters, so it should work fine. It uses `{@inheritDoc}` though, and javac fails to resolve the superclass `Window` inside [ElementJavadoc::getInherited](https://github.com/apache/netbeans/blob/master/java/java.sourceui/src/org/netbeans/api/java/source/ui/ElementJavadoc.java#L1078) (`type.getSuperclass().getKind()` returns `TypeKind.ERROR`). There is no other content in the javadoc of the method, so only the method signature is displayed.
   
   That's where I stopped, the next step would probably be to see what's so special about Stage.java that javac can't parse its type references.
   
   @matthiasblaesing
   The javac errors are not caused by this PR: Renaming the source artifact in .m2 to `javafx-graphics-13-linux-sources.jar` (so NetBeans finds it) leads to the same failures in stock NetBeans 11.2: source navigation jumps to the top of the file and javadoc is only displayed for methods without reference type parameters. With this PR there is at least a fallback to javadoc jars when javac can't resolve type references.
   
   I did not check why the Ant project works, but fixing the javac errors has to be done anyway.
   
   While looking through the source I also found two other places that deal with javadoc that need to be adapted to javadoc 9+ output (namely [HTMLJavadocParser::parseClass](https://github.com/apache/netbeans/blob/master/java/java.sourceui/src/org/netbeans/api/java/source/ui/HTMLJavadocParser.java#L281) and [JavadocHelper.TextStream](https://github.com/apache/netbeans/blob/master/java/java.source.base/src/org/netbeans/modules/java/source/JavadocHelper.java#L274)). I'd like to consolidate the logic a bit, I think I have a way that doesn't break any public API. But leaving those places in for now shouldn't have a huge negative impact. I'm for merging this PR and I'll do a follow up PR when time permits.
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists