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.
dev build 200805071203 I've got two open projects which define the same class name but with slightly different definitions. One definition has a certain method, another does not. One is used on a client, another on a server. In any case, what I noticed is that Netbeans' code parser doesn't seem to respect the "main project" setting because it marks a method invocation as an error (underlines it using a wavy red line) but when I actually compile the file using F9 it works fine. Furthermore, it seems that if I open the main-project-specific version of the class in the editor the underline suddenly goes away as if it updated the parser to use the correct version. In summary, what I am expecting is the code parser to use the "main project" as a compilation root. The parser should uniquely identify classes by "projectName.packageName.className" name instead of just "packageName.className".
As further proof of my point I noticed that if I click on a reference to the class (using CTRL+LMB) it opens the wrong class definition. More specifically: Project A defines MyPackage.MyFactory Project B defines MyPackage.MyFactory Project A and Project B do not dependent on one another. Both contain different definitions of MyPackage.MyFactory When Project A is the "main project" and I click on a reference to MyFactory using CTRL+LMB I expect the definition from Project A to come up, but instead the one from Project B does. I hope this clarifies what I mean :)
reassign to editor
Sorry, but I am still confused - where is located the class in which you Ctrl-clicked to go to MyPackage.MyFactory? What is the relationship between this class and the projects A and B? Please note that the java parser ignores projects (and their relationships) as such - it uses only classpath specified from the given source file(s). When you Ctrl-click, the target class is looked-up using the classpath. Main project setting does not have any effect on the target of Ctrl-click. You can verify the IDE's idea of the classpath for your class by right-clicking the Java node and choosing Properties.
Main Class *should* affect CTRL+click because if you have two projects open which are totally unrelated then you will end up with different classpaths whether one is the Main Class or the other. If I have two projects open, both of which define different versions of SomePackage.SomeClass, and I CTRL+click on a class then Netbeans should use the Main Class to determine which version of SomePackage.SomeClass to open. Do you understand what I mean now?
In what class do you Ctrl-Click? (In which project is it located? What is its classpath?) Sorry, but the Java infrastructure should not modify its behavior this way based on the main project setting. If a file is opened in the editor, the classpath of the opened file is authoritative source of information. If you Ctrl-Click on a class name in the editor, and the class is on the classpath, the class on the classpath is opened.
I CTRL+click on a class defined in Project A and it opens the version of the file found in Project B. How do you determine the classpath when someone ctrl+clicks on a class? I would have thought it is determined by the Main Class? From what you're saying it sounds to me that when someone ctrl+clicks on a class, the file open in the editor is used to determine which project it came from and then that project is used to determine the classpath. I'm not sure that makes a lot of sense because multiple projects could all point to the same file and yet have a different classpath. Please explain to me how you determine what the classpath is when someone ctrl+clicks on a class.
In the IDE, a file cannot belong to more than one loaded project. The classpath is in most cases determined from the project that owns the given file. If you would have two projects claiming ownership of one file, it would explain your problems - but I do not think there is anything that could be done about this.
To make it clearer: one file can belong into more than one project, but at most one of them can be loaded in the IDE at any time.
I don't have two projects owning the same file, but I'm saying it's quite possible. In my case I open a file from Project A, ctrl+click on a class inside it and expect the class from Project A to open. Instead, the class from Project B opens even though Project B isn't at all in the classpath of Project A and Project A is also the Main Class.
In case the file is owned by only one project, we will need a reproducible test case - IIRC, I have never seen such behavior, so I have not idea what is the cause. In case the file is owned by more than one currently load projects, it is impossible to us to do anything about it (at least not in the java/editor), I am afraid (in you case, presumably, the IDE would suppose the file belongs to Project B).
I haven't reproduced the problem yet but I've discovered what could be a related problem. Windows Vista aliases "c:\documents and settings\gili" to "c:\users\gili". I opened my project file at "c:\users\gili\somePath" but the project's source/test directories pointed to "c:\documents and settings\gili" instead. I believe what happened is that the project was created on a pre-Vista system but opened on a post-Vista system. The problem is that Netbeans does not know that "c:\users" is an alias for "c:\documents and settings" so it messes up the code parser very badly. For example, if I open a file from project A in the editor, then hit CTRL+SHIFT+1 Netbeans asks me "do you wish to open Project A?" which is already open. I suspect this sort of path canonicalization problem accounts for other parser-related bugs. One would think that File.getCanonicalPath() would fix this, but it does not. So, is this a bug in the JDK or in Netbeans? I tend to believe that the JDK should handle this. What do you think?
According to http://en.wikipedia.org/wiki/Symbolic_link#Windows_Vista_symbolic_link these really are symbolic links, not just NTFS "junctions". I am fairly sure this is a bug in the JDK so I filed a BugParade issue. I will let you know once I hear from Sun.
What do you guys want to do about this issue? I don't think it is "incomplete" any more but issue 135547 is blocking it.
Oops, I closed the issue by mistake.
Well, I do not think there is anything that the Java (infrastructure|editor) could or should do about this - when a classpath is given, we should not magically change it. I am not sure about Windows, but on UNIX, we do not resolve symbolic links on purpose.