How does Java – JFrame work? Deep inside, how does it draw things?

Usually, when I create a class, such as customer, I give it some data fields, that is, public int IDnumber; And some methods, namely public string getname() {...} But that's it I can't go beyond it and start playing with graphics - I can only manipulate and organize data, as long as the class allows

I can't understand what happened in JFrame Who wrote the JFrame class and how did they write a class that allows a box to appear on the screen? What happens internally that causes this to happen? Do you want to imitate it anyway?

The same problem applies to all graph - based Java classes I really want to know how it works, because every time I use one of them, it bothers me

Solution

Java started with AWT (Abstract windowing Toolkit) and later introduced swing

In AWT, platform event processing loops are hooked, events are packaged in their own Java classes, and one (non parallel) event processing queue / thread processes them one by one Swing inherited this

In AWT, each GUI component (such as radio button or menu item) has a native code "peer" control, that is, the component provided by the platform There is a set of parallel Java classes and their c counterparts Of particular interest is the java graphics class, which allows custom drawing of lines, rectangles, etc Presumably, it is equivalent to CDC (device context) under windows

In swing, most platform components are simulated, that is, they are recreated by themselves: drawing, mouse processing, etc So the native part is simpler, such as CWnd (window component) with custom drawing

Swing can achieve more consistent and richer functions You can imagine that it may not be possible to set the background color on AWT radio buttons, or use HTML on tags or tooltips Swing can also do skin, theme, lookandfeels The appearance and feel of the system is an approximate imitation of the platform components In particular, swing components are lighter, because not every component has a local peer control that can be processed in C

Now SWT is a later plan implemented by IBM for AWT reload in eclipse It is not customizable like swing, but it is intended to be close to the platform

You should forget to use AWT components. If you don't program for eclipse RCP, you can also use SWT

Therefore, global platform events such as mouse click and redraw request are converted into Java events There is a container hierarchy of JFrame, jpanels, jscrollpanes and jcomponents Dispatch events to processing components, such as calling paintcomponent:

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

With JavaFX, there will be a new player that, with all due respect, is not yet fully mature, but can be used for non production code It can achieve effects / animation, rotation, transformation, light Therefore, 2D - 4D rendering is based on similar platforms It is also attribute based, so the check box is not necessarily bound to a Boolean value, but a Boolean attribute for observing and notifying changes I also need some practical experience to use it to conceive an optimal architecture