This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 258985 - RepositoryForBinaryQueryImpl.getJarMetaDataCoordinates() should cache its results
Summary: RepositoryForBinaryQueryImpl.getJarMetaDataCoordinates() should cache its res...
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 8.1
Hardware: PC Windows 7
: P3 normal with 1 vote (vote)
Assignee: Tomas Stupka
: 251973 (view as bug list)
Depends on:
Reported: 2016-04-23 14:35 UTC by markiewb
Modified: 2016-07-10 20:53 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Shows the snapshot and the code (96.24 KB, image/png)
2016-04-23 14:35 UTC, markiewb

Note You need to log in before you can comment on or make changes to this bug.
Description markiewb 2016-04-23 14:35:02 UTC
Created attachment 159407 [details]
Shows the snapshot and the code

I wondered why opening the "rename field"-refactoring-dialog takes so long. More than 2s to open. Our application uses many dependencies. Maven transitive dependencies, starting from hibernate and spring.

So I took a snapshot and saw that NetBeans scans all the jars of the dependencies of our application to get the GAV-information from the META-INF/.../ files. 

See the screenshot.

EXPECTED: Cache the GAV-information. Especially released versions in the maven repo change seldom/never. The caching key might be the file path combined with the file change date. Or the file path plus checksum.

Perhaps analog to ?
Comment 1 Tomas Stupka 2016-05-18 11:59:23 UTC
fixed in jet-main #cd5049fedcf9
Comment 2 Quality Engineering 2016-05-19 01:43:53 UTC
Integrated into 'main-silver', will be available in build *201605190002* on (upload may still be in progress)

User: Tomas Stupka <>
Log: Issue #258985 - RepositoryForBinaryQueryImpl.getJarMetaDataCoordinates() should cache its results
Comment 3 markiewb 2016-07-10 20:53:06 UTC
*** Bug 251973 has been marked as a duplicate of this bug. ***