When compile on save is enabled (at least for plain java projects and maven projects, but probably for all java based projects), Netbeans copies the (unchanged) .class file corresponding to a java file to the build/classes directory every time the editor window of the java file is activated (that means, when you open the file in the editor or it is already open and is brought to the foreground e.g. be selecting its tab).

The timestamp of the class file is being changed to current time by this, although the file is binary identical to the version from before.

This may not be a problem in many scenarios, but with third party tools depending on checking the timestamp of class files for changes, it becomes a big problem. My scenario (that should be absolutely common) is developing spring applications with spring boot and spring-boot-devtools. The latter checks the class files for changes and does a class reload when changes are detected. The combination with this bug makes debugging the application practically impossible. As soon as the debugged process switches to another source file, the class file is refreshed and the whole spring container is reloaded.

While it might be possible to enhance spring-boot-devtools to check if the class file does not only have a different timestamp, but actually changed, I think the correct solution to the problem would be the compile on save feature actually only really doing that: compiling (or updating class file) when a file really changed.