Just to be clear, this is a documentation bug in the JLS, not a bug in the language. Check out this example from Section 4.11 of the Java Language Specification:

void <S> loop(S s) {
  this.<S>loop(s);
}

That won’t compile for me. I have to put the <S> before the void, like this:

<S> void loop(S s) {
  this.<S>loop(s);
}

Simplify the Code

Now that the bug is fixed, IDEA warns that the second <S> is not required. “this.” is also extra noise, so you could simplify the recursive loop to this:

<S> void loop(S s) {
  loop(s);
}

Although I think they may have wanted the explicit <S> in there just to show the syntax.

Good luck running this example.

See my next post for the reason why I ran across this little gem…

Drawing stick figure comics may seem like a pathetic cry for help…a desperate plea for MORE LINKS…but the Code To Joy team has taken the art of link groveling to a new level.

For those “on the inside”, Mike has better pictures…far better pictures…deemed inappropriate for the workplace.

Mike: post those pictures!

UPDATE: Oops, I corrected the link to Mike’s blog.

I just added “thought bubble” graphics to my blog comments. Scroll down to see the results.

Check out Comic: Wide-Stanced Programming for another post with a handful of comments.

I have no idea if this works in your browser. I tested on Vista using IE 7 and Firefox 2.0.0.9. It’d be great if people on other operating systems and browsers could let me know how the bubbles render.

Consider this EventSubscriber interface:

public interface EventSubscriber<T> {
  void onEvent(T event);
}

To subscribe to a single event type, you write something like this:

public class MyBean implements EventSubscriber<String> {
  public void onEvent(String event) {
    // handle String events
  }
}

I then decided I wanted to subscribe to multiple events. I foolishly tried this:

public class MyBean implements EventSubscriber<String>,
      EventSubscriber<StatusEvent> {
  public void onEvent(String event) {
    // handle String events
  }

  public void onEvent(StatusEvent event) {
    // handle status events
  }
}

Oops. Won’t compile.

IDEA says:

Duplicate class: ‘com.stuffthathappens.classbus.EventSubscriber’

javac says:

Error:(33,8): com.stuffthathappens.classbus.EventSubscriber cannot be inherited with different arguments: <com.stuffthathappens.demo.StatusEvent> and <java.lang.String>

Section 8.1.5 of the Java Language Specification says this:

A compile-time error occurs if the same interface is mentioned as a direct superinterface two or more times in a single implements clause names.

Hmm…that sounds really close, but not quite. The end of section 8.1.5 contains the answer:

A class may not at the same time be a subtype of two interface types which are different invocations of the same generic interface (§9.1.2), or an invocation of a generic interface and a raw type naming that same generic interface.

Discussion

Here is an example of an illegal multiple inheritance of an interface:

class B implements I<Integer>
class C extends B implements I<String>

This requirement was introduced in order to support translation by type erasure (§4.6).

Foiled by erasure!

Is erasing erasure still on the table for Java 7? I’m no compiler expert…would reification allow me to do what I tried to do above?

I received a very helpful (and FAST) response from the reCAPTCHA team earlier today:

Basically, when you get a reCAPTCHA incorrect on wordpress, the comment is saved but it is marked as spam. When a legitimate user gets the CAPTCHA incorrect, they are redirected to a page that saves their comment and allows them to correct the CAPTCHA. Once we recover the comment, it’s deleted from the database. However, if a spam bot enters the comment, it will not follow the redirect, so sometimes the comment stays in the DB.

Basically, when using reCAPTCHA, any comment you see in the moderation queue was caught by reCAPTCHA — it doesn’t mean that the CAPTCHA is broken.

The only thing I’ll add to this is my observation that WordPress does not always make it clear which “comments” come from the comment form versus trackbacks and pingbacks. So “any comment you see in the moderation queue” MIGHT have come via reCAPTCHA, but it might also have originated via trackbacks. Read on…

Following Their Advice

Today I turned off email notification for the moderation queue, as the reCAPTCHA FAQ suggests. But this has a side-effect…I also had this option selected in WordPress: “Comment author must have a previously approved comment”.

Damn. This means I’ll no longer see email notifications for those legitimate human comments. So…I went ahead and turned off that, as well.

Trackback Vulnerability

After changing these settings, I very quickly saw a spam comment make it onto my blog, because (I think) the “Comment author must have a previously approved comment” checkbox is now unselected. I missed my opportunity to moderate the comment (which is actually a trackback), so it went on through.

AFTER the spam makes it through the system, WordPress sends an Email notification. Part of this email contains this phrase:

You can see all trackbacks on this post here:

Aha! Now I know this came from a trackback, not from a normal comment.

I now believe most of the comment spam I’ve been seeing in recent weeks has originated from trackbacks, it’s just that WordPress does not always make it easy to tell if the comments are coming from trackbacks or the comment form. reCAPTCHA does a very good job with the comment form, but does not address trackback or pingback spam in any way.

Closing Thoughts

I really, really like reCAPTCHA. It is very effective and the people on their team are always helpful and promptly answer questions. Having reCAPTCHA in place saves me significant time. It’s also damn cool that they are harnessing people power to digitize books. Watching Luis von Ahn’s Google Tech Talk was the reason I tried reCAPTCHA in the first place. It is an incredibly clever idea that any geek can appreciate.

I used Akismet in the past, and wading through thousands of spams in the Akismet queue grew very burdensome. Furthermore, it occasionally marked valid comments as spam — definitely more often than once every 6 months — so I never felt comfortable ignoring the spams.

Maybe WordPress needs to improve its moderation queue? Some ideas:

• Offer separate moderation queues for comments, trackbacks, and pingbacks.
• Let me configure different moderation policies for these different queues.
• At all stages, make it very obvious if a comment originated from the comment form, a trackback, or a pingback.

Trackbacks and pingbacks are now off. Comments — from people — are open and encouraged. Spammers, you suck.

For awhile, reCAPTCHA solved my WordPress spam problem. Then I started seeing a handful of spams, now I receive at least 5 per day in my moderation queue. I first blogged about this a bit over a month ago.

Here is a typical email I receive from my WordPress moderation queue:

Here is what the WordPress moderation queue looks like:

Is this from a trackback or did a human enter this comment? How can I tell the difference between comments and trackbacks?

What should I do next to fight spam on this blog? Disable trackbacks? Install some sort of trackback SPAM fighting plugin? Help!

These posts from Dale are painful to read:

Part 1 - An out-of-box experience, where we learn that Leopard is *not* installed on new Macs. WTF?

Part 2 - Look, it’s a Tiger; no, it’s a paperweight; NO….., where we learn Macs have the “Blue Screen of Frustration” instead of the “Blue Screen of Death”.

Ouch.

Some classes are incredibly easy to test:

public class Name {
  private final String first;
  private final String last;

  public Name(String first, String last) {
    this.first = first;
    this.last = last;
  }

  public String getFirst() { return first; }
  public String getLast() { return last; }
}

Should we write unit tests for these simple classes? Kevin “pottymouth” Bourrillion brings this up as well:

If we write tests for these idiotic classes, we’re wasting time; if we don’t write tests for these idiotic classes, we find out later that they’re buggy because, say, we forgot to use a null-safe equality check for a nullable field, or something.

So what do you do? Do you test trivial code?

The Testing Suite Spot

Let’s look at an advanced diagram showing code complexity:

Some code feels too trivial to test, so we don’t test all of those getters and setters. Other code is awful legacy crap that is damn near impossible to test. The tests become so convoluted, time-consuming, and hacky that we don’t bother.

Random Observations

• If you wait until code gets really complex before writing that first test, it is generally too late. It is damn hard to retrofit existing code with good tests.
• Most code starts out pretty simple. You may feel like you are wasting time testing this trivial code, but complexity sneaks up on you.
• Writing that first stupid trivial test helps ensure you lay a foundation for ongoing testing. Are your build scripts up-to-snuff? Does you continuous integration build run the tests? Do you publish test results? Putting these features in place on day 1 is easy, when the code is “too trivial to test”. Procrastination makes all of these things much harder.
• Testing as you go helps avoid complexity in the first place. People who never write tests do not grasp this concept.

I believe the last bullet is the most important. Code that is “too hard to test” is often that way because you did not write tests as the code evolved rotted.

Should We Test Trivial Code?

Back to the original question. Should we write tests for trivial code? I don’t see much harm in writing a handful of trivial tests for each class. I see far more harm in writing too few tests. Even if classes never evolve beyond simple POJOs with a few getters and setters, writing trivial tests wastes very little time. If the code happens to grow and require new features, having those first few tests gives you a better starting point.

As a learning exercise, writing tests for trivial classes is the first step towards understanding how to write tests for the really hard stuff. The stuff that really needs testing.