Eclipse, JUnit and an odd networking issue

My coworker started having issues with getting JUnit to do anything in Eclipse. After some digging around, it was discovered that, for whatever reason, the JUnit runner was trying to create a network connection and couldn’t. He tried to perform an update of Eclipse plugins and that failed also, for the same network connectivity reasons.

After a lot of digging and much gnashing of teeth, he came across this page which outlines an issue where Java has started connecting using IPv6. We’re not sure if this is a Debian package issue or something from elsewhere but thankfully the LiveJournal page outlines a couple of fixes. The fix performed at the system level rather than by Java properties is what fixed things for him.

To check the system property, do this:

machine:/# sysctl net.ipv6.bindv6only

Which, if you’re having this problem should return 1. If you’re having this problem and get a return value of 1, issue this command next:

machine:/# sysctl net.ipv6.bindv6only=0
Advertisements

EasyMock’s “N matches expected, M recorded” not always what you expect

This has been discussed in varying ways. I tend to point to this article as a good description of how to understand what is going on when this message is given. There is an interesting corner case that I feel needs to be explored as I’ve just wasted an hour trying to figure it out.

Consider the following code sample.

public void testSomethingBasic() {
  Thing myThing = new Thing(EasyMock.isA(Whatever.class));
  // do more stuff in the test
}
public void testSomethingElse() {
  IJobber myJobber = EasyMock.createMock(IJobber.class);
  EasyMock.expect(myJobber.doStuff()).andReturn(null);
  // do more stuff in the test
}

The thing to notice is that isA(..) was used on a non-mock object then used again on a mock object. The problem here is that EasyMock will record that you created a matcher (ie. isA(Whatever.class)) that was never used then will record that you created another one that you did use. You’ll get an error to the nature of “1 matcher expected, 2 recorded”.

While this is not always the case, a debugging method to consider is when you have more recorded than expected, check test methods that run before the one throwing this exception to make sure you aren’t improperly creating matchers that don’t get used.

Clicking Things

For a month or so now, I’ve been having problems with clicking buttons in Eclipse and in Flash. After asking in the Eclipse IRC room, I was able to find an answer that actually fixes both Eclipse and Flash.

Eclipse (from the wiki)
I’ve created a startup script that sets the following system property.

export GDK_NATIVE_WINDOWS=true

Flash (from this post)
Pretty much the same fix as above but made in a different place. In /usr/lib/nspluginwrapper/i386/linux/npviewer, add the following:

export GDK_NATIVE_WINDOWS=1

before the line:

. /usr/lib/nspluginwrapper/noarch/npviewer

A note to all this. Don’t put either of these properties in .profile, .bashrc or anything like that. This property needs to be set specific to things that break as this changes how GTK+ processes events.