CodeLens-style reference count hint to the NetBeans Java editor.

[harshaindunil]

I have been working on a prototype for #8230, and before opening a PR I would like to get feedback on the overall direction and scope.

Summary

The feature adds a CodeLens-style reference count hint to the NetBeans Java editor.

For Java methods and named types, the editor shows an above-line hint such as:

• 1 reference
• 5 references

Clicking the hint opens a lightweight popup with grouped references, and from there the user can navigate to usages or open the full existing Find Usages results.

Scope of the current implementation

This is currently limited to the Swing Java editor only.

Implemented behavior:

• shows reference counts above Java methods and named types
• aligns the hint with the declaration start
• hides zero-reference entries
• excludes constructors in the current version
• uses the existing Java Find Usages infrastructure for correctness and navigation
• opens a popup on click, with an option to open the full Find Usages UI
• adds a setting under Tools > Options > Editor > Inline Hints > Show reference counts

Main implementation areas

The current implementation touches these areas:

• Java editor task to discover declarations and publish above-line hints
• editor rendering support for block-style hints above a line
• integration with Java Find Usages / Where Used
• popup UI for quick navigation
• settings/UI integration for enabling or disabling the feature

Performance work done

I initially observed noticeable editor slowdown, especially on larger files.

To address that, the current implementation now:

• computes counts in the background
• avoids running while scan/indexing is still in progress
• caches computed counts
• only computes counts for declarations visible in the current editor viewport
• avoids full cache invalidation on every index event
• handles split editors correctly
• keeps existing hints visible while recomputation is deferred

With these changes, the feature now appears stable in my testing and no longer shows obvious scrolling or split-editor issues.

Areas where I would like feedback

Before I submit a PR, I would especially like feedback on these points:

1. Feature scope

   • Is Java-editor-only a reasonable first step?
   • Is it acceptable that this is editor functionality only, not LSP / generic editor support?

2. UI direction

   • Is the above-line block hint approach acceptable for NetBeans?
   • Is the popup-on-click interaction preferred over directly opening Find Usages?

3. Reuse of Find Usages

   • The current implementation reuses the existing Java Where Used behavior for correctness.
   • Is this the right direction for v1, even if a future optimization could use a lighter counting backend?

4. Performance expectations

   • The current implementation is much better after viewport-based computation and cache improvements.
   • Is this sufficient for an initial contribution, or would reviewers expect a lighter-weight count mechanism before merge?

Current intent

If there are no major objections to the approach, I plan to open a PR for #8230 with:

• the editor hint support
• popup navigation
• settings integration
• tests and documentation/screenshots

I would appreciate feedback before I finalize the PR.

[mbien]

Feature scope

sounds good to me. First integration wouldn't have to cover all aspects (e.g LSP server) as long the implementation doesn't make future extension impossible which is probably not the case. Its good to keep scope small at first.

UI direction

This would be NetBeans first inline hint which is drawn between lines I believe. I know this is popular and don't have anything against it, but I believe it would be worth considering a usage mode which does not rely on inline text too. Lets say it would work analog to the ctrl+click of the goto-declaration feature, but backwards, opening the usage popup instead. This mode would also avoid some of the performance concerns since it is lazy/on-demand. But since you already started with inline hints, its probably too late to reduce the scope to simple popup action first - which would likely be a smaller change. Lets see how the code looks we can add that later too.

Is the popup-on-click interaction preferred over directly opening Find Usages?

popup is probably the most convenient solution here.

opens a popup on click, with an option to open the full Find Usages UI

right, you seem to have already accounted for that. User can still chose based on preference to get the full tree view -> excellent

Performance expectations

this is something we likely can't enable by default for now since performance wouldn't be predictable. (knowing how find usages works atm #8957).

But inline hints are already off by default and mapped to a hotkey, so it would already be covered I think.

feel free to open a draft PR - even if it isn't done yet.