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.
[ BUILD # : 7eabe626eb09 ] [ JDK VERSION : 1.7.3 ] Generate Full Classnames option is not respected anymore, and the class names are always fully generated.
Could you, please, provide more details? Does it really fail _always_ on your machine? If it fails for some forms only then please attach some test-case. Thank you in advance.
Created attachment 117332 [details] Sample project Looks like it happens just for a couple of my forms. I am attaching a sample project. I just can't remove the full classname for PesquisaPedido.java form. Any idea why it is happening? I can't reproduce it for new forms. Acctualy, when I change the Generate Full Classnames for true/false, just 'Variables declaration' has its values changed. I will decrease the priority since it looks to be a isolated problem.
Thank you for a reproducible test-case. I am able to reproduce the described problem using the attached project. Steps to reproduce: 1. Open the attched project. 2. Open PesquisaPedido.java in Design view. 3. Do some dummy change, for example, select the root container of the form (i.e. JDialog) and switch on and off its alwaysOnTop property (in Properties window). This ensures that the code is regenerated in the next step. 4. Switch to Source view => fully-qualified names are replaced in Variables declaraction section at the end of the file, but they remain in initComponents() method. The replacement of fully-qualified names is performed by by Updates.fixImports in java.source.queries (called from FormJavaSource.importFQNs() in form module) => reassigning to java/Source for evaluation.
The problem here is a mismatch between JavaOperationsImpl.getMethodSpan and JOI.fixImports. The gMS uses takes a tree, takes the attached comments, and if some (preceding) comments are attached, their position is used as the starting position of the method. The fI uses positions exactly as reported by the javac. In the attached case, however, the method header is: @SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code"> private void initComponents() { The "// <editor-fold..." comment is attached as a preceding comment directly to the method tree, and so gMS reports its starting position as the starting position of the method, while javac reports the starting position of "@SuppressWarnings" as the starting position. Due to this, this whole method is skipped from the fix imports. I see two possible solutions: 1. attach the comment to some other tree. I don't really like this option - from the "human" point of view, the comment does belong to the method, not to some other tree (the only real option in this case would be the trailing comment for @SuppressWarnings, which definitely seems wrong to me). 2. make sure the gMS uses whatever smallest offset it can find as the starting position of the method, and whatever largest offset it can find as the ending position. I will attach a patch that tries to achieve this. Note that before this patch, the starting position of the last ending comment was used as the ending position of the method, which seems incorrect to me and is fixed by the diff as well.
Created attachment 117864 [details] Proposed fix.
Any news on this?
IMHO it should be fixed at least for FCS.
Fixed jet-main 72eb08779567
Integrated into 'main-golden', will be available in build *201205120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/72eb08779567 User: Tomas Zezula <tzezula@netbeans.org> Log: #210039:[72cat] Generate Full Classnames option is not respected anymore
v. Build 20120514-2f1ba0e44a6b
*** Bug 214683 has been marked as a duplicate of this bug. ***