Type hierarchy not displayed

[amitjoy]

I have recently encountered the problem that the type hierarchy cannot be listed anymore.

Steps to reproduce:

1. Use the latest snapshot version of bndtools
2. Open any API residing in a project other than the implementation project
3. Click on the name of the API
4. Press CMD+T to display the type hierarchy
5. The type hierarchy is not displayed at all

I believe the problem lies in the access rules since they differ in 6.2-REL (where it works perfectly) and latest snapshot:

Latest Snapshot:

REL-6.2:

Step

[bjhargrave]

As part of changes to support transforming in a Bnd Workspace build, I made a change to the Bndtools classpath container so that for version=latest/snapshot -buildpath references, the IClasspathEntries had the project reference for the source files was changed to be not accessible. This forces the compiler to use the binary class file in the built jar since that class file could be significantly transformed from what the source code says.

This change works fine for compiler and Open Type. However, there is a flaw in the way that Eclipse JDT finds types in the hierarchy which breaks with this change. First JDT searches for the supertypes and subtypes of the subject type. During this phase, JDT finds the source type and since it is not accessible (due to the IClasspathEntry configuration), JDT keeps looking and finds the binary type in the built jar. Then later JDT wants to get the IType objects for each super type and calls HierarchyResolver.findSuperInterfaces passing the binary type. This then calls HiearchyBuilder.getHandle to obtain the IType for the binary type. This calls HiearchyBuilder.lookupBinaryHandle which calls NameLookup.findType but this time it does not request checking accessibility. So this lookup returns the first source type (which is marked inaccessible). So then when HiearchyBuilder.lookupBinaryHandle receives a non-binary answer for the lookup, it just ignores it.

HiearchyBuilder.lookupBinaryHandle also has another flaw where it tries to short cut the lookup by seeing if the lookup name matches the focus type but the focus type can be a source type. So the receiver expects the return value to be a binary type and a class cast exception occurs.

I can try and make a fix for JDT but that does not help things in the near term since we support older versions of Eclipse.

So I think the answer here will be to revert to the prior behavior as the default behavior and define a way for individual -buildpath entries (which are known to need the alternate behavior) to request the alternate behavior.

• Default behavior = source folder is accessible
• Alternate behavior = source folder is not accessible to support transforming (at the cost of reduced results in the Open Type Hierarchy).

[kriegfrj]

Great work on this one, @bjhargrave ! I haven't looked in detail, but the bug in finding supertypes in certain circumstances reminded me of this bug that I found while working on the quick fix processor: https://bugs.eclipse.org/bugs/show_bug.cgi?id=566145 I wonder if the two are connected in some way.

[pkriens]

Impressive work ... I know how complex that code is.

[amitjoy]

Thanks a lot @bjhargrave for looking into the issue so carefully. I really appreciate your in-depth hard work. 🙇 Great job 👍

[bjhargrave]

I wonder if the two are connected in some way.

The case here requires an inaccessible source type before the accessible binary type. Not sure if that applies to your test case problem since I would doubt it involves this kind of shadowing.

[chrisrueger]

@bjhargrave thanks for the fix. I can confirm Type Hierarchy is working again with 6.3.0-RC3

One thing I noticed is that there are duplicates.

You see 4 leaf entries, which are actually only 2.

I think this has been the case also in the past too - not sure.... But just wanted to mention it, in case it is important for this specific issue.

[bjhargrave]

This is a long term issue and not part of this change. There is code which attempts to remove the duplicates which come from the jar classpath elements, but it does not always work. Sometimes it does and sometimes not :-(

[chrisrueger]

Ok thanks for the clarification.