I tried an found same problem.

Why this is marked as an API_REVIEW?

File Hierarchy and File Members now work also for class files.
Fixed jet-main 805e2dbf1d5a

(In reply to comment #3)
> File Hierarchy and File Members now work also for class files.
> Fixed jet-main 805e2dbf1d5a

Please Make sure it is tested in Maven as well

If maven correctly fullfils the java model contract it will work. Seems to work fine with basic maven project (tested on junit) I have no time to set up more complicated maven project.

Integrated into 'main-golden', will be available in build *201011300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/805e2dbf1d5a
User: Tomas Zezula <tzezula@netbeans.org>
Log: #192306:Class hierarchy Alt + F12

Hi I have tested with NetBeans IDE Build 201012070001, The issue still persist.

Works for me, see the attached screenshot.
If you have some test case please attach it to this issue and reopen.
Thanks

Created attachment 103791 [details]
Screenshot

Created attachment 104031 [details]
Screen shot of NB build version

I have tested with latest build but no luck for third party libraries.

Screen short attached. http://netbeans.org/bugzilla/attachment.cgi?id=104031

Works fine for me as shown on my screenshot.
Your screenshot also shows that it works fine on sources.
If you have an reproduceable test case attach it.
You can try it by opening Libraries/JDK/rt.jar/java.lang, selecting Integer.class and calling Navigate/Inspect/File Hierarchy.

Created attachment 104048 [details]
Windows test

I've also did the test on Windows (XP) and works fine even on it, see http://bugzilla-attachments-192306.netbeans.org/bugzilla/attachment.cgi?id=104048
I did the test with java.lang.Integer as described above.

Created attachment 104131 [details]
Test Case Document

Hi please find the attached test case document. I have cross checked with Leon - leonhad@netbeans.org, He have the same issue for struts third party libraries. 

Thanks
vidhya

Test case attached. please review.

Thanks,
vidhya

Changing the summary.
The File Hierarchy action does not show subtypes coming from libraries.

There are two cases:

1st) The file comes from library as well. In this case the File Hierarchy action cannot even set up the find usages context other than the jar only in reasonable time. Other solution will take a list of all open projects check for the presence of the jar on each source root and add it to search, but this will be very slow for bigger amount of projects.

2nd) The file comes from project sources and has implementation in library. This is probably useless as it's wrong backward reference. The project library depends on project source but the dependence is vice versa. Such a library belongs to runtime classpath.


The 1st case (with the subtypes in the same jar) can be fixed, the generic case (with the project lookup) is problematic due to performance reason.

The current implementation of the File Hierarchy is not very effective and does nearly the same as I've described as the performance problem (in fact it does the same but a bit slower). It really deserves to be rewritten. But adding the support for class from libraries does not add any new performance overhead. It will have the same speed as if it the classes were from sources. So I will integrate it.

Fixed jet-main a34246da45b0

I've improved a bit the performance of HierarchyView, jet-main 2b5506d67c11

Integrated into 'main-golden', will be available in build *201012180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a34246da45b0
User: Tomas Zezula <tzezula@netbeans.org>
Log: #192306:Class Hierarchy does not show subtypes from libraries.