How does JFrame work? Deep inside, how does it draw stuff?

Question

Typically, when I create a class, for example Customer, I give it some data fields, i.e. public int IdNumber; and some methods, i.e. public String getName(){...}. But that's pretty much it. I can't go beyond that and start playing with graphics - I can only manipulate and organize data as far as the class allows.

I can't get my head around what is happening inside JFrame. Whoever wrote the class JFrame, how did they write a class that can make a box appear on screen? What is happening internally that causes this to happen? Is there anyway to emulate it?

The same question applies to all graphics-based Java classes. I'm really curious to know how it works, as it bothers me each time I use one of them.

Answer 1

Java started with awt (Abstract Windowing Toolkit) and later introduced swing.

In AWT the platform event handling loop is hooked into, and events are packed in own java classes and one single (non-parallel) event handling queue/thread handles them, one after another. Swing inherits this.

In AWT every GUI component, like radio button or menu item, has a native code "peer" control, the platform provided component. There is a parallel set of java classes and their C counterpart. Especially interesting is the java Graphics class which allows custom drawing of lines, rectangles and such. It is peered under Windows with a CDC (Device Context) - presumably.

In Swing most of the platform components are emulated, that is, recreated oneself: the drawing, the mouse handling, and so on. So the native part is simpler, say maybe a CWnd (Window component) with custom drawing.

Swing can achieve a more consistent and more feature rich functionality. You can imagine that setting a backgroud color on an AWT radio button might not be possible, or using HTML on a label or tool tip. Also Swing can do skinning, themes, LookAndFeels. The System look and feel being a close imitation of the platform components. Especially Swing components are more light weight, as not every component has a native peer control to be handled in C.

Now SWT was a later initiative of IBM realized in eclipse for AWT reloaded. Not as customizable as Swing but intended to be platform near.

You should forget using AWT components, and if not programming for eclipse RCP also SWT.

So: global platform events like mouse click, repaint request are translated to Java events. There is a container hierarchy of JFrame, JPanels, JScrollPanes, JComponents. An event is dispatched to the handling components, on which for example paintComponent is called:

@Override
public void paintComponent(Graphics g) {
    Graphics2D g2 = (Graphics2D) g; // A later introduced class that can do more.
    g2.draw...
}

With JavaFX there comes a new player, which is IMHO not yet fully mature, but usable in non-production code. It enables effects/animations, rotations, transformations, light. So a 2D - 4D rendering, based on like platform rendering. Also it is property based, so a check box would not necessarily be bound to a boolean, but a boolean property observing and notifying changes. I need still some practical experience, to conceive an optimal architecture with it.