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 83539 - Smarter classpath scanning
Summary: Smarter classpath scanning
Status: RESOLVED WORKSFORME
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 6.x
Hardware: PC All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-27 20:03 UTC by _ gtzabari
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2006-08-27 20:03:43 UTC 
I notice Netbeans scans the classpath every time on startup for changes. I
assumes this means it has cached the parsing of the class files and it is simply
checking for changes.

Instead of rescanning the contents of rt.jar (and any other JAR file for that
matter) why doesn't Netbeans simply compare the file size, modification date or
even crc32 value and if they are unchanged since the last scan it will not
rescan the contents? Surely this is much faster than what we are currently doing?
Comment 1 Jan Becicka 2006-08-28 08:37:02 UTC 
We didn't rescan rt.jar. We just compare timestamp.
Comment 2 _ gtzabari 2006-08-28 13:47:27 UTC 
I stand corrected then. I guess it was due to the fact I was upgrading my
Mustang build so often.
Comment 3 Quality Engineering 2007-09-20 12:07:03 UTC 
Reorganization of java component