Java applets were small applications written in the Java programming language, or another programming language that compiles to Java bytecode, and delivered to users in the form of Java bytecode. The user launched the Java applet from a web page, and the applet was then executed within a Java virtual machine (JVM) in a process separate from the web browser itself. A Java applet could appear in a frame of the web page, a new application window, Sun's AppletViewer, or a stand-alone tool for testing applets.
Java applets were introduced in the first version of the Java language, which was released in 1995. Beginning in 2013, major web browsers began to phase out support for the underlying technology applets used to run, with applets becoming completely unable to be run by 2015–2017. Java applets were deprecated by Java 9 in 2017.
Java applets were usually written in Java, but other languages such as Jython, JRuby, Pascal, Scala, NetRexx, or Eiffel (via SmartEiffel) could be used as well.
Since Java bytecode is cross-platform (or platform independent), Java applets could be executed by clients for many platforms, including Microsoft Windows, FreeBSD, Unix, macOS and Linux. They could not be run on mobile devices, which do not support running standard Oracle JVM bytecode. Android devices can run code written in Java compiled for the Android Runtime.
The applets are used to provide interactive features to web applications that cannot be provided by HTML alone. They can capture mouse input and also have controls like buttons or check boxes. In response to user actions, an applet can change the provided graphic content. This makes applets well-suited for demonstration, visualization, and teaching. There are online applet collections for studying various subjects, from physics to heart physiology.
An applet can also be a text area only; providing, for instance, a cross-platform command-line interface to some remote system. If needed, an applet can leave the dedicated area and run as a separate window. However, applets have very little control over web page content outside the applet's dedicated area, so they are less useful for improving the site appearance in general, unlike other types of browser extensions (while applets like news tickers or WYSIWYG editors are also known). Applets can also play media in formats that are not natively supported by the browser.
Pages coded in HTML may embed parameters within them that are passed to the applet. Because of this, the same applet may have a different appearance depending on the parameters that were passed.
Most browsers executed Java applets in a sandbox, preventing applets from accessing local data like the file system. The code of the applet was downloaded from a web server, after which the browser either embedded the applet into a web page or opened a new window showing the applet's user interface.
The first implementations involved downloading an applet class by class. While classes are small files, there are often many of them, so applets got a reputation as slow-loading components. However, since
.jars were introduced, an applet is usually delivered as a single file that has a size similar to an image file (hundreds of kilobytes to several megabytes).
Java system libraries and runtimes are backwards-compatible, allowing one to write code that runs both on current and on future versions of the Java virtual machine.
Many Java developers, blogs and magazines recommended that the Java Web Start technology be used in place of applets. Java Web Start allowed the launching of unmodified applet code, which then ran in a separate window (not inside the invoking browser).
A Java Servlet is sometimes informally compared to be "like" a server-side applet, but it is different in its language, functions, and in each of the characteristics described here about applets.
The applet would be displayed on the web page by making use of the deprecated
applet HTML element, or the recommended
object element. The
embed element can be used with Mozilla family browsers (
embed was deprecated in HTML 4 but is included in HTML 5). This specifies the applet's source and location. Both
embed tags can also download and install Java virtual machine (if required) or at least lead to the plugin page.
object tags also support loading of the serialized applets that start in some particular (rather than initial) state. Tags also specify the message that shows up in place of the applet if the browser cannot run it due to any reason.
object being officially a recommended tag in 2010, the support of the
object tag was not yet consistent among browsers and Sun kept recommending the older
applet tag for deploying in multibrowser environments, as it remained the only tag consistently supported by the most popular browsers. To support multiple browsers, using the
The Java browser plug-in relied on NPAPI, which nearly all web browser vendors have removed support for, or do not implement, due to its age and security issues. In January 2016, Oracle announced that Java runtime environments based on JDK 9 will discontinue the browser plug-in.
A Java applet could have any or all of the following advantages:
Java applets had the following disadvantages compared to other client-side web technologies:
There were two applet types with very different security models: signed applets and unsigned applets. Starting with Java SE 7 Update 21 (April 2013) applets and Web-Start Apps are encouraged to be signed with a trusted certificate, and warning messages appear when running unsigned applets. Further, starting with Java 7 Update 51 unsigned applets were blocked by default; they could be run by creating an exception in the Java Control Panel.
Limits on unsigned applets were understood as "draconian": they have no access to the local filesystem and web access limited to the applet download site; there are also many other important restrictions. For instance, they cannot access all system properties, use their own class loader, call native code, execute external commands on a local system or redefine classes belonging to core packages included as part of a Java release. While they can run in a standalone frame, such frame contains a header, indicating that this is an untrusted applet. Successful initial call of the forbidden method does not automatically create a security hole as an access controller checks the entire stack of the calling code to be sure the call is not coming from an improper location.
As with any complex system, many security problems have been discovered and fixed since Java was first released. Some of these (like the Calendar serialization security bug) persisted for many years with nobody being aware. Others have been discovered in use by malware in the wild.
Some studies mention applets crashing the browser or overusing CPU resources but these are classified as nuisances and not as true security flaws. However, unsigned applets may be involved in combined attacks that exploit a combination of multiple severe configuration errors in other parts of the system. An unsigned applet can also be more dangerous to run directly on the server where it is hosted because while code base allows it to talk with the server, running inside it can bypass the firewall. An applet may also try DoS attacks on the server where it is hosted, but usually people who manage the web site also manage the applet, making this unreasonable. Communities may solve this problem via source code review or running applets on a dedicated domain.
The unsigned applet can also try to download malware hosted on originating server. However it could only store such file into a temporary folder (as it is transient data) and has no means to complete the attack by executing it. There were attempts to use applets for spreading Phoenix and Siberia exploits this way, but these exploits do not use Java internally and were also distributed in several other ways.
A signed applet contains a signature that the browser should verify through a remotely running, independent certificate authority server. Producing this signature involves specialized tools and interaction with the authority server maintainers. Once the signature is verified, and the user of the current machine also approves, a signed applet can get more rights, becoming equivalent to an ordinary standalone program. The rationale is that the author of the applet is now known and will be responsible for any deliberate damage.[vague] This approach allows applets to be used for many tasks that are otherwise not possible by client-side scripting. However, this approach requires more responsibility from the user, deciding whom he or she trusts. The related concerns include a non-responsive authority server, wrong evaluation of the signer identity when issuing certificates, and known applet publishers still doing something that the user would not approve of. Hence signed applets that appeared from Java 1.1 may actually have more security concerns.
Self-signed applets, which are applets signed by the developer themselves, may potentially pose a security risk; java plugins provide a warning when requesting authorization for a self-signed applet, as the function and safety of the applet is guaranteed only by the developer itself, and has not been independently confirmed. Such self-signed certificates are usually only used during development prior to release where third-party confirmation of security is unimportant, but most applet developers will seek third-party signing to ensure that users trust the applet's safety.
Java security problems are not fundamentally different from similar problems of any client-side scripting platform. In particular, all issues related to signed applets also apply to Microsoft ActiveX components.
As of 2014, self-signed and unsigned applets are no longer accepted by the commonly available Java plugins or Java Web Start. Consequently, developers who wish to deploy Java applets have no alternative but to acquire trusted certificates from commercial sources.