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.
| Summary: | Copy/Paste should not create *_1 files | ||
|---|---|---|---|
| Product: | java | Reporter: | _ tboudreau <tboudreau> |
| Component: | Source | Assignee: | Svata Dedic <sdedic> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | jglick, markiewb |
| Priority: | P3 | ||
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
_ tboudreau
2004-08-22 12:40:49 UTC
Of course it should and it normally does. Can you reprodude this? Couldn't this be related to the OOME you filed as issue 47651? *** Issue 47705 has been marked as a duplicate of this issue. *** Strange - I am really not able to reproduce it. Could you please provide a sample code? My fault. It is not really that it doesn't work - it's that when a file is copied and pasted, its name is changed to something like Foo_1. That operation does not run refactoring on the file. So then when you try to rename it to something sensible, all of the references to Foo in the class are skipped because they don't say Foo_1. So, it's invalid as problem in refactoring - but probably should be fixed somehow in how a pasted file of the same name is handled. Issue #47705 sounds like something different, no? Can't imagine what Issue #47705 has to do with this. Both issues are about replacing references to a class from itself in ".class" expressions. Or am I missing something? Possibly: That when you copy and paste a file into the same package, it is renamed, but no refactoring runs, so you have SomeClass_1 with references to SomeClass in it. When you then rename SomeClass_1 to something else, refactoring works fine, but it doesn't figure out that references to SomeClass really were supposed to be references to SomeClass_1, which would be touched by the refactoring. IMO two bugs here: 1. The handling of pasting a file when a file with the same name exists in the folder is retarded - nobody actually means to create SomeClass_1, so this functionality is totally useless - it should pop up a dialog and ask for a name (IDEA handles this nicely this way). Otherwise we're just making extra work for the user to rename it later. 2. Either way, that action is going to have to trigger the Rename refactoring to run, not just rename the file and its class declaration. Otherwise trying to rename it to something meaningful is broken. For 1., yes there will have to be some handling of the situation that 10 files are copied and pasted from a folder to the same folder, but it's not an excuse not to fix it, and the most common case is 1 file. We could even leave it broken for multiple files and it would still be an improvement. Tim, your last comments is not a bug, but enhancement for java module.
Refactoring module does not create those _1 files.
> 2. Either way, that action is going to have to trigger the Rename
refactoring to run, not
just rename the file and its class declaration. Otherwise trying to
rename it to something
meaningful is broken.
trigger the rename refactoring? Why? New class SomeClass_1 was
created, but no class was renamed. No rename refactoring is needed.
Note that creation of *_1 files in general is handled by Datasystems. The java module just inherits this behavior. Overtake. Resetting assignee to default for all bugs reported against product java and assigned to moonko. |