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 175309 - [68cat] Rename does not report conflicts when renaming class existing in other source root
Summary: [68cat] Rename does not report conflicts when renaming class existing in othe...
Status: RESOLVED WORKSFORME
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: lujop
URL:
Keywords: NETFIX
Depends on:
Blocks:
 
Reported: 2009-10-23 15:46 UTC by stefan79
Modified: 2010-10-06 13:42 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
A sample Project. Rename the TestClass MyClass1 to MyClass2 and you´ll see the result. (11.02 KB, application/octet-stream)
2009-10-29 16:05 UTC, stefan79
Details
Initial patch (4.35 KB, patch)
2010-04-14 21:19 UTC, lujop
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description stefan79 2009-10-23 15:46:54 UTC
[ BUILD # : 200910212001 ]
[ JDK VERSION : 1.6.* ]

When the Junit-Class has the same name as the original class and you rename the class, the refactoring renames any
occurence of the original class.

For a Test:
-) New Java-Application Project
-) Create a Class MyClass1 in package package1
-) Create a JUnit-TestClass (4.x) "MyClass1Test"
-) Rename the Class MyClass1Test to MyClass1
-) Rename the Class JUnit-Test-Class MyClass1 to MyClass2
-) Result:
The Class1 (at src-folder) looks like this (Name is still MyClass1.java):
public class NewClass2 {

    public NewClass2() {
        System.out.println(" " + NewClass2.class.getName());
    }

    public void myMehtod() {
        
    }
}
Comment 1 Michael Nazarov 2009-10-26 09:07:04 UTC
Sorry it looks like some misunderstanding about MyClass / NewClass
I was unable to reproduce it, would you please provide more details
with exact names or classes, files etc.?
Comment 2 stefan79 2009-10-27 08:29:41 UTC
Ok. Result was wrong.

The problem is, that renaming the test-Classes renames any Occurence of the productive-Class.

-) New Java-Application Project
-) Create a Class MyClass1 in package package1 
   ->src/package1/MyClass1.java

-) Create a JUnit-TestClass (4.x) "MyClass1Test" 
  Tools/Create JUnit-Test
  ->test/package1/MyClass1Test.java

-) Rename the Class MyClass1Test to MyClass1
  test/package1/MyClass1Test.java -> test/package1/MyClass1.java

-) Rename the Class JUnit-Test-Class MyClass1 to MyClass2
   test/package1/MyClass1.java -> test/package1/MyClass2.java

Result of src/package1/MyClass1.java:
----
public class MyClass2{

    public MyClass2() {
        System.out.println(" " + MyClass2.class.getName());
    }

    public void myMehtod() {
        
    }
}
----

Comment 3 Michael Nazarov 2009-10-27 11:46:42 UTC
Sorry I'm unable to reproduce it. Original java source file was not touched
by these manipulations.
May be there is something more?
Comment 4 stefan79 2009-10-29 16:05:15 UTC
Created attachment 90216 [details]
A sample Project. Rename the TestClass MyClass1 to MyClass2 and you´ll see the result.
Comment 5 Jiri Prox 2009-11-04 11:03:57 UTC
reproducible, thanks for sample project, but I'm not sure if it is good idea to have two classes with the same FQN in
one project



Product Version: NetBeans IDE Dev (Build 200910310201)
Java: 1.6.0_15; Java HotSpot(TM) Client VM 14.1-b02
System: Linux version 2.6.24-23-generic running on i386; UTF-8; en_US (nb)
Comment 6 stefan79 2009-11-09 04:30:51 UTC
> reproducible, thanks for sample project, but I'm not sure if it is good idea to
>have two classes with the same FQN in
>one project
I don´t want this. 

Following situation:
I made a copy of a JUnit-Test-Class and then I set for the field "New Name", the name of the src-filename (instead of src-filename+Test).
Then I renamed the file src-filename + Test.
The result was, that I had to change ~30 source-Files back.
Comment 7 Jiri Kovalsky 2010-03-26 14:47:35 UTC
This issue was added to the list of NetFIX [1] candidates. If module owner does not agree, please speak up. Thanks!

[1] http://wiki.netbeans.org/NetFIXIssues
Comment 8 lujop 2010-03-26 22:42:55 UTC
I've looked at that issue to try to NetFix it.
But it's not clear to me the fix that has to be done.

I think that you won't be able to have the two classes with the same FQN. Because as test sources import normal sources there is a name conflict and I think that this makes no sense and it's very confuse. 
In fact seems that when the two classes has the same name the one in src takes preference over the one in test. And then the test can't never be run because the test runner tries to run the src class that has preference.

A good solution will be possibly to not allow classes with the same FQN in the two sources. And don't let to create the tests or refactor the classes to have the same names. It's a good solution? It's Netfixable?
Comment 9 stefan79 2010-03-31 13:03:32 UTC
(In reply to comment #8)
> A good solution will be possibly to not allow classes with the same FQN in the
> two sources. And don't let to create the tests or refactor the classes to have
> the same names. It's a good solution? It's Netfixable?

Yes, it´s a good workaround.
Comment 10 lujop 2010-04-01 07:02:29 UTC
Can I start to work and try to NetFix with my proposed solution?
Comment 11 Jiri Kovalsky 2010-04-01 08:57:22 UTC
Tomas Zezula agrees to review & integrate possible patch. And by the way he says that the only correct fix is to prevent Refactoring from seeing "src" folder.

If you want you can try to fix this Joan. Good luck!
Comment 12 lujop 2010-04-14 21:19:16 UTC
Created attachment 97397 [details]
Initial patch

I submit an initial patch. I know that it isn't completely correct but if it's possible I want to know if it's in the correct direction.

For me the patch works with two problems:

-1-
When I check if the rename is correct in the complementary source I use the filesystem and that doesn't work for non public classes.
I suppose that I've to get a TreeHandle and look with RetoucheUtils but I've to investigate how to do that. Any hints of where to start?

-2-
Package renaming isn't checked

Can I continue and complete the patch?
Comment 13 Jiri Kovalsky 2010-04-14 21:31:23 UTC
Tomasi, can you please evaluate this patch and give Joan some hints? Thanks!
Comment 14 Jiri Kovalsky 2010-04-21 19:56:36 UTC
Any update Tomasi? Thanks a lot!
Comment 15 Tomas Zezula 2010-04-28 11:55:21 UTC
Thanks for path.
For java test the sources should not be refactored at all, as the dependency is vice versa (the test roots are de facto a new project depending on sources project). I will fix it, not to refactor the sources for test. The attached patch solves name clashes among source roots of project which is good.

Here are some comments:
1st) project.getLookup().lookup(Sources.class) use ProjectUtils.getSources()
2nd) .lookup(MultipleRootsUnitTestForSourceQueryImplementation.class) never use SPI directly use an API class UnitTestBorSourceQuery.
3rd) Rather than looking to source packages for unit test and test packages for sources it's enough to look into all SOURCES_TYPE_JAVA roots. The same bug happens when you have the same class name in 2 source roots. If you remove the UnitTestForBinaryQuery you will also fix this. :-)
Again, thanks.
Comment 16 Jiri Kovalsky 2010-04-28 12:18:14 UTC
Thanks for your evaluation Tomasi! Joan, are you going to address Tomas' comments?
Comment 17 Quality Engineering 2010-04-30 04:59:03 UTC
Integrated into 'main-golden', will be available in build *201004300200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/
User: 
Log:
Comment 18 lujop 2010-05-04 17:49:29 UTC
Yes I will try that week. Thanks for your comments Tomas.
Comment 19 Jan Becicka 2010-10-06 13:42:33 UTC
It works for me. Probably already fixed.