Question

I was wondering if there is a way for extending Font class in a manner that I could return my own Font class by createFont and deriveFont methods. I mean something like this…

public class MyFont extends Font {

    // Constructor
    public MyFont (...) {
        super(...);
    }

    // createFont method
    public static MyFont createFont (...) {
        // body
    }

    // deriveFont method
    public static MyFont deriveFont (...) {
        // body
    }
}

I’ve tryied but I could not retrieve any font, and when doing it the font I got was the default one (I mean “Dialog”).

The reason for doing is is to minimize the impact produced by an eventual change in later Java distributions of its VM.

This is the code summoned above:

MyFont onePoint=MyFont.createFont(MyFont.TRUETYPE_FONT,fontStream, size); 

Then in MyFont, I coded:

public static MyFont createFont (int i, InputStream io, int size) throws FontFormatException, IOException { 
    Font font = Font.createFont(i, io); 
    MyFont kfont = new
        MyFont(font.getName(),font.getStyle(),font.getSize()); 
    return kfont;
}

Answer 1

0th. What if someone wants to pass generic Font to your code, and you require argument being instance of MyFont. Does it make any practical sense? You try to use inheritance to adjust some lifecycle protocols (object creation in this case) which does not fit well into Java OO-paradigm. Use a factory method/prototype instead.

1st. createFont() is not overridable as it’s static. You may provide your own version in your class, but using the same method name may confuse other users of your code (and, later on, you too).

2nd. while providing some shortcuts to createFont() and possible new versions of deriveFont() you don’t avoid linking against the API you want to control changes of, so you’d have to recode/recompile anyway, given java implementations change. Proper dependency avoidance involves some reflection and String-coded class names with catching lots of ClassNotFound exceptions and other whatnot which may happen on an API change. You don’t want that. Period.

3rd. just relax, really, this code is quite stable and chances your app gets outdated and rewritten from scratch are much greater than anyone even deprecates those methods, leave alone removing them. this is well beyond the end of world in 2012 (or any other more or less relevant date closer than heat death of the universe).

To wrap it up, just add couple of easily distinguishable static shortcuts: MyFonts.create() chained to the Font.creatFont(), and another MyFonts.derive(Font font, otherargs) chained to font.derive(otherArgs). Keep it simple, dude, and seal the MyFonts() constructor, to indicate this is a factory/utility class.