Editing Java applet (section)

== Advantages ==
A Java applet could have any or all of the following advantages:<ref>[http://download.oracle.com/javase/tutorial/deployment/applet/index.html Oracle official] overview on Java applet technology</ref>

* It was simple to make it work on FreeBSD, Linux, Microsoft Windows and macOS{{snd}} that is, to make it cross-platform. Applets were supported by most [[web browser]]s through the first decade of the 21st century; since then, however, most browsers have dropped applet support for security reasons.
* The same applet would work on "all" installed versions of Java at the same time, rather than just the latest [[plug-in (computing)|plug-in]] version only. However, if an applet requires a later version of the [[Java virtual machine|Java Runtime Environment]] (JRE) the client would be forced to wait during the large download.
* Most web browsers [[web cache|cached]] applets so they were quick to load when returning to a web page. Applets also improved with use: after a first applet is run, the JVM was already running and subsequent applets started quickly (the JVM will need to restart each time the browser starts afresh). JRE versions 1.5 and greater restarted the JVM when the browser navigates between pages, as a security measure which removed that performance gain.
* It moved work from the [[server (computing)|server]] to the [[client (computing)|client]], making a web solution more scalable with the number of users/clients.
* If a standalone program (like [[Google Earth]]) talks to a web server, that server normally needs to support all prior versions for users who have not kept their client software updated. In contrast, a browser loaded (and cached) the latest applet version, so there is no need to support legacy versions.
* Applet naturally supported changing user state, such as figure positions on the chessboard.
* Developers could develop and debug an applet directly simply by creating a main routine (either in the applet's class or in a separate class) and calling init() and start() on the applet, thus allowing for development in their favorite [[Java Platform, Standard Edition|Java SE]] development environment. All one had to do was to re-test the applet in the AppletViewer program or a web browser to ensure it conforms to security restrictions.
* An [[Browser security|untrusted]] applet had no access to the local machine and can only access the server it came from. This makes applets much safer to run than the native executables that they would replace. However, a signed applet could have full access to the machine it is running on, if the user agreed.
* Java applets were fast, with [[Java performance|similar performance]] to natively installed software.