Need to clarify that in case B,
I did a move + rename.

Cannot reproduce any of the mentionned problems. Please provide more info, as
peroject type (normal, free form) etc.

In the second problem, isn't there additional pair of brackets in the class
definition? 

Did you test it under JDK1.5? I was using JDK1.5 when encountering this 
problem. I have not tested under JDK6.

I've verified it again and I haven't seen reported behaviour. 

A. Please check if the line endings are correct (there is similar issue when
moving file which was cecked out form cvs and has line edinigs from differen OS)

B. There were huge improvements and fixing in this area last days, is it
reproducible in last build?

NetBeans IDE Dev (Build 070112)
1.5.0_11; Java HotSpot(TM) Client VM 1.5.0_11-b03
Windows XP version 5.1 running on x86
en_US (nb); Cp1252

I discovered that if you created a simple project with a barebone java class, 
you will not see any problems.

You need to use a large project - try this:

Download jdom-1.0 source zip from jdom site.
Unzip and rename build folder to _build and build.xml to _build.xml (or delete 
them).
Create a new java class project with existing source (NOT existing ant).
Specify ..../src/java as source path and add all the jars in lib into project 
library path.

Build project:
26 warnings
BUILD SUCCESSFUL (total time: 1 second)

At package org.jdom of project explorer, right click and copy Attribute.java .
Right click on the same package and paste->Refactor copy = Attribute1.java .

Now inspect Attribute1.java: Lots of errors.

Created attachment 37353 [details]
Attribute1.java

I attached Attribute1.java which resulted from my paste->refactor copy.

When trying the jdom project I used :

NetBeans IDE Dev (Build 200701111900)
1.5.0_05; Java HotSpot(TM) Client VM 1.5.0_05-b05
Windows XP version 5.1 running on x86

Yes, I can see the error now. Thanks for info.

The problem is probably caused by the line ending. The provided project uses
CRLF and the code got corrupted (even when invoked on Win). The the files are
converted to use only LF it's all ok (even on Win!). There is one additional
problem - incompatible type on "return this" but I'll file it as separate issue.

See #88424.

I believe there is an issue already lodged (either by me or someone else but I 
can't find it) about refactoring within the same source file. Since it is 
probably due to the same cause as this issue, I'll describe them here without 
opening a redundant issue entry.

Such refactoring either adds additional unwanted text or removes text.
For example.

Original method:
===============
protected int Verification(int maxVerificationLoops, State currentState)
{
  int verificationLoops = 0, verifications = 0;
  while (verificationLoops++<maxVerificationLoops &&
      !CurrentState.Verified)
  {
  ...
  }
  
  return verifications;
}


After refactor->rename [currentState to entryState].
Notice the line with redundate declaration of
int verificationLoops = 0:
===================================================
protected int Verification(int maxVerificationLoops, State entryState)
{
  int verificationLoops = 0,int verificationLoops = 0, verifications = 0;
  while (verificationLoops++<maxVerificationLoops &&
      !CurrentState.Verified)
  {
  ...
  }
  
  return verifications;
}

oops ... typo

"redundant" not "redundate"

If I understand this issue well, it is generator issue..

In this issue, many things is mixed together. 

Messed up source
----------------
When you move file, it mess up the source. -- The root cause of problem is
positions, at UNIX platform this is not reproducible. -- Again, see issue
#88424. I think this is a duplicate. Positions are incorrect (because computed
from file with CR/LF, but generating to LF only file.) Generator does not have
any chance to solve it if bad positions are provided. There exists hack, but it
slows down many generating use-cases.

Variable declaration separated by commas
----------------------------------------
Different issue. Very similar to #91010. All the declaration are represented by
separate var. declaration in tree. Code generator has to do some hacky stuff to
recognize if variable is declared separately or in a "field group" (i.e. comma
separated declaration.) Unfortunately there is no support for it and it is still
not implemented.

Marking as a duplicate. For the second reported problem, new issue was created.
(see #95533)

*** This issue has been marked as a duplicate of 88424 ***