JFrame如何工作？ 在内心深处，它如何绘制东西？

Question

Typically, when I create a class, for example Customer , I give it some data fields, ie public int IdNumber; and some methods, ie 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

If you are curious about how java is implemented you should take a look at the source code. http://openjdk.java.net/projects/jdk7/ would be a start.

Of course this would only give you insight into that particular implementation and doesn't mean that your java is implemented the same way.

Answer 2

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.

Answer 3

How does a box appear on a screen? This functionality is offered by the operating system to the JVM (by the X Window System on Linux).

On the Java level, JFrame inherits from java.awt.Window, which has the "native peers" provided by the native windowing system .

If you really want to understand it, it is better if you try to create some windows using C only.