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 6003 - Anonymous inner class in a constructor can cause code to be deleted during copy or rename of class.
Summary: Anonymous inner class in a constructor can cause code to be deleted during co...
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: All All
: P1 major (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-03-17 03:22 UTC by Jesse Glick
Modified: 2011-02-17 11:01 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2000-03-17 03:22:30 UTC 
See attached files. They are in the default package. I got this problem accidentally and reduced the test case to this. Note that Test1 is a valid source (compiles without errors). If you copy it an
d paste it to the same package, thus creating a class Test1_1, you get the attached class--note that part of the constructor has been deleted. Apparently the parser is confused by the inner class.

Also if you rename it, the same thing happens--the class name and constructor name are correctly changed, but the constructor body is munged in this way.

I saw this in Build 500 (1.0 RC3) on NT4. Nothing of interest on console.
Comment 1 Quality Engineering 2003-07-02 17:19:57 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 2 Quality Engineering 2011-02-17 11:01:51 UTC 
Integrated into 'main-golden', will be available in build *201102170501* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/768552d632fd
User: Jesse Glick <jglick@netbeans.org>
Log: testRenameHiddenEntry failed apparently at random in NB-Core-Build #6003; fails consistently for me without optimalResult=true.