FindUsagesDependencies

(Difference between revisions)
m (Find Usages dialog)
Line 9: Line 9:
===Description===
===Description===
-
There will be a new scope added to the Find Usages dialog:
+
Java's Find Usages support will be enhanced with searching in a project's dependencies. When the user invokes Find Usages on an element and selects the newly added scope in the dialog:
  Open Projects & Dependencies
  Open Projects & Dependencies
 +
 +
the index will be queried for all resources that reference the element. Usages from these resources, binary or source, will be shown in the results window. In this window the user can filter the results with the already available filters and the newly added filters binary and platform.
===Open Problems===
===Open Problems===

Revision as of 19:30, 9 April 2015

Contents


Motivation

Find Usages in Project Dependencies and JDK is a highly requested feature, especially from users working with J2EE projects or using maven.

The user expectation is that you will find all usages - there is no indication that non-project classes will be excluded, and it is quite a surprise when you are unable to use this basic feature to understand the way the JDK and libraries work. (At least the Go to Class dialog offers you the choice - F.U. does not.) There has been repeated feedback from users on this point.

Description

Java's Find Usages support will be enhanced with searching in a project's dependencies. When the user invokes Find Usages on an element and selects the newly added scope in the dialog:

Open Projects & Dependencies

the index will be queried for all resources that reference the element. Usages from these resources, binary or source, will be shown in the results window. In this window the user can filter the results with the already available filters and the newly added filters binary and platform.

Open Problems

The byte code does not contain following source patterns:

  1. Source level annotations
  2. unused imports
  3. constants are inlined
  4. whole blocks if (false) or if (FALSE_CONSTANT) are removed.

Possible solution: identifier index created from attached sources (no attribution) created when user first time does find usages on the jar with attached sources.

Benefits: Fixes missing source patterns

Problems: Lots of work on the level of index and refactoring.

If we decide to implement it with binary full index we should notify user about missing features. When the user invokes find usages on a constant or source level annotation, the new scope should not be available and this should be documented in the accompanied help files.

Unfortunately for optimised code (removed if) and unused imports we have no such a solution it will just not work.

UI

Find Usages dialog

Scopes for Type

image:FindUsagesScopesDependencies.png

Find Usages results

Results from dependency

image:FindUsagesDependencyBinary.png

Results from JDK

image:FindUsagesJDKsrc.png image:FindUsagesJDKbinary.png

Filters for Dependencies and Binary results

image:FindUsagesFilters.png

Effort estimation

2 engineers/2 weeks

Dependencies

Impacts

Architecture

API

ClassIndex to get Binary Resources from the index

Documentation

Testing

Performance

  1. Indexing binary attached sources by JavaCustomIndexer is no option due to performance impact.
  2. Using binary full index.

Benefits: Already implemented in BinaryAnalyzer, needs to be just enabled.


The performance impact of enabling full binary index on JDK 7 rt.jar:


partial index full index
Index size: 6,546KB 7,605KB (~+1MB)
creation time 2787ms 5517ms (~100% regression)
impact on query time 44ms 48ms (~10% regression)

Risks

Additional information

Sources

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo