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.
Using an excludes_49026 build, I am trying to load a project defined with <compilation-unit> <package-root>${root}/j2se/src/share/classes</package-root> <package-root>${root}/j2se/src/windows/classes</package-root> <package-root>${root}/j2se/src/solaris/classes</package-root> <classpath mode="compile">${root}/j2se/build/${arch}/classes</classpath> <classpath mode="boot"/> <built-to>${root}/j2se/build/${arch}/classes</built-to> <source-level>1.5</source-level> </compilation-unit> I am getting some odd warnings: SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/java/util/LinkedList.sig, source file file:/space/src/jdk7/j2se/src/share/classes/java/util/LinkedList.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/java/util/TreeMap.sig, source file file:/space/src/jdk7/j2se/src/share/classes/java/util/TreeMap.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/java/util/concurrent/FutureTask.sig, source file file:/space/src/jdk7/j2se/src/share/classes/java/util/concurrent/FutureTask.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/com/sun/tools/javac/jvm/Gen.sig, source file file:/space/src/jdk7/j2se/src/share/classes/com/sun/tools/javac/jvm/Gen.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.sig, source file file:/space/src/jdk7/j2se/src/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.sig, source file file:/space/src/jdk7/j2se/src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s18/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.sig, source file file:/space/src/jdk7/j2se/src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s17/classes/java/lang/ProcessEnvironment.sig, source file file:/space/src/jdk7/j2se/src/windows/classes/java/lang/ProcessEnvironment.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s17/classes/java/io/FileDescriptor.sig, source file file:/space/src/jdk7/j2se/src/windows/classes/java/io/FileDescriptor.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s17/classes/sun/nio/ch/PollArrayWrapper.sig, source file file:/space/src/jdk7/j2se/src/windows/classes/sun/nio/ch/PollArrayWrapper.java SEVERE [global]: Coupling error: class file file:/space/src/excludes_49026/nbbuild/testuserdir/var/cache/index/0.1/s17/classes/sun/awt/windows/ThemeReader.sig, source file file:/space/src/jdk7/j2se/src/windows/classes/sun/awt/windows/ThemeReader.java I will attach one dump file.
Created attachment 38698 [details] Sample dump file
(Sorry for late answer.) Some of the coupling errors (eg. LinkedList, TreeMap and FutureTask) probably represent issue #90473 and issue #90766. Hard to verify without the dump files. If you still have the dump files, would it be possible to pack them and send them to me? Thanks. The attached coupling error is actually caused by the configuration - it complains that the sig file created for FileDescriptor load from ${root}/j2se/src/solaris/classes does not match the source file load from ${root}/j2se/src/windows/classes (ie. there is the same FQN twice on the classpath, with different contents). The warning itself should be harmless (it says that it detected difference between the sig file content and the actual source file and attempted to correct it), but the effect of this setup on various features (code completion, refactoring, hints, error underlines, etc.) is mostly unpredictable. So I would suggest to fix the project configuration not to have the same FQN twice on the classpath.
Created attachment 39598 [details] Dump file from LinkedList
Attaching one such dump file, but AFAIK it is easy to reproduce the problem for yourself. For FileDescriptor - yes, there are a few such classes in the JDK. I will see if it is possible to get these cleaned up, but it may not be.
"For FileDescriptor - yes, there are a few such classes in the JDK. I will see if it is possible to get these cleaned up, but it may not be.": Sorry, but I do not understand what this means. How do you expect the IDE to work with two different classes with the same FQN? Currently, most features (error underlining, hints, etc.) will probably only see the first class of given FQN on the given classpath. Some features (like refactoring) may see either one or even both at one time. I do not think there is anything we could do about this.
I don't really care if the IDE complains about cases like FileDescriptor. It is up to the JDK team to fix these overlaps if they can. (As a rule they seem to be resistant to any suggestions to clean up source structure to be friendlier to tools, but I can at least try.) But 1. For overlapping classes, the IDE's error log should at least warn that you have overlapping classes and that operations involving these classes may be impaired. "Coupling error" is not a very helpful diagnostic. 2. Many other classes (LinkedList, FutureTask, etc.) also print this warning. They are not duplicated.
1. I agree, though it is not very trivial to do, so I did not manage to actually create such code. Please note that there is no general guarantee that such error will be reported (depends on order in which the files are processed). 2. Yes. All such failures I have seen are either issue #90473 or issue #90766. "I don't really care if the IDE complains about cases like FileDescriptor. It is up to the JDK team to fix these overlaps if they can." OK, but I am afraid *I* have to care, as the users are going to file issues against me (which I cannot solve, because the problem is project misconfiguration, IMO).
The malicious coupling aborts are mostly fixed now. The warning should bad configuration should be better, but this does nto qualify as P3, IMO.
Is this related to issue #102857?
Using NB 6.1beta with Maven projects coupling errors occurs (subsequently causing errors in the taslist/editor). First I openened my library project (consisting of several submodules). The occuring coupling errors disappear when openening some dependency files - which are all included in classpath, anyway. But loading an application project (dependent on the library), which all have this package design by convention: tld/domain/foo/Foo.java tld/domain/foo/FooFrame.java tld/domain/foo/FooProject.java causes coupling errors like the following: SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/${user.home}/.netbeans/6.1beta/var/cache/index/0.8/s23/classes/tld/domain/foo/FooFrame.sig, source file file:/java/project/tld/foo/src/main/java/tld/domain/foo/FooFrame.java SEVERE [org.netbeans.modules.java.source.usages.RepositoryUpdater]: Coupling error: class file file:/${user.home}/.netbeans/6.1beta/var/cache/index/0.8/s23/classes/tld/domain/foo/FooProject.sig, source file file:/java/project/tld/foo/src/main/java/tld/domain/foo/FooProject.java
Seeing the same thing in salesforce.com sources, a lot. Some of them are cases where we're patching library jars (are there such errors when dealing with code in a NB module's /patches/ dir?) Some of them are classes with a unique FQN, though. I'll attach a dump file for one such example.
Created attachment 62093 [details] salesforce.com sig dump
I am only still seeing this at SFDC for classes in lucene that we are patching. It's causing erroneous error badges in the editor and project tree, as NB winds up choosing the version in the lucene jar instead of our patched versions. Coupling error: class file jar:file:/home/runger/dev/app/main/core/sfdc/java/ext/lucene-core-SFDC-2.2.0.jar!/org/apache/lucene/index/CompoundFileWriter.class, source file file:/home/runger/dev/app/main/core/sfdc/java/src/org/apache/lucene/index/CompoundFileWriter.java ----- Sig file content: ------------------------------------------- not a sig file ----- Source file content: ---------------------------------------- ...skipped... ----- Coupling Error: --------------------------------------------- com.sun.tools.javac.util.CouplingAbort at com.sun.tools.javac.model.LazyTreeLoader.couplingError(LazyTreeLoader.java:61) at com.sun.tools.javac.comp.Enter.visitClassDef(Enter.java:403) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:588) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:281) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:295) at com.sun.tools.javac.comp.Enter.visitClassDef(Enter.java:557) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:588) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:281) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:295) at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:344) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:451) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:281) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:295) at com.sun.tools.javac.comp.Enter.complete(Enter.java:630) at com.sun.tools.javac.comp.Enter.main(Enter.java:615) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:853) at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:357) at com.sun.tools.javac.api.JavacTaskImpl.enterTrees(JavacTaskImpl.java:395) at org.netbeans.modules.java.source.usages.RepositoryUpdater.batchCompile(RepositoryUpdater.java:3081) at org.netbeans.modules.java.source.usages.RepositoryUpdater.access$4900(RepositoryUpdater.java:159) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.parseFiles(RepositoryUpdater.java:2161) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.parseFiles(RepositoryUpdater.java:1851) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.updateFolder(RepositoryUpdater.java:2276) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.scanRoots(RepositoryUpdater.java:1794) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.access$2700(RepositoryUpdater.java:1240) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1389) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:1283) at org.netbeans.modules.java.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:99) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1280) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:1240) at org.netbeans.api.java.source.JavaSource$CompilationJob.run(JavaSource.java:1618) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595)
jlahoda: "Sorry, but I do not understand what this means. How do you expect the IDE to work with two different classes with the same FQN?" Matching FQNs are almost inevitable for JDK developers. They are laying the ground work for Java's platform independence. Waiting for them to "clean up" could last forever. Source scanning in Netbeans 6.5 produces hundreds of NativeStrike dumps for JDK 7 and takes days on a Core 2 Duo. Netbeans shouldn't force developers into an arbitrary schema for project internal implementation reasons, in my opinion. As the other comments show this is not JDK specific either. My proposal would be to extend the FQN space with a secondary property reflecting the directory tree. Only in case of FQN conflicts the "closer" element in the directory hierarchy is chosen. Anything else would stay untouched. For scenarios like src/.../unix src/.../windows src/.../common everything would suddenly work out automagically.
Overtake.
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Seems a shame to mark this WONTFIX, since it manifests in several difference scenarios, including loading of the jdk sources.
If you continue to see this problem, esp. if it is reproducible, it should probably be reopened.
(In reply to comment #6) > It is up to the JDK team to fix these overlaps if they can. > (As a rule they seem to be resistant to any suggestions > to clean up source structure...) May change with JDK 8 modularity, TBD.