Java applet

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Java applet that was created as a supplementary demonstration material of the scientific
publication.[1] and is available from the university site

Java applet that uses 3D hardware acceleration,

downloading from the server 3D files in .pdb format to
visualize[2]

Using applet for non trivial animation illustrating biophysical topic (randomly moving
ions pass through voltage gates)[3]

Using Java applet for computation - intensive visualization of the Mandelbrot set[4]

Sufficient running speed is also utilized in applets for playing non trivial computer games
like chess [[5]]

NASA World Wind (open source) is a second generation applet [6] that heavily uses
OpenGL and on-demand data downloading to provide detailed 3D map of the world.

Web access to the server console at the hardware level with the help of java applet

A Java applet is an applet delivered to the users in the form of Java bytecode. Java
applets can run in a Web browser using a Java Virtual Machine (JVM), or in Sun's
AppletViewer, a stand-alone tool for testing applets. Java applets were introduced in the
first version of the Java language in 1995. Java applets are usually written in the Java
programming language but they can also be written in other languages that compile to
Java bytecode such as Jython[7], Ruby[8] or Eiffel[9].
Applets are used to provide interactive features to web applications that cannot be
provided by HTML alone. They can capture mouse input (like rotating 3D object) and
also have controls like buttons or check boxes. In response to the user action an applet
can change the provided graphic content. This makes applets well suitable for
demonstration, visualization and teaching. There are online applet collections for
studying various subjects, from differential equations[10] to heart physiology[3]. Applets
are also used to create online game collections that allow players to compete against live
opponents in real-time.

An applet can also be a text area only, providing, for instance, a cross platform
command-line interface to some remote system[11]. 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 dedicated area, so they are less useful for
improving the site appearance in general (while applets like news tickers[12] or
WYSIWYG editors[13] are also known). Applets can also play media in formats that are
not natively supported by the browser[14].

Java applets run at a speed that is comparable to (but generally slower than) other
compiled languages such as C++, but many times faster than JavaScript[15]. In addition
they can use 3D hardware acceleration that is available from Java. This makes applets
well suited for non trivial, computation intensive visualizations.

HTML pages may embed parameters that are passed to the applet. Hence the same applet
may appear differently depending on the parameters that were passed. The first
implementations involved downloading an applet class by class. While classes are small
files, there are frequently a lot 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 of the bigger image (hundreds of kilobytes to several
megabytes).

Since Java's bytecode is platform independent, Java applets can be executed by browsers
for many platforms, including Windows, Unix, Mac OS and Linux. It is also trivial to run
a Java applet as an application with very little extra code. This has the advantage of
running a Java applet in offline mode without the need for any Internet browser software
and also directly from the development IDE.

Many Java developers, blogs and magazines are recommending that the Java Web Start
technology be used in place of Applets [16][17].

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.

Contents
[hide]
 • 1 Technical information
• 2 Simple examples
o 2.1 A basic example using the java.applet package
• 3 Advantages
• 4 Disadvantages
• 5 Compatibility related lawsuits
o 5.1 The 1997 year Sun - Microsoft lawsuit
o 5.2 The 2002 year Sun - Microsoft lawsuit
• 6 Applet security
o 6.1 Unsigned applet
o 6.2 Signed applet
• 7 Alternatives
• 8 See also
• 9 References

• 10 External links

Technical information
Java applets are executed in a sandbox by most web browsers, preventing them from
accessing local data like clipboard or file system. The code of the applet is downloaded
from a web server and the browser either embeds the applet into a web page or opens a
new window showing the applet's user interface. The applet can be displayed on the web
page by making use of the deprecated applet HTML element [1], or the recommended
object element [2]. This specifies the applet's source and the applet's location statistics.

A Java applet extends the class java.applet.Applet, or in the case of a Swing applet,
javax.swing.JApplet. The class must override methods from the applet class to set up
a user interface inside itself (Applet is a descendant of Panel which is a descendant of
Container. As applet inherits from container, it has largely the same user interface
possibilities as an ordinary Java application, including regions with user specific
visualization.

The domain from where the applet executable has been downloaded is the only domain to
that the usual (unsigned) applet is allowed to communicate. This domain can be different
from the domain where the surrounding html document is hosted.

Simple examples
A basic example using the java.applet package

The following example is made simple enough to illustrate the essential use of Java
applets through its java.applet package. It also uses classes from the Java Abstract
Window Toolkit (AWT) for producing actual output (in this case, the "Hello, world!"
message).

import java.applet.Applet;
import java.awt.*;

// Applet code for the "Hello, world!" example.

// This should be saved in a file named as "HelloWorld.java".
public class HelloWorld extends Applet {
// This method is mandatory, but can be empty (i.e., have no actual
code).
public void init() { }

// This method is mandatory, but can be empty.

public void stop() { }

// Print a message on the screen (x=20, y=10).

public void paint(Graphics g) {
g.drawString("Hello, world!", 20,10);
}
}

For compilation, this code is saved on a plain-ASCII file with the same name as the class
and .java extension, i.e. HelloWorld.java. The resulting HelloWorld.class applet
should be installed on the web server and is invoked within an HTML page by using an
<APPLET> or a <SCRIPT> tag. For example:

<!DOCTYPE HTML PUBLIC

"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>HelloWorld_example.html</TITLE>
</HEAD>
<BODY>
<H1>A Java applet example</H1>
<P>Here it is: <APPLET code="HelloWorld.class" WIDTH="200" HEIGHT="40">
This is where HelloWorld.class runs.</APPLET></P>
</BODY>
</HTML>

Displaying the HelloWorld_example.html page from a Web server, the result should
look as this:

A Java applet example

Here it is: Hello, world!

To minimize download time, applets are usually delivered in a form of compressed zip
archive (having jar extension). If all needed classes (only one in our case) are placed in
compressed archive example.jar, the embedding code would look differently:
<P>Here it is: <APPLET code="HelloWorld" WIDTH="200" HEIGHT="40"
ARCHIVE="example.jar">
This is where HelloWorld.class runs.</APPLET></P>

Applet inclusion is described in detailed in [18].

Advantages
A Java applet can have any or all of the following advantages:

• It is simple to make it work on Linux, Windows and Mac OS i.e. to make it cross
platform. Applets are supported by most web browsers
• The same applet can work on "all" installed versions of Java at the same time,
rather than just the latest plug-in version only. However, if an applet requires a
later version of the JRE the client will be forced to wait during the large
download.
• Most web browsers cache applets, so will be quick to load when returning to a
web page. Applets also improve with use: after a first applet is run, the JVM is
already running and starts quickly (JVM will need to restart each time the browser
starts fresh).
• It can move the work from the server to the client, making a web solution more
scalable with the number of users/clients
• If standalone program (like Google Earth) talks to the web server, that server
normally needs to support also previous versions as the user may not keep it
always updated. Differently, the browser updates the applet so there is no need to
support the legacy versions. Only due configuration mistakes the applet may get
stuck in the cache and have issues when new versions come out.
• The applet naturally supports the changing user state like figure positions on the
chessboard.
• Developers can develop and debug an applet direct simply by creating a main
routine (either in the applet's class or in a separate class) and call init() and start()
on the applet, thus allowing for development in their favorite J2SE development
environment. All one has to do after that is re-test the applet in the appletviewer
program or a web browser to ensure it conforms to security restrictions.
• An untrusted applet has no access to the local machine and can only access the
server it came from. This makes such applet much safer to run than standalone
executable that it could replace. However signed applet can have full access to the
machine it is running on if the user agrees.

Disadvantages
A Java applet may have any of the following disadvantages:

• It requires the Java plug-in which may not be available on some less popular web
browsers or operating systems.
 • Some organizations only allow software installed by the administrators. As a
result, some users can only view applets that are important enough to contact the
administrator asking to install the Java plug-in.
• As with any client side scripting, security restrictions may make difficult or even
impossible for untrusted applet to achieve the desired goals.
• Some more badly designed code may require a specific JRE [19].

Compatibility related lawsuits

Sun has made a considerable effort to ensure compatibility is maintained between Java
versions as they evolve, enforcing Java portability by law if required.

The 1997 year Sun - Microsoft lawsuit

The 1997 year lawsuit [20] was filled in after Microsoft has modified its own Java Virtual
Machine that was shipped with Internet Explorer by default. Microsoft added about 50
methods and 50 fields[20] into the classes within the java.awt, java.lang, and java.io
packages. Other modifications included removal of RMI capability and replacement of
Java native interface from JNI to RNI, a different standard. RMI was removed because it
only easily supports Java to Java communications and competes with Microsoft DCOM
technology. Applets that relied on these changes or just inadvertently used them worked
only within Microsoft's Java system. Sun sued for breach of trademark, as the point of
Java was that there should be no proprietary extensions and that code should work
everywhere. Microsoft agreed to pay Sun $20 million, and Sun agreed to grant Microsoft
limited license to use Java without modifications only and for a limited time[21]
Insertformulahere
The 2002 year Sun - Microsoft lawsuit

Microsoft continued to ship its own unmodified Java virtual machine. Over years it has
become extremely outdated yet still default for Internet Explorer. In 2002 Sun filled in
antitrust lawsuit, claiming that Microsoft's attempts of illegal monopolization have
harmed the Java platform. Sun demanded to distribute Sun's current, binary
implementation of Java technology as part of Windows, distribute it as a recommended
update for older Microsoft desktop operating systems and stop the distribution of
Microsoft's Virtual Machine (as its licensing time, agreed in the previous lawsuit, had
expired).[21] Microsoft paid $700 million for pending antitrust issues, another $900
million for patent issues and a $350 million royalty fee to use Sun's software in the
future.[22][23]

Applet security
There are two applet types with very different security model: signed applets and
unsigned applets[24]
Unsigned applet

Limitations for the unsigned applets are understood as "draconian" [25]: they have no
access to the local filesystem, web access limited to the applet download site, there are
also many other important restrictions. For instance, they cannot access system
properties, use their own class loader, call native code, execute external commands on a
local system or redefine classes belonging to the certain packages. While they can run in
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 access controller checks all stack of the calling code to be sure the call is not
coming from improper location. Several specific security problems have been discovered
and fixed since Java was first released, and some like [26] even persisted as long as till
2008 without anybody being aware. Some studies mention applets crashing browser or
overusing CPU resources but these are classified as nuisances[27] and not as true security
flaws. However unsigned applets may be involved into combined attack that exploit
combination of multiple severe configuration errors in other parts of the system[28].
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 attack 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[29].

As of 1999 no real security breaches involving unsigned applets have ever been publicly
reported, while these references are now dated [27][30]. Using an up-to-date Web browser is
usually enough to be safe safe against the known attacks from unsigned applets.

Signed applet

Signed applet [3] contains a signature that the browser should verify through 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 then the user of the current machine also approves, signed applet can get
more rights, becoming equivalent to the ordinary standalone program. The rationale is
that the author of the applet is now known and will be responsible for any deliberate
damage. This approach allows to use applets for many tasks that are otherwise not
possible by client side scripting. However this approach require more responsibility from
the user, deciding whom he/she is trusting. The probable concerns include non-
responding authority server (should the applet be allowed to run?), wrong evaluation of
the signer identity when issuing certificates and known applet publishers still doing
something that the user would not approve (as adding bookmark to the website). Hence
signed applets that appeared from Java 1.1 may actually have more security concerns.

Java security problems are not fundamentally different from similar problems of any
client side scripting platform. In particular, all issues related to the signed applets also
apply to Active X.
Alternatives
Alternative technologies exist (for example, JavaScript, Curl, Flash, and Microsoft
Silverlight) that satisfy some of the scope of what is possible with an applet. Of these,
JavaScript is not always viewed as a competing replacement; JavaScript can coexist with
applets in the same page, assist in launching applets (for instance, in separate frame or
providing platform workarounds) and later be called from the applet code[31].