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.
Martin (and, may be, Svata :-), Again, new issue concerns VCS and java modules, I think. The problem is - I don't know, how anybody can reproduce the issue, as it concerns my own src tree. So, I'll describe as I see it. Env: build from current CVS dev trunk, j2se 1.4.1_02, win xp. Use case 1: 1. start the IDE with empty user dir, 2. moun needed jars and _local_ directory (~1000 java files), 3. select internal java compiler in Options, 4. "Build All" for src root or any subtree (package) - all is OK. Use case 2: 1. start the IDE with empty user dir. 2. moun needed jars and VCS (CVS win2000 profile) directory (the same dir as in use case 1). 3. select internal java compiler 4. "Build All" for src root - is OK 100%. 5. "Build All" for almost all subtrees is OK, but (the issue), for some subtrees, it shows in OW: "Errors compiling <package name>." And it's 100% reproducable for these some package. OW doesn't contain ant other mesages. "Build All" for src root is still OK. When external compiler is selected - all works fine in any case. Can anybody point me how to make this issue report more usefull? Thanks!
Can this be evaluated by Java guys? I don't thing this problem relates to VCS modules at all.
Try to run the IDE with -J-Dnetbeans.debug.exceptions=true and observe the logfile. There may be some exception related to the compile. Does something happen to the source or output directories externally ? .class generation or something which would require NetBeans to refresh FileSystems to see files properly ? Did you select multiple subtrees, or just one - and sometimes that produces an error ? How is your compiler set up (particularly, is there a Target directory set) ?
Svata, 1. With the noted property (-Dnetbeans.debug.exceptions=true) this exception was caught: java.lang.NullPointerException at org.netbeans.modules.java.gj.V8ClassWriter.outputFileObject(V8ClassWriter.java:75) at org.netbeans.modules.java.gj.V8Engine.writeClass(V8Engine.java:257) at org.netbeans.modules.java.gj.V8Engine.genCode(V8Engine.java:249) at org.netbeans.modules.java.gj.V8Engine.compile(V8Engine.java:391) at org.netbeans.modules.java.gj.JavaCompilerGroup.start(JavaCompilerGroup.java:132) at org.netbeans.core.compiler.CompilationEngineImpl$CompilerThread$GroupCompiler.run(CompilationEngineImpl.java:280) Errors compiling db. Some file were compiled, some - were not. 2. Nothing external intervention into FS. 3. Every time just one node (package) was selected. 4. No target directory, internal compiler settings were changed (from default): - encoding -> Cp1251 - deprecation - > true 5. I'd want to emphasize, the issue takes place with VCS FS only. When sources are mounted as a local dir, all works fine.
Adding RANDOM keyword, I cannot reproduce it. I've tested it with openide/src.
Jan, It's very interesting the way you have tested :-) I have about ~200 packages, and have found only few ones the issue takes place. And, I want to repeat, I'm using VCS FS (CVS win 2000 profile). Are there any other way I can supply additional info (besides sending all my src :-)?
I don't know, what is interesting on openide sources. :o) Do you have any idea how can I reproduce it? I did all those steps from your use case 2.
When we looked at the source, we could not realize where the null parameter came from. I will try to prepare a patch which would log various things that may contribute to the issue. BTW no need to vote for an issue that you created -- the creation itself indicates that you are quite interested in the fix ;-)
Jan, may be Svata'a probable patch will help. I can not suggest anything clever :-)
Svata, Have you some success in the patch preparing? Thanks in advance!
Sorry for the delay. I had to fix some accessibility stuff prior this one.
Created attachment 9388 [details] Added logging of parsing/code generation
Please try the attached patch - replace $nb_install/modules/ext/java-gj.jar with the attached file (and of course save the original one). When you encounter the exception, please *zip* the ide.log (or better: the portion that recorded the last IDE session) and attach it here. Thanks.
Svata, Are you sure you have uploaded needed java-gc.jar? :-) 1. There is no _any_ new output, 2. All .class files in jar have 21-feb-03 as creation date. Andrew
Created attachment 9390 [details] This binary should be really patched ;-\
Another "human failure". It seems that I copied the first .jar from a wrong folder :-\ Most of files in the jar should have timestamp 27-Feb, except a few, which are 13-Mar.
Created attachment 9392 [details] Svata's patch out
Svata, ide.log file is uploaded. Of course, OW has already reported NPE.
Svata, I have looked at your patch out. It seems, the error takes place with DTField.java. May be it is important: it is java bean, and appropriate jar file is added to form designer palette. Andrew
Andrew, I have to ask you to perform yet another test. I would like to confirm my suspicion as there was (as usual) at least one trace message missing from the patch. Please try to reproduce with the the 3rd version java-gj attached here. Re. your last comment -- is the DTField bean's source mounted somewhere in FileSystems ? Has that FileSystem COMPILE capability ? Is DTField's source underneath the folder you have applied Build action on ? Evaluation for Tomas: so far it seems that something in the code references DTField.FormListener directly -- for some reason, DTField is not commenced for compile (e.g. it is up to date ? when building, rather than compiling ??), and the source file is reached through completing a ClassSymbol from source (V8EngineBase.complete()). That method uses overloaded parse(String filename, ...) which does not register Tree.TopLevel in the FileObject hashtable. The difference in file path (forward vs. backward slashes in exactly the erroneous case) is caused by filename.replace(File.separatorChar, '/') in the complete() method. If Andrew's next test confirms the suspicion, then the fix is indeed trivial.
Created attachment 9394 [details] 3rd patch version
Created attachment 9395 [details] third patch out
Svata, 1. Third patch out is uploaded. 2. Bean's source is mounted with all capabilities, bean's jar added to components palette. 3. Bean's source is from _another_ package (gs.lib.ui.beans) rather package under "Build All" testing (gs.lib.db). Andrew
It's not random at all and may occur fairly frequently. Create a class A and B. Make A reference B (e.g. new B(); somewhere). Modify B and save it. Set the default compiler to Internal and set compiler'sTarget property to null. Rebuild A (when only A is selected). NPE. Fixed in trunk: /cvs/java/external/java-gj.jar.scrambled,v <-- java-gj.jar.scrambled new revision: 1.11; previous revision: 1.10 done Checking in java-gj_ja.jar.scrambled; /cvs/java/external/java-gj_ja.jar.scrambled,v <-- java-gj_ja.jar.scrambled new revision: 1.4; previous revision: 1.3 .. and in R35: /cvs/java/external/java-gj.jar.scrambled,v <-- java-gj.jar.scrambled new revision: 1.10.2.1; previous revision: 1.10 done Checking in java-gj_ja.jar.scrambled; /cvs/java/external/java-gj_ja.jar.scrambled,v <-- java-gj_ja.jar.scrambled new revision: 1.3.12.1; previous revision: 1.3
Svata, Thanks! The fix works for me. BTW, is it clear now, why the issue was with VCS FS only (with local FS, building was without error)?
Hehe, no. I don't think it had something to do with VCS filesystem. I was able to reproduce on local fs, the exactly same error. The order in which you attempted to compile your sources does matter (because when the class that used DTField was compiled, DTField.class was or was not up-to-date depending on what was compiled before that). Maybe there's some inconsistency in timestamp handling and VCS ? (so that .class file sometimes appear as out of date even if it is not ?)
Already verified by reporter