Faking implementation inheritance in Java

I am a lazy programmer, and generate far too many typos. What to do when I want my objects to provide more than one interface and share the implementation amongst themselves? I could write a slew of forwarding methods, but that's sloppy and ugly and blows up the classes. I need mixins but Java doesn't have mixins. (However see here and here.) In C++ I could use implementation inheritance in the standard fashion. But what about Java?

The best I have is forwarding methods:

public interface Interface1 { void dobeedo(); } public class Bob implements Interface1 { private Interface1 mixin1; public Bob(Interface1 mixin1) { this.mixin1 = mixin1; } public void dobeedo() { mixin1.dobeedo(); } }

Sure it works, but do you really want to do this for several large interfaces? Poor Bob gets rather cluttered rather quickly.

(NB — What pattern is this? I can't quite put my finger on it. I don't mean the dependency injection, but the forwarding.)

Closures to the rescue

Simon Willison makes excellent use of closures in JavaScript to insert code for page load without interfering with other scripts trying to do the same thing:

function addLoadEvent(func) { var oldonload = window.onload; if (typeof window.onload != 'function') { window.onload = func; } else { window.onload = function() { oldonload(); func(); } } } addLoadEvent(nameOfSomeFunctionToRunOnPageLoad); addLoadEvent(function() { /* more code to run on page load */ });

This is very excellent.

A beautiful language-theoretic post

Maneability has a beautiful post on recombinant computing (yet another buzzwordy phrase) with a good grounding in the classics. The paper reference gets good style points. Enjoy as pleasure reading.

Clever use of Package

This is a class I wish I'd known about earlier: java.lang.Package. Euxx points out that is has the information you need to describe software's version: title, vendor and version for both software specification and the particular implementation. Yummy.

Propagating web exceptions to the test environment

Rather than use in-container testing such as Cactus, our project elected to run the tests separately and communicate with the web using httpunit and jwebunit. For the most part this has worked well but one lingering issue was that exceptions thrown in the container are hidden from the tests, and only show up as the exception handling page (our "red screen").

But, that is different now. We had passed the web session back and forth (a clever trick from Andrew McCormick using a helper servlet) using standard object serialization, but flattened it to a string on the trip back because of serial id mismatches. Then last night I realized that I could use XML serialization from the JDK (XMLEncoder) to serialize the session without worrying about mismatch issues. Once this worked, it was a small step to see to serialize web exceptions and rethrow them in unit tests. A rather neat solution, I think.

Very excellent NKS lecture

Cluey (if that's his real name, Danil) pointed me to to Wolfram's excellent lecture, A New Kind of Science and the Future of Mathematics. Did you buy his book? I did. Wow, is it heavy. It's one of the few books I have to read in pieces — all in one go and I wind up skimming too much. And the pretty pictures... oh so many pretty pictures. Here's just one, but is it a doosie:

To be 20 again, and a new kind of programmer.