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.
When more than 10 files are being compiled on Windows, Netbeans generates temp file containing list of files to be compiled. This is however not support prior to jdk1.2beta4. This also relates to javadoc from jdk1.1. Netbeans/Forte should check which jdk version is the external compiler before compiling using the @ operator. This issue exists in all versions, but most affected are Windows users because the treshold value in Unix is apparently different and files are passed as arguments.
I'm afraid we must use @ due to limited length of Windows commad line.
There is no reason for using @ if someone is just compiling a small project. You comment sounds too much like we will not support pre1.2beta4 jdks, which I believe is not the right approach. Even with large projects, you can split the compilation into several steps, since the code already has to generate list file, it can just generate small enough command lines and compile them one at a time, if it detects jdk not supporting 1.1.8. The reason why this is important is because most browsers out there still do not have plugins for new jdks and I'm not sure how far one can trust the cross compilation switches.
Correction, the "detects jdk not supporting 1.1.8" should be "detects jdk not supporting @". Sorry about this.
Well.. running the compiler several times could be a good workaround, but the price is excess error messages. If there's a file, which has errors in it, it could be attempted to compile several times (bcs of references from the other files being compiled), so the error may appear several times in the output window. But it will allow compilation around javac AND windows limitations and the same time. Right now, the IDE cannot detect which compiler it is working with (although such nice thing is planned for 4.0); I think that an expert property on java compilers could do. BTW the cross compilation switches are quite good (-target 1.1), but you have to set the -bootclasspath as well to be sure that you didn;t accidentally use some class from JDK > 1.1.8 in your code. I will try to change the java compiler invocation scheme, not sure the implementation makes it into 3.4 release. The code which constructs the commandline still lies in OpenIDE for the most part, making it difficult to customize in a module. Oh well :-)
I prefer not to show the controlling property in IDE GUI for 3.4 (we are ways after feature freeze now). I will recategorize this issue as a feature request for the new project system (4.0). I have prepared a work around for 3.4 timeframe: when the IDE is run with parameter "-J-D org.netbeans.modules.java.extCompileMultistep=true" the IDE will launch the compiler multiple times, passing filenames whose cummulative length does not exceed some threshold to each invocation. The threshold value is set to 256 initially and can be adjusted by setting property "-J-D org.openide.compilers.filelistThreshold=xxxx" where `xxx' is the max allowed cummulative pathnames length. Also see issue #25395 Fixed in trunk: /cvs/java/src/org/netbeans/modules/java/JExternalCompilerGroup.java,v <-- JExternalCompilerGroup.java new revision: 1.43; previous revision: 1.42
Jirko, can you verify it? Thanks.
VERIFIED
Resolved for 3.4.x or earlier, no new info since then -> closing.