More Complex Applet

This particular applet just displays what the servlet sends. A fancier one might do something different with it.
For example, the servlet might send a number, and the applet might use that to decide what color to draw something in.
Or two numbers might be an x and y co-ordinate. We just dump the string into a label, but the only limit to the ways that applets and servlets can work together is your imagination.

When a Java applet is embedded in a web page, a browser can download it and execute it automatically. If you think about it, that is a very dangerous thing to do. So, to protect the client, JDK 1.0 assumed all applets were untrusted and ran them under the watch of a SecurityManager that severely limited what they could do.
For example, the security manager made sure applets couldn’t write to the user’s file system, read certain system properties, accept incoming socket connections, or establish outgoing socket connections to any host but the origin server. This protected the client, but it limited the usefulness of applets.
Consequently, JDK 1.1 introduced the concept of trusted applets, applets that can operate like normal applications with full access to the client machine. For an applet to be trusted, it has to be digitally signed by a person or company the client trusts (as marked in the client’s browser). The signature authenticates the applet's origin and guarantees integrity during the transfer, so the client knows the applet code has not been surreptitiously changed. This allowed for more productive applets, but it was an all-or-nothing approach.
To give the client more control, JDK 1.2 is introducing a fine-grained access control system. Under this new system, a digitally signed applet can be partially trusted, given certain abilities without being given free reign on the system. This promises to allow applets from unknown sources to be granted small privileges (such as writing to a single directory), without granting them the ability to wipe the client’s hard drive.