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.
I'm currently using Visual Age for Java, but (mostly) because of its lacking support for CVS I'm looking for a replacement IDE. Something it has though, which NetBeans lacks, is an incremental build process. Basically, every time a .java file is updated in any way -- I save a new file, a file is updated from CVS or any other way -- it gets compiled into a corresponding .class file and compilation errors are reported immediately (and I can choose between fixing them at once or ignoring them for now). Thus, there are no separate menu items or such for building the project. All classes (containing a main() method) are immediately executable (unless they have errors that is). As the point of writing stuff (using an IDE or not) is creating things that work, I find being continously aware of what things work and what things don't is very valuable. I realize that this is a large feature to add, and that it may or may not fit with your vision of where NetBeans is going, that it may or may not be hard to integrate with your ANT and Makefile support etc, but *I* want it and here's my feature request. Hope you agree :-).
I am not sure if this can be implemented on core side. What think others? Maybe java? Now the icon image informs you about syntax correctness. There can be some perf. issues when after each save of java document will this be compiled.
Feature request for java module I guess... One comment from my user point of view - I am affraid that such support would not fit into the way how I work. I'd rather see java team to concentrate on projects and metadata repository support than this. It is opensource project thus if somebody really wanted such feature he would write it...
Unforturnately that's not how open source projects work in practice. Except for really wanting the feature, that somebody must also have the time and skill to do it. Also, if "somebody" can use another IDE, s/he is not very likely to bother even if s/he has the want, time and skill to do it. Regarding your other comments: If this doesn't fit your way of working, but it fits mine, maybe there should be some kind of poll? Perhaps just waiting to see if this bug gets any dups or any votes would be enough, perhaps not. It's your project, you decide :-). And that there are other things that have higher priority than this doesn't surprize me too much. If that's the opinion of the development team or whoever makes those types of decisions, this item should get its priority lowered. Also, maybe the milestone should be something later than 3.3 (although I don't know what).
Well, the document is parsed anyway, which can discover syntax and some semantic issues. Triggering compilation (on background) after a successfull save-parse is probably OK (controlled by some option), but we'll get into troubles when two mutually dependent files will be modified.
Two solutions: 1: Do what VAJ does; perform a real re-build of the class and provide feedback on it before the user is allowed to do anything else. 2: Queue the re-builds and do them in the background. As they are completed, mark classes with problems with some extra icon in the explorer (I believe there already is one that could be used). In case two interdependant classes are modified, here's how the solutions would work: Solution 1: After you edit your first class, the compiler says it's broken. You click ignore, edit the next class, and the problems go away when you save it. Solution 2: While you edit the second class, the first class will be marked as having problems. After you have saved your changes to the second class, both it and all classes that depends on it will get re-compiled. When both interdependent classes have been re-compiled, the error markings will go away.
The fun is, that the IDE does not know dependencies between classes - the compiler does not provide this feedback (except Jikes). And analysis on the resulting bytecode is quite costly.
Having the IDE keeping track of file dependencies might be rather helpful from time to time (like now). Possibly there should be a separate issue about it. I have no idea what the byte code looks like, so I can't say how complicated extracting a list of class names from bytecode would be. It sounds simple to me, but that usually means I don't understand the problem correctly :-). If Jikes provides the necessary information, couldn't incremental compilation be a jikes-only feature? Also, regarding other compilers, doesn't Sun's Javac accept some flag (--verbose or -v or something) that makes it spit out more information? Maybe you could even trick your fellow SUNners into implementing that for 1.4 :-). Either way, if Jikes is available, maybe Jikes could be used for extracting dependency information even if the user wants to use another compiler for the actual build. Another option would be to implement a Java parser (just the parser, not a complete compiler) to extract this kind of information from the source code. This would be quite useful for features like context dependant code completion for instance. But yet again, there should probably be another issue tracking that.
Target milestone -> 3.3.1.
Cleaning up before 4.0 planning
Target milestone was changed from not determined to TBD
I suggest enabling an option to auto-compile files when they are saved. This option should only work after the project is entirely built for the first time. If an error occurs because some class is missing or something, then display this error in a separate error/problem window.
2 cents: Why would this be a P1 issue? I cannot see any immediate showstoppers (at most inconvenience to some) in not having an incremental build process. Given the Java editor always do in-place checks and display compiler errors (and as far as I understand these are directly implement using Compiler API in 6.0) I don't see any point in duplicating this feature of Eclipse / IDE that you have mentioned. As for the class files, one should never need them up till running / deploying / packaging the project. Don't know about you, but the incremental build "feature" in Eclipse gave me endless headaches when it failed to bring other classes up-to-date; I went on and on wondering where the bug is, and it turns out that a clean & rebuild is all I need!
IMHO the issue is obsolete. NetBeans supports "Compile on Save", which only compiles changed files. http://wiki.netbeans.org/FaqCompileOnSave So mark as worksforme.