... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)

2006-11-02

Subtleties of Java Static Imports

I had a Java class that has a static import for org.junit.Assert.assertEquals which imports a number of signatures including one with arguments String, double, double, double.  I also defined in that class a static method named assertEquals with the argument signature String, double[], double[], double that invoked the JUnit assertEquals.  Under Eclipse 3.2.0, the compiler accepted this code and it worked the intuitive way.  Under Eclipse 3.2.1, the compiler misidentified my call to the double[] version of assertEquals as if I were trying to call the double version, and issued an error message complaining about the type mismatch.

I wondered which behaviour was correct, the 3.2.0 or 3.2.1 version.  I checked the Java Language Specification and it is silent on the subject.  Reading between the lines, however, it would seem that neither the 3.2.0 nor the 3.2.1 behaviour is correct (although 3.2.1 is almost right).  The spec does say that if you statically import a type and also define a type with the same name in the class, a compiler error is issued.  If I extrapolate that rule to include imported members, then the 3.2.1 behaviour is correct, although I would argue that the error message that it gives is misleading or even wrong.  It should give an error message along the lines of "the statically imported method name 'x' conflicts with the definition of 'x' in the class".

Blog Archive