Support Type Hierarchy

[CsCherrYY]

Relates to redhat-developer/vscode-java#1790, please see that PR for more details.

Signed-off-by: Shi Chen [email protected]

[testforstephen]

how about adding some unit tests?

[CsCherrYY]

how about adding some unit tests?

Sure. I'll add some then.

[rgrunber]

This doesn't seem to work for me. If I just try to call "Show Type Hierarchy" on java.io.File, I see 2 popups the first time : "MISSING provider", and "command 'java.action.resolveTypeHierarchy' not found". Afterwords I just see the latter. Looking at the code I see :

ExecuteCommandParams [
  command = "java.action.openTypeHierarchy"
  arguments = ArrayList (
    "{\"textDocument\":{\"uri\":\"file:///home/rgrunber/git/ebr/releng/maven-plugins/ebr-maven-plugin/src/main/java/org/eclipse/ebr/maven/CreateRecipeMojo.java\"},\"position\":{\"line\":135,\"character\":11}}",
    "2",
    "0"
  )
]

gets sent to executeCommand(..). However in TypeHierarchyCommand, both resolveChildren/resolveParents, will return null if the last parameter, "resolve", is 0.

[CsCherrYY]

@rgrunber
For the command not found error, I missed the java.execute.workspaceCommand in executing java.action.resolveTypeHierarchy. I'm not clear why it works in some specific environments like my PC but I fix it via redhat-developer/vscode-java@c7894ce. You can try it again.

For the last parameter of openTypeHierarchy, that's the mechanism to lazy load the focus type with large number of parents and children. We'll return a focusItem with null parents and children first. It will be regarded as unresolved but we can show it early with its own name, description, etc. When we try to expand it (once you open the type hierarchy view, the focusItem is going to be expanded automatically), java.action.resolveTypeHierarchy is called to resolve it and return the real parents or children.

[rgrunber]

Ok, so my initial impression is that this is really nice! redhat-developer/vscode-java@c7894ce fixed the issue. Is there any reason not to include this in the patch if it is in fact the more correct way to do the call ? Might this be a bug in VSCode itself maybe on different platforms ?

I'd still like to do a closer look on the JDT-LS side to see if there's anything to improve, but it looks pretty good.

A few comments/observations (not necessarily needing to be addressed) :

• I haven't gotten type hierarchy on java.lang.Object to complete on my machine but that's expected. I was partly expecting it to lazily load only immediate children like I see in other cases but likely even immediate children are a massive amount.
• I don't see any menu items for "Show SuperType Hierarchy" or "Show SubType Hierarchy" so I accessed them from the command palette. I expected them to run on the opened file but it seems they run on the focus type of the References View. That was a bit unexpected.
• If you run any of the Show Type/SubType/SuperType Hierarchy commands immediately from the palette (whether a class is opened or not) they'll pop up a small error message, so might need to guard against those
• Eventually it would be nice to extend this to method type hierarchy as well (though probably in a separate bug). For example, suppose you want to know all types inheriting from the given type that implement some given method, all by activating type hierarchy on that method declaration/reference.

[CsCherrYY]

@rgrunber
Thanks a lot for the review and suggestions!

Ok, so my initial impression is that this is really nice! redhat-developer/vscode-java@c7894ce fixed the issue. Is there any reason not to include this in the patch if it is in fact the more correct way to do the call ? Might this be a bug in VSCode itself maybe on different platforms ?

It's my mistake to miss the java.execute.workspaceCommand in executing commands. But in my PC it works (like my demo) so I didn't find this bug previously:cold_sweat:. I've just done some tests and find if I have some Java related extension installed, it works. For this PR, using java.execute.workspaceCommand is a correct way of delegate command and I'll keep my eyes on this bug.

• I haven't gotten type hierarchy on java.lang.Object to complete on my machine but that's expected. I was partly expecting it to lazily load only immediate children like I see in other cases but likely even immediate children are a massive amount.

I find this issue as well. In fact, we should get the children of the current item's children because we would like to show the collapse status of the current item's children, such as collapsed(if exists) or none(if none). So we should resolve two levels of types in the lazy load process. But currently VS Code gets dead after waiting for a long time, we should resolve it and I'll update the status in this PR.

• I don't see any menu items for "Show SuperType Hierarchy" or "Show SubType Hierarchy" so I accessed them from the command palette. I expected them to run on the opened file but it seems they run on the focus type of the References View. That was a bit unexpected.

From my personal perspective, I'd like to keep consistent with Call Hierarchy and show only one entry in the context of the editor, the user can change the view in the reference view. For a VS Code user, he'll change the call direction (incoming or outcoming) in the reference view. That's also the same behavior as Eclipse. Does it make sense?

• If you run any of the Show Type/SubType/SuperType Hierarchy commands immediately from the palette (whether a class is opened or not) they'll pop up a small error message, so might need to guard against those

It should be guarded for it makes no sense if there is no opened java file. And the behavior of calling from command palette should be optimized. Thanks!

• Eventually it would be nice to extend this to method type hierarchy as well (though probably in a separate bug). For example, suppose you want to know all types inheriting from the given type that implement some given method, all by activating type hierarchy on that method declaration/reference.

That's sounds very useful. If I understand correctly, the user can manually find override method by such as go to superimplementation or go to definition currently, but a little complex. Offering a method type hierarchy view can make it convenient for the users to find them in just one click. I think we can discuss on it later in another PR 😄.

[testforstephen]

When calling type hierarchy on java.lang.Object, i also observed the UI is freeze. I would suggest to whitelist it because all classes are children of Object. Show something like what IJ does.

[fbricon]

When calling type hierarchy on java.lang.Object, i also observed the UI is freeze. I would suggest to whitelist it because all classes are children of Object. Show something like what IJ does.

+100

[testforstephen]

Overall, it works well.

Here are some minor bugs:

• Duplicated results for the subtypes of "java.util.List".
  

• Run "Show Type Hierarchy" command from palette, throw errors if the active editor is on Settings view. Should hide the command.

[rgrunber]

Overall, this works pretty well and I think it's in a pretty good state. Once the remaining issues are resolved, I think we should merge. I plan to do a release by the end of the week so it probably makes sense to introduce this afterwards.

[testforstephen]

Overall, this works pretty well and I think it's in a pretty good state. Once the remaining issues are resolved, I think we should merge. I plan to do a release by the end of the week so it probably makes sense to introduce this afterwards.

Can we release Type Hierarchy in 1.0 milestone?
cc:// @rgrunber @fbricon

[testforstephen]

test this please

[CsCherrYY]

test this please

[testforstephen]

Have a play at the latest commit, it works well. I plan to merge it at the end of this week.