Reason for using Class instead of actual type in this java example?

Question

I have seen this "design pattern" (don't know what else to call it.. template?) show up more than once in Java code. Application is expected to be extended and include a main method. I can't figure out what the benefit is of using Class instead of the AppFrame in the start method since it is just type casted to AppFrame anyways. It just all seems so pointless, maybe somebody can fill me in.

public class Application {

 public static class AppPanel extends JPanel {
  //stuff
 }

 public static class AppFrame extends JFrame {
  protected AppPanel mainPanel;
  //more stuff
 }

 public static AppFrame start(Class appFrame) {
  try {

   final AppFrame frame = (AppFrame) appFrame.newInstance();
   java.awt.EventQueue.invokeLater(new Runnable()
            {
                public void run()
                {
                    frame.setVisible(true);
                }
            });
   return frame;
  } catch (Exception e) {
   e.printStackTrace();
   return null;
  }
 }

 public static void main(String[] args){
  Application.start(AppFrame.class);
 }
}

Answer 1

The signature of start() allows passing of any class, but implementation restricts it to the children of AppFrame and the latter is just a nested static class. Since everything is piled into the same file I don't why all of this is necessary and I agree - the way it is implemented in this particular example is pointless.

Answer 2

I've seen that around too, particularly in fairly old examples.

The idea seems to be that everything starts with a single static call, and the user does not create anything on the heap. Instead, the "Application framework" somehow instantiates what it needs and the user only instructs what specific implementations to use. Thus, the user indicates the class to use, but nothing is actually instantiated yet. One risk of doing this is that you could transfer a class whose instances are not convertible to an AppFrame. This can result in an exception.

I personally consider this ugly design. It makes sense in languages where it is more common to directly instantiate a class via a class object like Smalltalk or Python. In Java, I think that sticking with factory interfaces is clunkier yet more OO.

Answer 3

The pattern is called a type token, a term coined by Gilad Bracha and discussed in Class Literals as Runtime-Type Tokens, as well as mentioned here. It is an interesting way to instantiate the top-level container, a JFrame, but the GUI components should be constructed on the Event Dispatch Thread(EDT). Depending on //stuff in the constructors and how start() is called, it may mitigate the effect of an escaped this.