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.
Currently all classes from bootclasspath are scanned and maintained in Java MDR. These classes are then offered in code completion and at other places (fast Java import) thought they are only internal implementation. Users should not use them. With correctly reduced scope of bootclasspath analysis we can also get some performance benefit due to smaller database.
The question is how to identify the classes that can be igonred: - have a hard-coded hack for bootclasspath jars? - make it configurable somehow?
sun.* according to http://java.sun.com/products/jdk/faq/faq-sun-packages.html Of course there is a question whether it is OK for function like where used to ignore these classes.
hard coding may be good enough. Definitely don't introduce an option. Nobody would find it. I increase the priority to P2. This may improve the the initial creation of the repository significantly. I have the feeling that the old code completion already did some trick with this. Mila may know
Regarding parser DBs we in fact did not care about the contents of bootclasspath. Instead we have pre-constructed DBs for JDK - they've been built from contents of src.zip that does not contain sun.* sources. There were other pre-built DBs as well - for classes that were specific for certain modules functionality e.g. web module. There was a specialized ant task to build these PDBs as part of the NB build process.
Moved to new subcomponent java/javacore.
Lowering priority to P3 since this is a problem only for the first start. It is not certain whether it is worth of implementing. Performace team will measure a possible performance gain and together we will evaluate whether we should give this a priority.
There are 2971 entries in rt.jar starting with sun.* prefix (2116 if I eliminate inner classes). Total number of entries is 13198. It means 22.5% are classes that are not important for us. Other jars in jre/lib and jre/lib/ext will not change this ratio significantly as they are much smaller. They will only slightly improve it.
Fixed. Checking in src/org/netbeans/modules/javacore/scanning/FileScanner.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/scanning/FileScanner.java,v <-- FileScanner.java new revision: 1.4; previous revision: 1.3 done Packages to be ignored by scanning are read from org.netbeans.javacore.ignoredPackages system property. The default value is "sun sunw".
The time for the initial scanning decreased roughly by ~15-20%: jdk 1.4.2_04 - 1:26 versus 1:44 jdk 1.5.0-b58- 1:58 versus 2:15 The memory consumption, as shown by the memory meter after the initial scan, is not different (but as indicated by Petr Nejedly in issue 43258, part of the strings were shifted to perm. generation, which is not covered by memory meter).
Marking as verified.
Reorganization of java component