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: | ClassCastException when moving a class | ||
|---|---|---|---|
| Product: | java | Reporter: | Roman Strobl <rstrobl> |
| Component: | Unsupported | Assignee: | Tomas Hurka <thurka> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | Keywords: | RELNOTE |
| Priority: | P2 | ||
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
Exception
Project on which rename package fails Project on which moving of a class fails by exception |
||
|
Description
Roman Strobl
2004-11-18 15:02:23 UTC
Created attachment 18956 [details]
Exception
Reliably reproducible when starting with a clean userdir? Can you provide an exact testcase? I cannot reproduce it with a simple project (2 packages, 2 classes). 100% reproducible with clean userdir on attached project. Just try to move class A to another package by DnD in Projects view. Not reproducible on a new simple project with 1 class and 2 packages, so it's probably not as general as I thought. Created attachment 18958 [details]
Project on which rename package fails
Created attachment 18959 [details]
Project on which moving of a class fails by exception
I am able to reproduce it too! There is a difference between package declaration (package test;) and file location in the package/folder structure (<src>/abc/A.java) You're right, note that it also happens for classes B and C whose package is ok. I see the project code got broken due to refactoring tests :-( This happens when there is a field in the code of the same name as a package. In this particular case there is a package named test containing class A and this class A has a field named test. Class D extends A and references A by its fully qualified name in a body of a method (test.A). The attribution code wrongly assumes that test is the name of the variable rather than name of the package. Fixed in trunk. Checking in org/netbeans/modules/javacore/parser/MDRParser.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/parser/MDRParser.java,v <-- MDRParser.java new revision: 1.63; previous revision: 1.62 done Ok, now there's no exception, good. For verification purposes I've tried to undo this action - moving a class to another package when the package is broken. This doesn't seem to work, try to follow the steps in my comment from 2004-11-18 07:27 PST and after the class is moved, try Refactor->Undo. The contents of the class are reverted but the class stays in the new package. Feel free to close and file another issue if this problem is not connected with the fix. This is currently as designed. DnD is a separate operation from the refactoring, which responds to the fact the files were moved. The Undo action reverts only the changes made by refactoring itself. This was agreed upon with the UI team for 4.0 and is a separate issue covered by a separate report (see issue 48676 - clearly a duplicate of this, and issue 50980, which is caused by the same thing). Ok, thanks for explaining... IMO this way it is very uncomfortable for users, agree it is a seperate issue. Verified. Waiver approved for 4.0. Reorganization of java component |