PHP 1, Java 0: The method assertEquals(Object, Object) is ambiguous for the type

October 21, 2009

Th old Ashley would never say this, maybe I’ve been working with PHP too long, but seriously, I’m going to have to side with the dynamic language crowd on this one – I think I have been spending too much time developing with Magento!

After an Eclipse upgrade a whole raft of my unit tests started failing to compile with the error: The method assertEquals(Object, Object) is ambiguous for the type. What this means is I’m passing an int and and Integer into a method that has two different signatures: assertEquals(Object, Object) and assertEquals(int, int) both of which could be called, thanks to autoboxing.

I’m hardly doing a lot of Java coding these days, and relish the chance to get stuck in to a little (truthfully, I still feel like PHP coding is ‘hacking’ compared to a good session on Java). But here I am confessing that I honestly cannot be f’ed fixing these errors – I mean seriously, int, and Integer, autoboxing it’s all more work for no gain in this case.

And before anyone responds to tell me that there is a perfectly good reason we have primitives and Objects in Java, and that autoboxing is a great solution to deal with converting between the two. Or that allowing polymorphism through method overloading is a powerful OO tool in Java, I know all of that, I understand it, I just do not want to have to change this:

assertEquals(-11.70, orderItem.getCommission());

into this, 88 times:

assertEquals(new Double(-11.70), orderItem.getCommission());

I hate to moan about a language feature and then not suggest something constructive. How about a version of Java called ‘slow Java‘, where there are no primitives and everything is really an object (some smart ass will tell me it’s called Eiffel right?). If someone clever writes a static analysis tool that will then optimize away the unnecessary new() calls (like where I have an object int that doesn’t need to be on the heap), then It’ll be slower sure, but maybe not impossibly slow? When you can rent cores for 10c an hour, does it really matter anymore? Would slow Java really get spanked in real-world applications? (like my unit tests)

</rant>

Ashley

Posts

Hi! I'm Ashley Schroder, a Software Engineer from New Zealand - this is a collection of notes on my experiences with Ecommerce Web Development, particularly Magento Development.

Are Your Customers Getting The Magento Emails You Send?

MageSend Magento Email sending with Amazon SES

I have made a premium Magento Extension called MageSend. MageSend makes it simple and easy to send using Amazon's highly reliable SES email service.

The extension is $99, and comes with a complete money back guarantee, please check it out, I am confident it will resolve any email sending problems with your Magento store.

5 responses to PHP 1, Java 0: The method assertEquals(Object, Object) is ambiguous for the type

  1. using assertEquals for doubles is deprecated. You should use a delta/tolerance

    If you use assertEquals(double, double, 0.0), the autoboxing ambiguity will take go away as a side benefit.

    int/Integer might still be an issue of course…

  2. Thanks Greg, good point re: doubles.

  3. The all-object Java with invisible autoboxing already exists: It’s called Scala. It fixes a number of Java’s annoyances concerning types.

  4. I’d like to know: Why did an upgrade of Eclipse suddenly start producing these errors? An upgrade of junit or Java 1.4 > 1.5 I might understand but I don’t see how this could possibly be an Eclipse issue…?

  5. Good point Alex, thanks for contributing – perhaps the upgrade changed the default junit or java version for the project. In any case, the actual cause was less important than my little whinge about the autoboxing ambiguity and how it doesn’t (or shouldn’t) really matter which method gets called in this case.