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.
[ BUILD # : 200710100000 ] [ JDK VERSION : 1.6.0_02 ] The line if (pObjectKey == null) is marked as an error with the explanation that the operator == can't be applied to the pObjectKey class and null-type. The line EfiValueMap prefs = pBinder.getUserPreferences(); is marked as an error saying incompatible type, found EfiValueMap, required se.grim.effie.value.EffieValueMap. The sources compile fine.
*** This issue has been marked as a duplicate of 118744 ***
Don't belive this is a duplicate. Issue 118744 seems to be about the error badges in the tree while this bug is about the parser not recognizing correct code.
Agreed, not a duplicate. This problem shows up in many areas of my code base, but I haven't spotted a pattern.
*** Issue 119687 has been marked as a duplicate of this issue. ***
The error about null comparison is probably not important - usually this error occurs when for some reason the type of the pObjectKey variable is errorneous. The important problem is why the type of variable pObjectKey is errorneous - is the in-IDE classpath set correctly for the class? (You can check this by selecting the file in Projects tab, selectin Properties from the popup menu and inspecting the classpathes - are they correct?) What is your project type? Thanks.
The project type is freeform and there is nothing wrong with the code or the classpath. The only way I have found to remove these error indications is to restart NetBeans.
Restarting Netbeans does not work for me. My classpaths are also correct, and the project was created in Netbeans 5.5.1 via Netbeans' New Project >> Java Application (the default).
medotin does it happen for every project imported from 5.5.1? Can you send us the project where you can see the wrong error badges?
Not all imported projects have the error, only a few. I've noticed a pattern, the errored lines involve classes which have errors in their respective imports. So it does seem to be a misconfigured IDE classpath. (However again, it appears correct upon inspection.) I cannot send any projects.
I've found that I often get these incorrect error indications after I've updated my project directory with the latest version from subversion. The files compile fine but I have to restart NB to get rid of the red markings.
This still happens with RC1 with a new user directory. Restarting NetBeans does not help. Everything compiles fine but still there are error markings in the code. The projects are Freeform and uses Subversion for versioning.
I have now spent a couble of hours trying to find some pattern that could help you pinpoint this bug. I have two freeform projects, DOI and Effie. DOI depends on Effie but not the other way around. Both projects compile fine. I also have a library definition associating the Effie output jar with sources and API docs, otherwise the editor can't find them even though Effie is defined as a subproject of DOI. Effie shows no errors but DOI has lots of files with incorrect error markings in them, and error badges. Efter clearing the cache and then opening NB6RC1 there are no error markings or badges while NB is busy indexing JDK's etc. When it starts "compiling" DOI however, the markings and badges start to appear. At this stage I can start getting rid of the error markings by opening badged files in DOI that does not use any other badged DOI files. After a few seconds the markings disappear and when I close it, also the badge. By working myself upwards in the dependency hierarchy within DOI I can get rid of more and more markings. I expect to get rid of all or most of them before christmas! At home I have a dual CPU Linux box that doesn't show these problems. Weird! I have meticolously checked all classpaths and library definitions and everything seems correct. The message log shows a lot of errors from RepositoryUpdater. Will atach. Also raising the level to P1 since this bug is definately serious enough to make me go back to 5.5.1.
Created attachment 52864 [details] Message log
Do you have classes in your project which are located in the file with the different name? (e.g. the class name and package does not match file name and directory)
No.
I would like to ask for a help. I will attach a debugging patch, could you please place the attached jar into ${netbeans_install}/java1/modules/patches/org-netbeans-modules-java-source (${netbeans_install}/java1/modules should already exist, patches/org-netbeans-modules-java-source need to be created), clear IDE caches ({$userdir}/var/caches/index) and start the IDE, and attach the messages.log? Please note that the log will contain class names and absolute paths from your project. Thanks.
Created attachment 52958 [details] Debugging patch.
Created attachment 52959 [details] Message log after starting with patch installed.
I have now tried the patch. When I started after clearing the cache all the error markings came back after a while, as expected. Message log is attached.
Not sure if this is useful but after restoring the saved copy of the index and opened NB the errors were gone again but I found that there was a few error badges for files I recently updated from our Subversion repository. There wasn't any red markings in the files and the badges disappered when I closed them. This is not reproducable however. I did a new subversion update, got a bunch of new files but no error badges.
Oops, I forgot that the logs need to be enabled by a command line option: -J-Dorg.netbeans.modules.java.source.usages.RepositoryUpdater.level=0 Could you please try it again with the option. Sorry for bothering you.
You are not bothering me! I'm very anxious to do what I can to get this fixed. Will attach the new message log. Also saw a dump file that was produced on the previous attempt. Attaching that too.
Created attachment 52961 [details] Message log after starting with patch installed and activated.
Created attachment 52962 [details] Dump file.
Thanks for the logs - it seems a bit clearer now. What happens is that DoiObjectView.java depends on EfiValueMap.java, but DoiObjectView.java is compiled/parsed first, so it cannot resolve EfiValueMap. The question is why this happens - from the logs, it appears that there may be a cyclic dependency between /home/gugrim/projects/DOISuite4/trunk/DOI4/src/ and /home/gugrim/projects/DOISuite4/trunk/Effie4/src/ (meaning that each of these source roots has build artifacts from the other on the classpath). What is the dependency structure between these two source roots? Thanks.
Yes, that was it! There wasn't any "real" two-way dependency but the Effie project had a test case that used a class in DOI to drive a low level component in Effie. For this reason Effie had a classpath entry pointing to one of the DOI artifacts. I removed this entry, moved the test case to DOI where it belongs, cleared the cache and started NB. No errors! In this light I wouldn't consider this issue a P1 anymore. Maybe change the subject to something like "Can't handle circular dependencies between projects." and give it P2. I hate circular dependencies but sometimes they are necessary so NetBeans should be able to handle them IMO. NB 5 has no problems with them and I'm currently working in a client project that have almost 200 subprojects, each producing an EAR. There are a lot of circular dependencies here so upgrading to NB6 is definately not an option for this client, unless this issue can be fixed. Thanks for your help in finding the cause and good luck with the solution! :-)
With 118348.jar in place, the attached messages.log is created. The IDE compile errors are gone, but as Netbeans starts up, some error messages popup (they are detailed in the log). Without 118348.jar in place, the IDE compile errors show up, but there are no error message popups at startup. My projects do not have circular dependencies. Thanks.
Created attachment 52978 [details] With 118348.jar in place, and cleared IDE caches.
Well, I am afraid that I do not see a way to actually support circular dependencies between source roots in different projects (i.e. with different classpaths). How are the projects with circular dependencies compiled? medotin, it seems that your IDE is too old for the patch - could you please try a newer build? (E.g. NB6.0RC1?) Thanks.
I'm now running this version of netbeans: NetBeans IDE 6.0 RC1 (Build 200711131200) And I no longer have any incorrect IDE compilation errors, even without your patch.
So the issue is fixed.