Why should I call repaint() instead of paint()?
Finlay McWalter repaint() enqueues a paint message onto the system's event queue. Later (in another thread) the AWT system will dequeue this message and dispatch it. One of the (many) things it does is call the paint() or update() method of the component. If you directly call paint() yourself, you'll run in to the following issues:
You lose serial paint processing
By doing painting in any old thread you're calling graphics primitives on the same compoent in one thread while the system event thread is potentially calling on the same component them in another thread.
Thus you run into reentrancy issues in your own code and in AWT, race conditions between your own threads and you greatly increase the probability of lock contention for internal AWT resources, which will be to the detriment of performance. A well-behaved AWT programming does all of its actual painting to real components in response to paint events, inside the system's event handler thread.
You lose paint event elision
The AWT internals contain code that looks for damage/paint events that overlap each other, and tries to glue them together into one big event, which is much more efficient. By circumventing this mechanism you may, in some applications, be unnecessarily repainting the same area of the screen a bunch of times - an AWT that doesn't elide paint events runs much slower in a lot of circumstances.
You lose native notification
By calling repaint() you ensure that the native paint code for the component is called. Just calling paint() yourself stops this from happening - which might cause you problems if you expect the native to be properly painted too.
You're breaking the pattern
From a software-engineering stand-point, you're breaking with the general AWT repaint paradigm. This would be okay if you were gaining some advantage from doing so, but you aren't, so you're unnecessarily making your code less maintainable, harder for others to understand and less reusable.