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.
In very rary cases import statements in generated Java classes occur at the bottom of the Java file as the last statement. I only saw this effect once after generating Java for a dbschema. I was not able to determinstically reproduce this effect.
Changed milestone to 3.2.1 - the behaviour needs to be yet investigated since we could not reproduce it at all. We suspect race conditions between parser and the code generation process or incorrect initialization of data in the code generator when inserting import statements/class elements.
Closing as WORKSFORME until a reliable reproduction is found.
Mistake in resolution state
NOW closing as worksforme :-)
I have seen something like this, only import statement is added on very beginning of the file. 1. Slow down the parser to parse the source for example after 1 minute (Project/Settings/Java sources/Automatic Parsing delay for 3.2 and Tools/Options/Java sources/Automatic Parsing delay for dev) 2. Go to source, write somewhere "StringTokenizer tokenizer;" (providing that java.util.StringTokenizer is not imported in this file) 3. Reformat code 4. Before automatic parsing can occur, go to "StringTokenizer" and invoke FastImport (Shift-Alt-I) and accept import for java.util.StringTokenizer 5. The import statement will be added to very beginning of file. This is probably caused by incorrect positions after reformat code (there are more bugs about this). In this case, I think that source hiearchy should be invalided after code reformat, which probably will force parsing before adding import statement (and everything will work OK, I hope). My build is 0108310100, my computer is Sun/Solaris.
No, actually the parsed information cannot be purged from memory; the current behaviour is, that as long as there's a live element from the source, the whole parse information is accessible and nonblocking for read operations. I think it is particularly bad if the reformat code operation obliterates valuable data held by other modules.
So, when I think about it, I agree with you. Editor is not doing much good job in these cases. I will suppose that root of the problems from original report is the same as in my case and will move this bug to editor.
*** This issue has been marked as a duplicate of 5620 ***
Resolved for 3.3.x or earlier, no new info since then -> closing.