Event Handling In Java Applet

[Rosella Bowlan]

Ihave an applet which opens a JFrame and I am using a KeyListener to listen for keyboard input. This works fine in my development environment (eclipse), but when I run the applet through a browser (I have tried Firefox and IE) it does not respond to keyboard events.However, if I run the applet and then minimize and maximize the frame, it works.I have tried setting focus to the JFrame in many different ways and also programmatically minimizing and maximizing it, but to no effect.I have also tried key bindings, but with the same problem.

I solved the problem. If I create the JFrame following a button press or mouse event on the applet, the key listener on the JFrame works. Apparently, creating the frame from Applet.init() means that key listeners do not function correctly when opened through a browser.

I think you are running into the plugin focus issue: in many modern browser a plugin only gains focus through either the user clicking on it or using Javascript. This typically affects Flash but it might be that it also affects applets. Try Adobe's recommendations at _15586.html.

Event handling in applets is the process of writing code to respond to different types of events that may occur within the applet. Events are generated when the user interacts with the applet by clicking on buttons, typing in text fields, or performing other actions.

In this example, we create a simple applet that contains a button and a label. We then register an ActionListener with the button using the addActionListener() method. When the button is clicked, the actionPerformed() method of the ActionListener interface is called, which sets the text of the label to "Button clicked!".

Mouse events: You can use the MouseListener and MouseMotionListener interfaces to handle mouse events in your applet. For example, the following code changes the color of a rectangle when the mouse is clicked on it:

Java Plug-in technology (hereafter the "Java Plug-in"), which is included in the Java Runtime Environment (JRE), enables Java applets to run in web browsers on the desktop. The Java Plug-in provides powerful capabilities to applets in the web browser, while improving the overall reliability and functionality of applets in a backward-compatible manner.

The Java Plug-in runs one or more Java virtual machine instances (JVMs) that connect back to the browser for full interoperability with the surrounding web page. This architectural change offers many advantages and features:

The JVM running the applet is isolated from the web browser at the operating system level. If something should go wrong while running the applet, or if an uncooperative applet refuses to shut down, the Java Plug-in detects and handles the error condition gracefully; the web browser is unaffected.

The Java Plug-in offers the capability to launch applets directly from JNLP files, unifying deployment of Java content both in the browser and out of the browser (via Java Web Start). Developers can reuse JNLP extensions for advanced functionality. Applets can access JNLP APIs for persistent data storage, local file system access, and other useful functionality from sandboxed code.

The bridge between the JavaScript engine in the web browser and the Java programming language is backward-compatible and features reliability, performance, and cross-browser portability for both Java applets calling JavaScript code as well as JavaScript code calling Java applets.

JVM command-line arguments may be specified in the HTML of the web page on a per-applet basis, providing fine-grained control over options such as the heap size and Java 2D hardware acceleration features.

With the Java Plug-in, applets are not run in the JVM inside the browser. Instead, they are executed in a separate process. The same JVM process can be shared between multiple applets, or applets can be placed into different processes depending on whether the existing JVMs match the applet requirements and have enough resources to execute the applet. An applet can request a specific version of the JRE to be used and can specify what options to pass to the JVM. An applet can also request to be executed in the separate JVM.

The browser and the applet can still communicate with one another, however. Existing APIs have been re-engineered to use process sockets, so everything continues to work as it did before, only better. This architecture provides a number of benefits:

If two applets each require a large amount of memory, they might both run in the same JRE, causing one of them to run out of memory. But that's only a concern when you have multiple applets running simultaneously.

On Windows platforms, both the Java Control Panel and the Java Plug-in automatically detect the installed JREs and add them to the available set. On Solaris, Linux, and OS X platforms, auto-detection of installed JREs is not supported. The Java Runtime Environment Settings dialog, which is accessed by clicking View in the Java tab of the Java Control Panel, can be used to manually add JREs to the known list for the Java Plug-in.

The list of available JREs is consulted. If there is an exact match of the version string, that JRE version is selected. Otherwise, if there are one or more installed JREs in the same family, the latest version is selected. Otherwise, the latest available JRE on the machine is selected.

The selected JRE version is compared against the security baseline for the family. (See Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer for more information.) If it is equal to or more recent than that version, no further prompting is done and the applet is launched.

Otherwise, the code for the applet is downloaded in a JVM instance of the selected JRE version. If the applet is signed and the user accepts the security dialog for the applet (or the code source has already been trusted), no further prompting is done and the applet is launched.

Otherwise, we are dealing with an unsigned applet on an "older" JRE version. A dialog box is presented indicating that this applet is requesting to run on top of an older JRE release, and asks the user whether he or she wants to allow it to. If the user clicks "yes", the applet is launched. If the user clicks "no", the applet is re-launched on top of the latest available JRE version.

A web browser's JavaScript interpreter engine is single thread. The Java Plug-in is capable of managing multiple threads. The Java Plug-in creates a separate worker thread for every applet. Applets themselves may be multi-threaded. Applets making JavaScript to Java calls and vice versa should be designed with the thread related issues in mind.

When a thread is executing a Java to JavaScript call, another thread wanting to do the same will be blocked till the first thread has received its result and is done (JavaScript Interpreter Busy scenario)

In order to avoid thread related issues especially when multiple applets are running simultaneously, keep both Java to JavaScript and JavaScript to Java calls short and avoid round trips, if possible.

Normally, if two applets have the same codebase and archive parameters, they will be loaded by the same class loader instance. This behavior is required for backward compatibility, and is relied on by several real-world applications. The result is that multiple applets on the same web page may access each others' static variables at the Java language level, effectively allowing the multiple applets to be written as though they comprised a single application.

While this feature enables certain kinds of applications to be conveniently written, it has certain drawbacks. It interferes with termination of applets, in particular when multiple instances of the same applet are active. It makes the programming model for applets more complex, since it is under specified exactly when the static fields of an applet will be re-initialized, and when they will be maintained from run to run of the same applet. It causes imprecise behavior of certain user interface operations within the Java Plug-in due to the inability to identify exactly which applet initiated a particular request.

Garbage collection occurs on an applet instance immediately after the destroy method finishes. The garbage collection applies to all memory acquired by the applet, except for static variables. Statics are preserved in the classloader cache, along with the classes themselves, for as long as the class loader is present.

So when does the class loader go away? That behavior is not specified. It's up to the implementation of the Java virtual machine and its interactions with the operating system. You can expect it be retained for as long as possible, but to be discarded when the memory is needed for other purposes.

Sign all applets with a valid certificate from a recognized certificate authority to provide a better user experience. An applet runs in a secure sandbox that prevents it from interacting with the user's system, unless authorized. To obtain that authorization, the applet must request permissions when it is launched and the user must agree to run the applet. Permissions are needed to:

Deployment of applets using JNLP gives the applets access to JNLP APIs similar to Java Web Start applications, which gives the applet controlled access to a user's system, under control of the user. For example, using JNLP provides the ability to save or open a file selected by the user and the ability to print.

Applets can be deployed by hand-coding the applet, object or embed tags with the required parameters. This section describes these parameters. However, to assure cross-browser compatibility, it is recommended that the Deployment Toolkit be used to deploy applets. See Chapter 19, "Deployment in the Browser" for information on using the Deployment Toolkit.

The Java Plug-in offers better customization of the image that is displayed before the applet is loaded. Animated GIFs are supported as the target of the image parameter. Additionally, the following parameters are supported:

3a8082e126