callHierarchy/outgoingCalls errors "Compilation unit name must end with .java"

[nalbion]

I send textDocument/prepareCallHierarchy and get a response:

[{
  "detail":"Main",
  "kind":6,
  "name":"bar() : void",
  "range":{"end":{"character":5,"line":21},
  "start":{"character":4,"line":18}},
  "selectionRange":{
    "end":{"character":27,"line":18},
    "start":{"character":24,"line":18}
  },
  "uri":"file:/jdtls-demo/java/src/main/java/Main.java"
}]

I send the item to callHierarchy/outgoingCalls

code: -32603, 
message: Internal error.
data:
java.util.concurrent.CompletionException: java.lang.IllegalArgumentException: 
Compilation unit name must end with .java, or one of the registered Java-like extensions 

at org.eclipse.jdt.internal.core.PackageFragment.getCompilationUnit(PackageFragment.java:294)
at org.eclipse.jdt.internal.core.util.Util.getCompilationUnit(Util.java:811)
at org.eclipse.jdt.internal.core.util.Util.getUnresolvedJavaElement(Util.java:1562)
at org.eclipse.jdt.core.dom.TypeBinding.getUnresolvedJavaElement(TypeBinding.java:581)

at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:258)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:3343)
at org.eclipse.jdt.internal.corext.callhierarchy.CalleeMethodWrapper.findChildren(CalleeMethodWrapper.java:101)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:265)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:196)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:87)

[nalbion]

Main.java:

import package_a.Foo;

public class Main {
    public static void main(String[] args) {
        package_c.Foo myFoo = new package_c.Foo();
	    Foo fooA = new Foo();
        package_b.Foo fooB = new package_b.Foo();
        myFoo.foo("bar");
        fooA.foo("bar");
        fooB.foo("bar");
        foo();
    }

    private static void foo() {
        System.out.println("main foo");
        bar();
    }

    private static void bar() {
        System.out.println("main bar");
        baz();
    }

    private static void baz() {
        System.out.println("main baz");
        boo();
    }

    public static void boo() {
        System.out.println("boo");
    }
}

[nalbion]

I'm not sure what I've done, but at other times I get another error:

{
  "item":{
    "name":"baz() : void",
    "kind":6,
    "detail":"Main",
    "uri":"file:///jdtls-demo/java/src/main/java/Main.java",
    "range":{
      "start":{"line":25,"character":4},
      "end":{"line":28,"character":5}
    },
    "selectionRange":{
      "start":{"line":25,"character":17},
      "end":{"line":25,"character":20}
    }
  }
}

java.lang.NullPointerException: Cannot invoke "org.eclipse.lsp4j.Location.getRange()" because "fullLocation" is null
at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.toCallHierarchyItem(CallHierarchyHandler.java:309)
at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.getOutgoingCallItemsAt(CallHierarchyHandler.java:270)
at org.eclipse.jdt.ls.core.internal.handlers.CallHierarchyHandler.callHierarchyOutgoingCalls(CallHierarchyHandler.java:133)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$54(JDTLanguageServer.java:1171)

[rgrunber]

I'm able to reproduce the NPE regarding fullLocation, but not the original one regarding the compilation unit name, though they may be closely related.

Basically, if the client doesn't set "classFileContentsSupport": true in the extendedClientCapabilities of the initialize request, this happens. The CallHierarchyHandler may return some .class files at https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/3dc4c5d2bc66748fac5cb201587f024707454d69/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CallHierarchyHandler.java#L270 and we need to check if that's the case and maybe exclude them if the client hasn't declared support for classfile content. Either that or see if we can support some kind of dummy URI since lack of classfile support means we can't resolve it.

[nalbion]

jdtls seems to work a lot better when a pom.xml is added to the test project