We Keep Coding

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

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.

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.

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.

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.

Java: How to do GUI animations?

In all my time so far working with Java and its Swing GUI framework, I've never quite figured out (or even attempted to try) how to make the interface animate components.
Say I wanted the screen to slide left into the next screen or have a JLabel "fly" to a new location. Perhaps you want a menu to smoothly open in an animated fashion. How does this work?
Do you have to use SwingWorker? Even if that's the case... how can you control the painting of components if the layout manager is already doing that?

Have a look at the book Filthy Rich Clients, you will find some really good answers there.

I think that there no reason for use SwingWorker, SwingWorker is designated for running long Backgroung Task(s) on output would be on Event dispatch Thread,
For animations in Swing is there javax.swing.Timer, examples here

Take a look at Trident library. You can use it to interpolate various properties in your class.

Does anyone have a example of slot machine in Java using swing?

I want to get some examples about the GUI of an slot machine written in java, I know that it's kind of specific thing, but i want to know if it's possible to do some animations with java swing, or something like that, greetings

It isn't a slot machine simulation, but you may find related features in this example.
Addendum: The example cited uses Unicode glyphs for variety, but another trick is to implement the Icon interface, which works nicely with some components. This example decorates a JButton for use in a game, while this example extends a child of JLabel to render a table.

This won't answer your question exactly (because I don't have a direct example), but I hope it at least tells you that it's certainly possible.
I've done some games using Java and Swing and such. None of them have been too heavy on the animations. Most of the animations I did happened through the Java 2D Graphics libraries, while more UI stuff happened through Swing.
For example, you can take all of the functionality of a JButton, but override the paintComponent(Graphics g) method to make it look however you want. This was really useful in past projects for me.
The most graphics-intensive Swing-related game I ever built was a "Who Wants to Be a Millionaire?" game. I used animations and graphics and sounds and everything, so I can assure you that it is possible, but it certainly isn't as easy as some other libraries might be.
If you decide to pursue this, I've found that Swing Hacks has some great tips on doing weird things with Swing. Although it isn't focused on gaming, I've found enough interesting things that you can do (Drag and Drop, a bunch of weird things) to make it a worthwhile purchase.

Custom Swing component: questions on approach

I'm trying to build a new java swing component, I realise that I might be able to find one that does what I need on the web, but this is partly an exercise for me to learn ow to do this.
I want to build a swing component that represents a Gantt chart. it would be good (though not essential for people to be able to interact with it (e.g slide the the tasks around to adjust timings)
it feels like the best approach for this is to subclass JComponent, and override PaintComponent() to 'draw a picture' of what the chart should look like, as opposed to doing something like trying to jam everything into a custom JTable.
I've read a couple of books on the subject, and also looked at a few examples (most notably things like JXGraph) - but I'm curious about a few things
When do I have to switch to using UI delegates, and when can I stick to just fiddling around in paintcomponent() to render what I want?
if I want other swing components as sub-elements of my component (e.g I wanted a text box on my gantt chart)
can I no longer use paintComponent()?
can I arbitrarily position them within my Gantt chart, or do I have to use a normal swing layout manager
many thanks in advance.
-Ace

I think that the article i wrote a few years ago for java.net is still correct today. Doing everything in one monolithic class gets you going faster in the beginning, but becomes a mess quite fast. I highly recommend doing the separation between the model (in your main class) and the view (UI delegate). The view is responsible for:
interaction with the user - mouse, keyboard etc.
painting
creating "worker" subcomponents as necessary
In the medium and long run this is the approach that has been validated over and over again in the Flamingo component suite, which you can use as an extra reference point (in addition to how core Swing components are implemented).

Using UI delegates is a good idea if you think that your component should look different for different Look And Feels. Also it is generally a good idea from design point of view to separate you presentation from your component
Even when overrding paintComponent you can still put any sub components on it.
Using null layout you arbitrarey position your components. Alternatively you can use layouts too.
Here is a very good starting point for you.

How are Swing components internally created, laid out, repainted, notified of events, ...?

I wonder if there's a good documentation (or a (viewable) ebook) about
the lifecycle of Swing components.
Is "lifecycle" the correct term, anyway?
I hope to find answers to question such as:
How, when, in which order painting methods are called?
How, when, which events are called by whom?
What is the exact sequence of method calls for component creation?
From time to time I encounter strange behavior of my apps, for example:
ComponentListener's resize event is called before setVisible(true)
(so that root pane has negative dimensions!)
Some components are laid out correctly only after resizing the JFrame by hand
Changing a super class from JPanel to JLayeredPane causes my class
to be laid out differently inside an other container.
And lot of other strange things...

I had the same question long ago.
I can't believe how hard is to find a good resource about this topic in the internet.
Fortunately I've found this link and now I have it in my bookmark with golden tag. :)
A Swing Architecture Overview
Once you have a good grasp of how they work conceptually you will be able to fix most of the problems you mention.
I hope it helps.