Editing Java applet (section)

== Disadvantages ==
{{more citations needed section|date=August 2015}}
Java applets had the following disadvantages compared to other client-side web technologies:

* Java applets would depend on a Java Runtime Environment (JRE), a complex and heavy-weight software package.  They also normally required a [[plug-in (computing)|plug-in]] for the web browser. Some organizations only allow software installed by an administrator.  As a result, users were unable to view applets unless one was important enough to justify contacting the administrator to request installation of the JRE and plug-in.
* If an applet requires a newer JRE than available on the system, the user running it the first time will need to wait for the large JRE download to complete.
* Mobile browsers on [[iOS]] or [[Android (operating system)|Android]], never run Java applets at all.<ref>{{cite web|url=http://www.java.com/en/download/faq/java_mobile.xml|title=How do I get Java for Mobile device?|website=Java.com|date=30 July 2014}}</ref> Even before the deprecation of applets on all platforms, desktop browsers phased out Java applet support concurrently with the rise of mobile operating systems.
* There was no standard to make the content of applets available to screen readers. Therefore, applets harmed the accessibility of a web site to users with special needs.
* As with any client-side scripting, security restrictions made it difficult or even impossible for some untrusted applets to achieve their desired goals. Only by editing the java.policy file in the JAVA JRE installation could one grant access to the local filesystem or system clipboard, or to network sources other than the one that served the applet to the browser.
* Most users did not care about the difference between untrusted and trusted applets, so this distinction did not help much with security. The ability to run untrusted applets was eventually removed entirely to fix this, before all applets were removed.