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.

Bug 271698 - Compile on save always acts when opening a java file (file was not changed or saved)
Summary: Compile on save always acts when opening a java file (file was not changed or...
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Compiler (show other bugs)
Version: 8.2
Hardware: PC Windows 10 x64
: P2 normal (vote)
Assignee: Dusan Balek
Depends on:
Reported: 2017-10-25 13:45 UTC by McNetic
Modified: 2017-10-28 21:56 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description McNetic 2017-10-25 13:45:41 UTC
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.