Best Practices

This is the final lesson of the Java Applet track. Rather than introducing new API surface, it pulls together a checklist of practices for writing correct, safe applet code - and, just as importantly, for knowing when this knowledge should stay educational rather than something you reach for on a real project.

1. Know When Not to Use This

The single most important "best practice" in this entire track is recognizing that applets are legacy, removed technology - covered in full in Why Applets Are Deprecated, and What to Use Instead. Nothing here should ship in a real product today. Treat this track as historical/educational/curriculum value: understanding the AWT event model that Swing (and indirectly Android) inherited, recognizing applet code if you meet it in a legacy codebase, or covering material that still appears in some college syllabi and certification exams.

2. Test with the Right Tools, Every Time

Always test applet code with a JDK 8 install and the classic appletviewer tool, as set up in Environment Setup. Never assume a modern JDK or a modern browser can run applet code - modern JDKs have removed the API outright, and no browser has run applets since the NPAPI plugin removal around 2015-2016, independent of the JDK's own timeline.

3. In Swing, Paint via paintComponent(), Not paint()

For any JApplet/Swing work, always draw by overriding paintComponent(Graphics g) on a JPanel - calling super.paintComponent(g) first - rather than overriding paint() directly on the JApplet itself, as covered in JApplet and Swing:

class DrawingPanel extends JPanel {
    protected void paintComponent(Graphics g) {
        super.paintComponent(g);  // keep Swing's own background/border painting
        // ...custom drawing here...
    }
}

Skipping super.paintComponent(g), or overriding paint() on the top-level Swing container instead, breaks Swing's own double-buffering and background/border painting in ways that are easy to get visibly wrong.

4. Keep paint()/paintComponent() Fast

Painting methods can be triggered very frequently - on resize, on window focus changes, during animation loops like the one in Threads and Simple Animation, and by the windowing system for reasons that have nothing to do with your code. Do heavy computation elsewhere (in init(), in a background thread, or ahead of time) and cache the result; paint()/paintComponent() should do as little work as possible beyond drawing already-prepared data.

5. Release Resources in stop()/destroy()

Anything an applet starts, it should clean up. Stop background threads by flipping a volatile boolean running flag to false inside stop() - never with the removed, unsafe Thread.stop() - and call stop() on any looping AudioClip so it doesn't keep playing after the applet is no longer visible.

6. Prefer *Adapter Classes Over Full Interfaces

When you only need one or two methods from a listener interface, use the matching *Adapter class (MouseAdapter, KeyAdapter, MouseMotionAdapter, and so on) instead of implementing the full interface and stubbing out every unused method. This track used exactly that pattern throughout - MouseMotionAdapter in Handling Mouse Events, KeyAdapter in Handling Keyboard Events, and MouseAdapter again in Playing Audio in an Applet.

7. Build Anything You'll Actually Ship With Modern Tools

For a desktop GUI you intend to ship today, use Swing or JavaFX. For interactive content in a browser, use plain JavaScript/WebAssembly. Full detail, including the honest caveats and niche exceptions, is in Why Applets Are Deprecated, and What to Use Instead.