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.
As evidenced in a recent usability study, the text output "Finished <file or directoryname>." when the user does a compile is somewhat ambiguous for users. They would "guess" that this means that the compile has completed successfully, however, we shouldn't have to make our users guess. Suggestion: we should find out what information user needs to know to feel confident that the IDE did what they expected. For competitive comparison, i looked at how build /compile output appears in other IDES. What other IDEs do: -MS .NET - For each file, prints out "Compiling ... <name of file> <any errors, warnings> <name of file> - x errors, x warnings " and at the end of this list reports if the build of the solution(i.e. collection of projects) is successful or not, where the "n" represents # of projects: "Build: n succeeded, n failed, n skipped" -VisualAge - couldn't find an explicit "Compile" command, but they give out errors as you type them. -Oracle JDeveloper 9i - much like MS .NET -JBuilder - very brief dialog flashes up, only build output is in the status bar. Something like "Build succeeded. x errors, x warnings."
Set target milestone to TBD
If a user uses the Compile or Compile All command, my suggestion for each file compiled would be to have the following output: "Compiling xxx.java... <listing of any error&warning messages in xxx.java> m errors, n warnings <<Insert newline to create separation from following compile messages>> <<repeat above for each file to compile>> Compile finished: x errors, y warnings" For a the Build or Build all commands, repeat the above, but in addition prepend the output with "Cleaning..." and add "Build finished: x errors, y warnings" at the end.
I think we should take into account how java compilation works. If the stats are to be displayed for each file separately, the compiler would have to be executed for each file individually (the compiler is not obliged to output errors grouped by file or even sorted by line -- and standard javac does not do it). In that case, the compiler would be started numerous times and some classes would be even compiled twice (for the first time when they are reached through dependencies and for the second time when the compiler is invoked for that file specifically) and produce the error twice. I do not think that is an acceptable solution for performance reasons; the other one is to delay output messages until the compilation finishes so they can be sorted/grouped. Overall statistics can be created and printed.
Having overall statistics printed in the output window after the compilation finishes is better than nothing and would be a better indication to the user as to what happened. Delaying output messages is not acceptable. Developers should also think about how else the other suggestions could be accomplished that won't degrade performance. Oracle JDeveloper is able to accomplish this, so it shouldn't be a direct dependency on how the javac compiler works.
Re. Oracle Developer: I think your assumption is wrong. As JDeveloper's code deviates from JBuilder, which has its own compiler built in, I suppose they took advantage of some special features of Borland's compiler. I checked the actual compiler behaviour and it reports, in the case that there are some errors and warnings, those statistics at the end. So the OW text reads: "xxx errors yyy warnings Errors compiling <directory-or-object-name>" The "Finished" clause is printed only when the process finishes successfully. It can be possibly changed to "Build finished successfully", with the risk that it will seem strange for cleaning. It may be possible to derive the noun from type of the compiler (with some possibility of an error): if there are only cleaning processes, use "Clean". If there's at least compile/build process in the queue, use "Build".
Fixed by using Ant in new build system, it shows the number of errors in the output window.