[Bluej-discuss] Compiler barfs when imported class not specifically named in method call

[Michael Kölling]

On 25 Oct 2007, at 08:37, Hedley Finger wrote:

> After installing junit-addons.jar into the BlueJ IDE and adding it to
> the list of libraries, I was able to do this:
>
>          import junitx.framework.AssertArray;
>          import junit.framework.Assert;
>
> but calling
>
>          assertEquals(double[], double[], double);
>
> causes a compiler error but not with
>
>          AssertArray.assertEquals(double[], double[], double);

It seems that the way these methods are provided in the junitx  
library is different from the junit library.

In JUnit, the way you get access to the assert methods is by  
inheritance: you inherit from junit.framework.TestCase, and then you  
have methods such as 'assertEquals' available as instance methods by  
inheritance.

That does not work so easily with the junitx framework, because you  
cannot inherit from two classes at the same time (not entirely true,  
see below).

So they, it seems, came up with a different way to make their methods  
available: they made them all static, and you can call them via the  
class (as you did there).

If you don't like the syntax, there are two possible solutions: one  
that the junitx developers could have used, and one you can do.

The first goes back to being able to inherit from two classes: You  
can, in fact, inherit from two classes if they themselves are chained  
in an inheritance hierarchy (that is, you inherit your superclass and  
your super-superclass). So the junix developers could have made their  
own class a subclass of JUnit's TestCase, and then you can inherit  
from their class and get the lot. Don't know why they didn't do it.

The thing you can do, if it bothers you, is to use a static import  
for the methods (if you use Java 5 or newer). (Google "static import"  
for details.) I'm not a great fan of static import, because I think  
it makes the code harder to read (less clear where method definitions  
are) for the benefit of typing a bit less (writer's convenience at  
the expense of readability). But it's there.

Michael