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.
Product Version: NetBeans IDE 8.1 (Build 201510222201) Updates: NetBeans IDE is updated to version NetBeans 8.1 Patch 1 Java: 1.8.0_91; Java HotSpot(TM) 64-Bit Server VM 25.91-b14 Runtime: Java(TM) SE Runtime Environment 1.8.0_91-b14 System: Windows Server 2008 R2 version 6.1 running on amd64; Cp1252; en_US (nb) User directory: C:\Users\richter\AppData\Roaming\NetBeans\8.1 Cache directory: C:\Users\richter\AppData\Local\NetBeans\Cache\8.1 I've found a minor "glitche" in rename behavior. I've discovered that while debugging an app. While debugging web app (I suspect the same happens not debugging, but plain run), I've observed the following behavior: 1) Create a file: src/br/com/mycompany/X.java 2) compile file X.java to generate X.class (or project, doesn't matter) 3) look build folder, the file is there: build/web/WEB-INF/classes/br/com/mycompany/X.class 4) rename source file X.java to Y.java 5) compile file Y.java (or the project) 6) look build folder, there are two files there: build/web/WEB-INF/classes/br/com/mycompany/X.class build/web/WEB-INF/classes/br/com/mycompany/Y.class Workaround: 7) Execute Clean & Build (or Clean, then Build) 8) look build folder, there is one file there: build/web/WEB-INF/classes/br/com/mycompany/Y.class Regards, Edson Richter
Annoying, but minor. In order to properly handle the situation one would have to track/record all toplevel classes within file externally, then erase all classes located in the file.
(In reply to Svata Dedic from comment #1) > Annoying, but minor. In order to properly handle the situation one would > have to track/record all toplevel classes within file externally, then erase > all classes located in the file. Sorry. I disagree: 1 - it is not minor, since it causes runtime errors hard to track. Specially in big projects with several contributors, it is really trouble. 2 - it is not necessary to keep a external file to track changes - just add task to delete .class files on rename (a step on refator) and/or on versioning update. Regards, Edson
(In reply to ecerichter from comment #2) > 1 - it is not minor, since it causes runtime errors hard to track. Specially > in big projects with several contributors, it is really trouble. theoretically, incremental compiling should provide the same as rebuild; the reality is different even without this bug. > 2 - it is not necessary to keep a external file to track changes - just add > task to delete .class files on rename (a step on refator) and/or on > versioning update. which .class file :) ? Consider nonpublic toplevel classes - any name can be used. Clearing just same-named .class file will not solve the issue in its entirety, and errors produced by leftovers will be even harder to spot.