lahodaj commented on code in PR #9173:
URL: https://github.com/apache/netbeans/pull/9173#discussion_r2747336873


##########
java/java.completion/src/org/netbeans/modules/java/completion/JavaCompletionTask.java:
##########
@@ -5996,7 +5996,7 @@ private Set<? extends TypeMirror> getSmartTypesImpl(Env 
env) throws IOException
                         path = new TreePath(path, mid);
                         TypeMirror typeMirror = 
controller.getTrees().getTypeMirror(path);
                         final ExecutableType midTM = typeMirror != null && 
typeMirror.getKind() == TypeKind.EXECUTABLE ? (ExecutableType) typeMirror : 
null;
-                        final ExecutableElement midEl = midTM == null ? null : 
(ExecutableElement) controller.getTrees().getElement(path);
+                        final ExecutableElement midEl = midTM != null && 
controller.getTrees().getElement(path) instanceof ExecutableElement ee ? ee : 
null;

Review Comment:
   I don't think we have a utility to fuse kind check and cast (although we 
could have - esp. for trees, as there's Kind.asInterface). Given we don't 
really support arbitrary Java Language Model (javax.lang.model), but only the 
one produced by javac, I think using instanceof for ExecutableElement is OKish.
   
   FTR, the lines above show the kind check:
   ```
   TypeMirror typeMirror = controller.getTrees().getTypeMirror(path);
   final ExecutableType midTM = typeMirror != null && typeMirror.getKind() == 
TypeKind.EXECUTABLE ? (ExecutableType) typeMirror : null;
   ```
   as Michael says, it is not easy to this without the auxiliary variable, esp. 
not without duplicating the `getTypeMirror` call. But, with source level >= 21, 
we could do:
   ```
   final ExecutableElement midEl = midTM != null && 
controller.getTrees().getElement(path) instanceof Element ee && ee.getKind() == 
ElementKind.METHOD ? (ExecutableElement) ee : null;
   ```
   
   As for the inconsistency, the attribution of erroneous code sometimes 
produces "funny" results - in particular, javac has no real `ExecutableElement` 
instance for really erroneous methods, its all either `ClassSymbol` or 
specialized subclases of `Symbol`, but not `MethodSymbol`/`ExecutableElement`, 
I think. I think I had some brief periods where I looked at possibilities to 
change this, but there I never found a viable solution.
   



-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

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

Reply via email to