Created attachment 158088 [details]
IDE log

Reproduced in Windows 7 with Oracle JDK 7 v79 64b (jdk-7u79-windows-x64) with fresh installation of NetBeans 8.1 and a new Hello World application:

Steps to reproduce:
1) Having "Compile on Save" enabled, then Compile java file and verify timestamp of compiled class file;
2) Modify the java file and verify the timestamp of compiled class file;

Expected: class file is modified (compiled) after saving from IDE.
Result: class file is not modified after saving from IDE.

Also, this exception is thrown in NetBeans message.log:

INFO: No FileObject found for the following URL: file:/C:/Users/zeroturnaround/Documents/NetBeansProjects/TestHelloWorld/test/
java.lang.IllegalStateException: No FileObject found for the following URL: file:/C:/Users/zeroturnaround/Documents/NetBeansProjects/TestHelloWorld/test/
	at org.netbeans.modules.java.testrunner.CommonTestUtil.getTestTargets(CommonTestUtil.java:155)
	at org.netbeans.modules.java.testrunner.providers.JavaCommonTestUtilProvider.getTestTargets(JavaCommonTestUtilProvider.java:60)
	at org.netbeans.modules.java.testrunner.ui.hints.Utils.populateLocations(Utils.java:145)
	at org.netbeans.modules.java.testrunner.ui.hints.Utils.getValidCombinations(Utils.java:85)
	at org.netbeans.modules.java.testrunner.ui.hints.CreateTestMethodsHint.computeWarning(CreateTestMethodsHint.java:114)
	at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.netbeans.modules.java.hints.providers.code.CodeHintProviderImpl$WorkerImpl.createErrors(CodeHintProviderImpl.java:339)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.runHint(HintsInvoker.java:810)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.access$400(HintsInvoker.java:112)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.runAndAdd(HintsInvoker.java:669)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scanDoNotGoDeeper(HintsInvoker.java:723)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeSuggestions(HintsInvoker.java:397)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:233)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:210)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:183)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:150)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:137)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:88)
	at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:298)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:584)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:809)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:304)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:725)
	at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:686)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
INFO [null]: Last record repeated again.

Created attachment 158139 [details]
Windows 7 Netbeans 8.1 log file with exception

Also reproducible reliably on Mac OSX 10.9.5.

The class files in project dir are not updated by compile on save any more. This feature updates the compiled classes in cache dir. 

When you run the project next time, are the changes respected?

@Jiri Prox Why "RESOLVED INCOMPLETE"? It still seems like a bug.

Restarting Netbeans or re-running application makes no difference.

One more observation - the class files in standard output directory will get updated after Run or Debug gets stopped. E.g.:
* Run simple application (with CoS enabled).
* Change java file, save.
* Observe timestamp change of java file in src.
* Observe no timestamp change of class file in build/classes
* Stop the running application.
* Observe timestamp change of class file in build/classes

Note that CoS seems to work fine with a web-application. So far, I have only reproduced the problem with simple java app with main().

The behaviour affects badly users of e.g. JRebel that picks up and reloads changes to class files in standard output directories.

RESOLVE INCOMPLETE means that we're waiting for response, the issue in not closed.

What you describe is designed behavior.
See the test specification:
http://services.netbeans.org/synergy/client/app/#/suite/1969/v/1

Have you tried JRebel plugin?

Thanks a lot for the links.

I read from the test specification that it actually should update standard output directories too:
1. http://services.netbeans.org/synergy/client/app/#/suite/1969/v/1 states that "The test cases should be performed in a row since they depends on result of previous case."
2. This step asks to Run (but not stop) http://services.netbeans.org/synergy/client/app/#/case/2575/suite/1969/v/1
3. Immediately next step asks to change+save a file (and does not ask to stop running program) http://services.netbeans.org/synergy/client/app/#/case/2576/suite/1969/v/1 and expects "The .class files is updated in build/classes folder"

Also I couldn't find any mention that CoS should behave differently for web projects and simple java applications.

Yes, I have tried with JRebel and it doesn't work because standard output directory is not updated.

The mentioned specification is for common j2se project, so no stop application is needed, it just ends by itself.

For simple hit-and-run applications this is definitely true, agreed. Bur for example background applications or Swing GUIs are meant to run longer. And this is where CoS+JRebel can immensely boost development.
So from the perspective of those developers, it is definitely a regression.

Besides test-specification that may be a bit ambiguous here, is there any other specification or discussion on how CoS is meant to work? I just can't see a reason why it shouldn't update standard output directories.

Hi,

Thanks guys for having a thorough look into this so far.

Maybe it is not even the most relevant question here whether the current
implementation follows the letter of current specification with 100% accuracy.
A more important question maybe really is what Andrus asked last - are there
any reasons why shouldn't "Compile on Save" compile class to the standard
output directory? (i.e., maybe there are reasons to change the current
specification.)

On the other hand, here are some reasons why it would be beneficial if "Compile
on Save" functionality would update classes in the normal build/classes
directory:
* New versions of classes would be available in main build dir, with fresh
timestamps. If end-user now executes his build tool via command line ("mvn
compile"), it would speed things up by not recompiling classes that IDE has
actually aready compiled and updated.
* New versions of classes would be available for class reloading tools like
JRebel. JRebel monitors the build/target directory for updates to .class files,
and picks them up on its own (without application re-execution). This makes a
lot of sense for developing long-running fat-client desktop applications,
custom servers, background applications, etc. The whole point of class
reloading tools is that the end-user _does not_ restart his application.

Thanks!