CS2092 - Object Oriented Programming in Java Chapter 9: Applets

CS2092 - Object Oriented Programming in Java Chapter 9: Applets C. C. Kirkham

An applet is a Java program which can appear in a Web page. When the Web browser finds an applet tag in an html file, it downloads the class file for the applet and runs it on the machine on which the browser is running. Alternatively JDK provides the appletviewer command, to which you give as argument the name of an html file, and it then runs the applet. The html file describing the page to the browser or the appletviewer contains something like: An applet has to rely on the AWT to interact with the user - it can’t use System.out or System.in. Here is the HelloWorld applet to which the above html file refers: import java.applet.Applet ; import java.awt.Graphics ; public class HelloWorld extends Applet { public void paint(Graphics g) { g.drawString("Hello World!", 20, 20) ; } } We can quite easily turn a program such as the one written for the Dice game into an applet. If the application being changed extends Frame, it can just be changed to extend Applet instead, with the package java.applet being added to those imported. The main method doesn’t get called, so you can remove it, but quite a lot of what it does will need to move into init(), a method which gets called to initialise an applet. If, as here, the main method called the constructor, any necessary code from that should also be merged into init instead because the Applet is created by the browser and the constructor does not get called. Thus in the Dice application, DiceGame extended Frame, so we change it to extend Applet, and include an init() method. The Game class regains control at the end of the game and produces the final contents of the screen using its own paint method. Here is the resulting DiceApplet class:

1

import java.awt.*; import java.awt.event.*; import java.applet.Applet ; public class DiceApplet extends Applet implements ActionListener, DiceWatcher { final static int howMany = 3 ; private int total ; private int nudges, gambles ; private DiceWithButton [] pane = new DiceWithButton[howMany]; private boolean ended = false ; private String endMessage ; public void init() { setLayout(new BorderLayout()) ; nudges = 0 ; gambles = 0 ; Panel centerPane = new Panel() ; for (int i = 0 ; i < howMany ; i++) centerPane.add(pane[i] = new DiceWithButton(this)); resetTotal() ; add(centerPane,"Center") ; Button b = new Button("Roll the lot") ; b.addActionListener(this) ; add(b, "North") ; setSize(howMany*200,250) ; } private void resetTotal() { total = 0 ; for (int i = 0 ; i < howMany ; i++) total += pane[i].getValue() ; } public void inform(int change) { total += change ; nudges++ ; if (total == 6*howMany) finishoff("nudging") ; } void finishoff(String mess) { endMessage = mess ; ended = true ; getToolkit().beep() ; removeAll() ; }

2

public void actionPerformed(ActionEvent e) { gambles++ ; for (int i = 0 ; i < pane.length ; i++) pane[i].roll() ; resetTotal() ; if (total == 6*howMany) finishoff("gambling") ; } public void paint(Graphics g) { if (ended) { g.drawString("You finished that off by " + endMessage, 70, 30) ; g.drawString("It took " + gambles + " gambles", 70, 65) ; g.drawString("and " + nudges + " nudges", 70, 100) ; } } public static void main(String [] args) { Frame f = new Frame("Dice Game") ; DiceApplet da = new DiceApplet() ; da.init() ; f.add(da, "Center") ; f.addWindowListener(new MyListener()) ; f.pack() ; f.setVisible(true) ; } } Notice an extra thing I have done here is that I also have a main method. It causes no problems when run as an applet because it is never called, and it allows you to run locally in the normal way without using the appletviewer. Note that it needs to create the instance of the applet class and then call its init() method, because that is where a lot of the useful code has been placed. Restrictions to applets Because of the way in which applets can be run, a number of things are not allowed. This is one of the areas which has changed most in the recent past, and in both directions. On the one hand, people have found and complained loudly about possible security problems arising from what is allowed, and this has led to it being constrained more securely. On the other hand, such tight security gets in the way of productive ways of using applets, and therefore safe ways in which restrictions can be relaxed are being investigated. Here is a list of some of the things an applet loaded over the net couldn’t do. It was accurate until recently, but some may be already out-of-date! Such an applet cannot: read files on the local system write, delete, or rename files on the local system 3

list directory contents check for the existence of a file, or obtain information about a file create network connections other than to the computer from which the applet was loaded create a top-level window without an ‘untrusted’ indicator obtain information about the user invoke any program on the local system When an applet is loaded from the local file system rather than across the net, some or all of these may be relaxed. Files like .hotjava/properties in the HotJava Web browser also allow users to slacken some of these restrictions when they use that browser, but this depends on the browser because you are relying on the way the browser implements a security policy by interacting with the class java.lang.SecurityManager. The java.lang.ClassLoader class is responsible for loading classes over the network to the local system, and keeping them separate from those defined on the local system. It also verifies the bytecode which arrives to check that it isn’t trying to cheat in various ways. The main direction of change is certification, which means that some applets from remote sources can, using cryptographic means, prove their identity, and can then be trusted far more than the hoi polloi. Of course the user of the browser has to install the necessary mechanisms to check such certificates, and has to agree to trust them. What it boils down to is that the author of the applet could sign the applet and tell everyone how to check that the applet they get is a valid one produced by him. They then have to make sure that their browsers allow more than default access to it when it runs, and if it is caught behaving suspiciously there is no doubt about who to blame.

4