import static does not work when the class has methods with the same name as the imported ones

I have a Junit4 test case which statically imports the org.junit.Assert.assertEquals method(s).

import static org.junit.Assert.assertEquals;

In this class I have created a utility method for asserting some complex internal classes which do not implement equals (and also have a hard time implementing it).

private void assertEquals(MyObj o1, MyObj o2)
{
    assertEquals(o1.getSomething(), o2.getSomethi开发者_开发知识库ng());
    assertEquals(o1.getSomethingElse(), o2.getSomethingElse());
    ...
}

I expected the code to behave as if I am "overloading" the assertEquals method(s) that I'm importing, but it looks like my private non-static method is hiding the statically imported methods. I also tried turning my method to be public and static (all permutations) but with no success - I had to rename it.

Any reason why it behaves this way? I couldn't find any reference to this behavior in the documentation.

What you observed is calling Shadowing. When two types in java have the same simple name, one of them will shadow the other. the shadowed type then can't be used by it's simple name.

The most common type of shadowing is a parameter to hide a field. usually result in setter code to look like setMyInt(int myInt) {this.myInt = myInt; }

Now let's read the relevant documentation:

A static-import-on-demand declaration never causes any other declaration to be shadowed.

This indicate a static import on demand always comes last, so any type with the same simple name as a import on demand declaration will always shadow (hide) the static import.

Overloading and overwriteing works in an inheritance tree. But a static import doesn't build a inheritance.

If you want to use the assertEquals of junit in your own assertEquals method you must qualify it with the className e.g. Assert.assertEquals.

Use a nonstatic import of org.junit.Assert.

You have stumbled onto method hiding, where the presence of a local method "hides" one from another class (often a super class).

I have always felt that statically importing methods is, while syntactically possible, somehow "wrong".

As a style, I prefer to import the class and use TheirClass.method() in my code. Doing so makes it clear that the method is not a local method, and one of the hallmarks of good code is clarity.

I recommend you import org.junit.Assert and use Assert.assertEquals(...).

This makes sense. Suppose javac does what you want, it picks your assertEquals(MyObj, MyObj) method today. What if tomorrow org.junit.Assert adds its own assertEquals(MyObj, MyObj) method? The meaning of invocation assertEquals(mo1,mo2) changed dramatically without you knowing it.

At question is the meaning of the name assertEquals. Javac needs to decide that this is a name of method(s) in org.junit.Assert. Only after that, it can do method overloading resolution: examine all methods in org.junit.Assert with the name assertEquals, pick the most appropriate one.

It's conceivable that java could handle method overloading from multiple classes, however as the first paragraph shows, it causes great uncertainty to developer of which class the method he is calling. Because these classes are unrelated, method semantics can differ greatly.

If at compile time, it's without any doubt to developr which class the method belongs to, it is still possible that the class will overload the method tomorrow therefore changing the target method invoked. However, because that is done by the same class, we can hold it responsible. For example, if org.junit.Assert decides to add a new assertEquals(MyObj, MyObj) method, it must be aware that some previous invocations of assertEquals(Object,Object) are now rerouted to the new method, and it must make sure that there's no semantics change that will break the call sites.