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 200211210100 IBM JDK 1.3.1 I get the following error when I try to compile a file which refers to a package which does not exist. If I switch from the internal compiler to the external one, it compiles just fine. Looks like a bug in the internal compiler. net/jxta/content/ContentType.java [10:26] cannot access net.jxta.security.ID bad class file: net\jxta\advertisement\ContentAdvertisement.class unable to access file: null Please remove or make sure it appears in the correct subdirectory of the classpath.
I wonder how it is possible that the external compiler compiles a file, which "refers to a package which does not exist". Isn't that a bug in the external compiler ?
Actually no. This is a bug in Netbeans. I know as a matter of fact if I run CLEAN ALL on my project a few times and *then* try the internal compiler it will work. There seems to be some sort of class caching problem or something in Netbeans. Does the internal compiler cache the file dependency tree when compiling? That was one issue (which I guess was not reflected in my previous message). The second issue is that very often the internal compiler will give me a misleading error message as mentioned above whereas javac will give me the correct message.
OK, then. You wrote: "If I switch from the internal compiler to the external one, it compiles just fine". How it could if there's a reference to a non-existent package (net.jxta.content) ? The file must not compile - even if the offending statement is "import" and the imported identifier is not used anywhere. What behaviour do you mean by "... *then* try the internal compiler it will work" what exactly does the internal compiler ? Does it compile the ContentType.java, even if it contains a reference to unresolvable symbol (package) ? There's indeed some caching, but caches are all flushed just before compilation starts; they serve only for parsing.
Gili, isn't this the same bug as described in issue #29718 ?
Svatopuk, I am unsure if these two bugs are identical but since I did not provide enough information and I *always* work off JavaFS it is highly likely they are the same. Closing as DUPLICATE unless I see evidence to the contrary. *** This issue has been marked as a duplicate of 29718 ***
OK, reopen if they are different. During testing of the other issue, I found that the compiler produces several types of messages, depending at what stage it attempts to access the locally removed file (I think that Bad class file + unable to access was one of them). The internal compiler now simply ignores those virtual files.
*** Issue 28419 has been marked as a duplicate of this issue. ***