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 253898 - [81cat] Rename class refactoring corrupts code
Summary: [81cat] Rename class refactoring corrupts code
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 8.1
Hardware: PC Windows 8 x64
: P2 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-28 12:26 UTC by cezariusz
Modified: 2015-08-13 01:19 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Sample project (36.60 KB, application/octet-stream)
2015-07-28 12:26 UTC, cezariusz 		Details
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 cezariusz 2015-07-28 12:26:35 UTC 
Created attachment 154972 [details]
Sample project

Product Version: NetBeans IDE Dev (Build 201507280002)
Java: 1.8.0_51; Java HotSpot(TM) 64-Bit Server VM 25.51-b03
Runtime: Java(TM) SE Runtime Environment 1.8.0_51-b16
System: Windows 8 version 6.2 running on amd64; UTF-8; pl_PL (nb)

Steps to reproduce:
1. Open the attached project
2. Open RenameTest module
3. Open the class managePane
4. Note there are no errors in the project
5. Invoke rename on the class name
6. Enter "NewManagePane" and press "Refactor"

EXPECTED: Class renamed, no compilation error
ACTUAL: Source is corrupted with a lot of errors

Marking as P2, because it leads to data loss - undo is not available after the action.
Comment 1 Ralph Ruijs 2015-08-10 10:07:28 UTC 
Processing of custom code seems to be the cause. Will investigate further.
Comment 2 Ralph Ruijs 2015-08-10 12:01:24 UTC 
(In reply to Ralph Ruijs from comment #1)
> Processing of custom code seems to be the cause. Will investigate further.

Ignore my last comment. The form file has different values for the custom-code than the corresponding java file. C3Button vs C3ButtonSmall
Comment 3 Ralph Ruijs 2015-08-11 10:08:27 UTC 
The created trees and generated code seem to be ok, but it looks like something goes wrong with the line diff. Reassigning to java.source, please evaluate. Thanks!
Comment 4 Svata Dedic 2015-08-11 13:57:56 UTC 
I narrowed down the search for bug origin to ComputeDiff.getLongestCommonSubsequences(). It will be tough...
Comment 5 Svata Dedic 2015-08-11 14:37:58 UTC 
Lucky day ... it seems that matched line set was carried over between editable sections. I made it reset at section boundaries, so the diff cannot alias lines if they come from different editable sections.

Fixed in jet-main#36ed38b8c71a

Needs HEAVY testing of refactoring/changes through GUI on form sources.
Comment 6 Quality Engineering 2015-08-13 01:19:30 UTC 
Integrated into 'main-silver', will be available in build *201508130002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/36ed38b8c71a
User: Svata Dedic <sdedic@netbeans.org>
Log: #253898: matches are reset for each editable section