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.
This issue was reported manually by jrmacias. It already has 1 duplicates Build: NetBeans IDE 6.9.1 (Build 201007282301) VM: Java HotSpot(TM) Client VM, 16.3-b01, Java(TM) SE Runtime Environment, 1.6.0_20-b02 OS: Linux Stacktrace: java.lang.NoClassDefFoundError: org/netbeans/modules/apisupport/project/layers/BadgingSupport$2 at org.netbeans.modules.apisupport.project.layers.BadgingSupport.getInstanceLabel(BadgingSupport.java:266) at org.netbeans.modules.apisupport.project.layers.BadgingSupport.annotateNameGeneral(BadgingSupport.java:228) at org.netbeans.modules.apisupport.project.layers.BadgingSupport.annotateNameGeneral(BadgingSupport.java:243) at org.netbeans.modules.apisupport.project.layers.BadgingSupport.access$300(BadgingSupport.java:95) at org.netbeans.modules.apisupport.project.layers.BadgingSupport$1.run(BadgingSupport.java:152) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
Created attachment 102820 [details] stacktrace
Probably close as worksforme, but it is surprising the file handle limit was reached so quickly. Just after start and one scanning. Interesting thing to note : the distribution is multilingual - e.g. there is three times more files than is usual. INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 7 source roots took: 3466 ms (New or modified files: 6, Deleted files: 0) [Adding listeners took: 10 ms] INFO [org.openide.filesystems.JarFileSystem]: error in opening zip file java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:135) at java.util.jar.JarFile.<init>(JarFile.java:99) at org.openide.filesystems.JarFileSystem.getJar(JarFileSystem.java:952) at org.openide.filesystems.JarFileSystem.reOpenJarFile(JarFileSystem.java:732) at org.openide.filesystems.JarFileSystem.getEntry(JarFileSystem.java:927) at org.openide.filesystems.JarFileSystem.lastModified(JarFileSystem.java:477) at org.openide.filesystems.JarFileSystem$Impl.lastModified(JarFileSystem.java:1069) at org.openide.filesystems.AbstractFileObject.initLastModified(AbstractFileObject.java:98) at org.openide.filesystems.AbstractFileObject.lastModified(AbstractFileObject.java:179) at org.openide.filesystems.AbstractFileObject.<init>(AbstractFileObject.java:83) at org.openide.filesystems.AbstractFileSystem.createFileObject(AbstractFileSystem.java:450) at org.openide.filesystems.AbstractFileObject.createFile(AbstractFileObject.java:140) at org.openide.filesystems.AbstractFolder.getChild(AbstractFolder.java:366) at org.openide.filesystems.AbstractFolder.getChild(AbstractFolder.java:337) at org.openide.filesystems.AbstractFolder.getFileObject(AbstractFolder.java:473) at org.netbeans.api.java.classpath.ClassPath.findPath(ClassPath.java:940) at org.netbeans.api.java.classpath.ClassPath.findResourceImpl(ClassPath.java:954) at org.netbeans.api.java.classpath.ClassPath.findResource(ClassPath.java:409) at org.netbeans.modules.apisupport.project.layers.LayerUtils.currentify(LayerUtils.java:167)
In reply to comment #2 The parsing.api + java.source uses only limited number of file handles, the indexes are closed by LRU. In the 7.0 the number of used handles should be decreased as the most hot indexes are soft referenced in mem (no file handle0.
Probably nothing to be done except raise your file descriptor limit to a more reasonable value. It is possible the fix of bug #181231 would also have helped.