Technology: January 2004 Archives

Can somebody answer this question for me please: why does this code not work?

interface FooNode {
    public FooNode getSelf();
}

class BarNode {
    public BarNode getSelf() {
        return this;
    }
}

class FooBarNode extends BarNode implements FooNode {
    public FooBarNode getSelf() {
        return this;
    }
}

As far as I can see it should be fine, since FooBarNode is a FooNode and also is a BarNode the compiler should have nothing to complain about. Of course it doesn’t work, and I can see that this is so from the language specification; but the question remains: why?

My complaint is really that this breaks the semantic model completely. What, in essence, is being said by the FooNode.getSelf() interface method is that it returns an object which conforms to the FooNode interface. Given that FooBarNode does conform to this interface it should be fine as a return type from this method.

I assume that there is some deep reason, probably to do with efficiency of the virtual machine, why the language behaves like this; but having seen some of the design decisions to come out of Sun’s Java group I wouldn’t be too surprised if it was just an accidental fuck up.

Fonts in Java look as ugly as sin, we all know this. Now, if you’re writing your own app or have the source code then you can get around this by setting the rendering hints on your JComponents. But if you don’t have the code, or can’t alter it because, for example, it would invalidate a support contract, is there any way of telling swing to use antialiasing on fonts by default? I’m hoping that there is some magic value that I can just add to my swing.properties file and be done with it, but an hour of searching on the net hasn’t found out what it is.