CS2 Advanced Programming in Java note 8

Size: px

Start display at page:

Download "CS2 Advanced Programming in Java note 8"

Hugo Hubbard
5 years ago
Views:

1 CS2 Advanced Programming in Java note 8 Java and the Internet One of the reasons Java is so popular is because of the exciting possibilities it offers for exploiting the power of the Internet. On the one hand, it is easy to write self-contained programs (called applets) which can be embedded in Web pages. On the other hand, there are also facilities which make it easy for a program to communicate over the Internet with other programs running at the same time. In this note, we will briefly look at some of these possibilities. The first half of this note is closely based on Chapter 20 of Cornelius s book, which we recommend for a more detailed account of this material. 8.1 Embedding an applet in a Web page We have seen in a previous lecture how to use the graphical facilities provided by the Swing toolkit to create programs called applets. As we have seen, applets can be run and tested using the, but the main reason for creating an applet is to include it as part of a Web page. To do this, one simply has to insert a suitable piece of HTML at the appropriate point in the source file for your Web page, telling the user s Web browser where to find the Java class files for the applet, and how much space to allow for the applet panel. In the early days of the WWW, this could be done with a very simple piece of HTML such as! "# $% " '&)( * *,+.-/ / : 8 Unfortunately, however, as the WWW developed, things got more complicated: different browsers made use of slightly different variants of HTML and supporting different versions of Java, and it became harder to ensure that the same applet could be run on all browsers. The recommended solution nowadays is to include a more complicated and ugly piece of HTML which instructs the browser to download a plug-in to enable it to run the appropriate version of Java if this version is not already present on the computer. We will not bother to include the relevant piece of HTML here, but you may find it in the file ;< =>& $ in the Practical 8 directory. You do not really have to understand how it works to adapt it to your own applet, you typically only have to change the name of the Java class file and the values of the width and height parameters (and perhaps also the version of Java that your applet requires.) 1

2 Much of the complication stems from the fact that different Web browsers expect different things, so the HTML we use actually has to say many things twice once for the benefit of Netscape Navigator, and once for the benefit of Internet Explorer! (Note that in adapting the HTML you therefore have to change the filename and size parameters in two places.) An even more complicated version that can deal with even more situations is available from the Sun website at : : A B&)*DC "@&)(=D$ : <= E C(F * : FC# /". Unless otherwise stated in your HTML, the browser will look for the Java class file for the applet in the same directory as that in which the HTML source file itself is hosted. If the applet lives in some other directory, you can tell it where to look by changing the value of the ( =E G< <* attribute to the (relative) pathname of the directory where your class file lives. 8.2 Java Archive files Typically a Java program will involve several &)( ** files. If the approach outlined above is adopted, your HTML will refer only to the main class file for your program, and the web browser will download this only to discover that it needs other class files in order to run the program. This is rather inefficient as it tends to result in several HTTP connections, one for each class file needed. To overcome this problem, it is recommended that all the class files (and any other files the applet needs such as images and audio clips) be bundled together in a single Java Archive file, or & A file. For instance, to bundle together all the &)( * * files in the current directory, one can type something like AH(D I "# $%" '& A KJL&)( * * to the shell prompt. (See the online manual page for A for more details on this command.) To tell the Web browser to look for a & A file rather than a &)( ** file, we now have to add a couple more lines of HTML to set the %(/;./ < attribute. In connection with the M ND tag, we add the line O PQ P (/;./ SR T! "# $%" '& A 98 alongside the other lines of a similar form, and in connection with the PM we add the clause tag (/;./! "# A The use of a & A file means that all the files needed to run the program can be downloaded using a single HTTP connection. In addition, the A utility performs some compression on the files, which further improves download time. 2

3 8.3 The life cycle of an applet Finally, in order to write any code for an applet, one needs to be aware of the various stages that an applet can go through in its interaction with a web browser. Recall that the Java code for an applet takes the form of a class which inherits (directly or indirectly) from the API class JApplet, and which has a zero-argument constructor (which may be the default constructor if no other is provided). When the user first visits the web page containing the applet, the applet s bytecode is loaded into the browser, and a new object of this class is created using the zeroargument constructor. As usual when an object is created, this will typically mean that initial values are assigned to the object s fields, and the body of the constructor (if present) is executed. Next, the object s init method is executed, which may perform further initialization. After that, the object s start method is executed. Whereas the init method is only executed once when the applet is first loaded, the start method is re-executed whenever the user returns to the WWW page after having visited another page. Whenever the user leaves this page, the stop method is executed. Finally, the destroy method is executed if the WWW browser ever unloads the applet (for instance, to make room for another applet). The class JApplet itself has trivial versions of these four methods (which do nothing), but the programmer may override these with his or her own code to do whatever is required in each of these situations. For instance, the init and destroy methods might (respectively) open and close connections with the server (see below), or the start method might start some animation sequence. For many applets, it suffices to provide a simple init method. We should also mention the paint method which is called whenever the applet window has to be redrawn (e.g. immediately after the init and start methods are executed, or after the browser window has been moved or resized). As explained in a previous lecture, the programmer will typically wish to override the paint method with code to redraw the applet window s contents appropriately. Finally, a reminder that for security reasons, there are certain limitations on the operations that an applet can perform: typically it cannot read or write files on the machine it is running on, or establish connections with other computers apart from the server from which it was downloaded. (These limitations are special to applets and do not apply to Java programs in general.) This principle is often expressed by saying that applets are run within a sandbox Reading files over the Internet So far we have looked at applets which, although they can be transferred over the Internet, essentially run as self-contained programs. We will now look at some of the ways in which applets (and Java programs in general) can communicate with other machines over the Internet. 1 A safe play area for small children. When I was little we called this a sandpit. 3

4 We first consider how a program may read a file stored on another machine. We might wish to do this if we had a large repository of data files hosted on a server somewhere, and we wished to allow a program running on another machine to gain access to just the files that it needs, without downloading the entire repository. To read the contents of a data file stored anywhere on the Internet, one needs to know the URL for the file. In a Java program, URLs are represented by objects of the class java.net.url. There are a variety of constructors for this class: for instance, we may create an instance by saying something like URL stuffurl = new URL (" ) ; or, if dir is already the URL for a directory somewhere, we may construct the URL for a particular file in this directory by saying URL stuffurl = new URL (dir, "stuff.txt " ) ; We may then "open" the file in question to obtain an input stream, which we can manipulate just as if it were an input stream obtained from a file on the local machine, or one corresponding to input from the keyboard. As with keyboard input, a rather complex sequence of transformations is needed to get this stream into the most convenient form: BufferedReader stuffreader = new BufferedReader (new InputStreamReader (stuffurl.openstream())) ; We may then use methods for the class BufferedReader to read the contents of stuff.txt in the way that we require, e.g. a character at a time, or a line at a time. When we have finished with this file, we may execute stuffreader.close(). A Java application program may read a file in this way from a machine anywhere on the Internet. By contrast, an applet is only permitted to read files from the server on which the applet itself was hosted. One could of course write the appropriate URL for this server into the Java code itself, but it is much better to obtain this URL by calling the method getdocumentbase from the class java.applet.applet. This method returns the URL of the directory containing the &U; $ file for the Web page containing the applet. From this one may obtain the URL for the required file itself as e.g. URL stuffurl = new URL (getdocumentbase(), "stuff.txt") ; Another closely related method is getcodebase, which returns the URL of the directory containing the main Java class file for the applet. This will typically be the same as the URL given by getdocumentbase, unless the codebase attribute is explicitly been set to something else in the HTML as described above. Warning: The methods getdocumentbase and getcodebase should be called within the body of the init method for the applet. They do not seem to work if called within the body of the constructor or in field initialization expressions. 8.5 Client/server computing and sockets Although the machinery described above allows client programs to access large amounts of data stored on a single server, it is rather limited by the fact that 4

5 the data in question has to be static that is, stored in fixed, pre-existing files. For more interesting applications, we would like the dialogue between client and server to be more interactive in particular we would like to be able to communicate dynamic data that has been specially generated by a live program in response to a request from the client. (For example, consider a Webbased system which allows the user to find out the times of trains between two given stations around a given time.) Or we might want our server to administer communications between different clients (consider a Web-based multi-player adventure game). All these kinds of communication, and more, can be achieved very simply in Java using the API classes for sockets. Sockets provide a way in which a pair of processes can communicate. The two processes might be running on the same machine or on different machines. In general the processes need not be Java programs, but here we will restrict attention the case of a Java program communicating with another Java program. The basic paradigm is as follows. Each machine on the Internet has (conceptually at least) several thousand ports on which it can communicate, each identified by a number between 1 and Ports 1 to 1023 are typically reserved for system uses such as sending and receiving , but almost all the others are available for use by users. To establish a connection between two processes, one of the processes (which we call the server) needs to be already listening out for connection requests on some port; the other (which we call the client) then takes the initiative and calls up the server on this port to make a connection. More specifically, the server program first needs to create a server socket on a given port, using the constructor ServerSocket (int port). The server may then listen for a connection by calling the method accept () on this server socket. The accept method will wait until a connection is made, and will then create and return a new Socket object which the server may use to talk to the client. At any time, the server may close the server socket using the method close(), after which it will no longer be possible for new clients to initiate connections. Meanwhile, a client has created a client socket and connected it to the server on the given port using the constructor Socket (String host, int port) Here the host identifies the server it may be a name (such as "localhost" or " starfruit.dcs.ed.ac.uk ") or an IP address (such as " "). Assuming the server is listening for a connection at the time, this creates a socket on the client s side which he may use to talk to the server. We are now in a position where each party is in possession of a Socket object which he may use to talk to the other. All the actual communication happens using these sockets; the server socket only exists to allow connections to be set up. Now that the socket connection is in place, it can be used as a bidirectional communication channel. For both parties, the methods getinputstream() and getoutputstream() return the InputStream and OutputStream associated with the socket, and they can send and receive information on these streams (as a sequence of bytes) at any time, much as if they were writing to or reading from an 5

6 ordinary file. We will typically want to buffer these streams for efficiency, e.g. BufferedInputStream bis = new BufferedInputStream (sock.getinputstream()) ; At any time, either participant may close the connection by calling the method close() on their socket. Note that an applet may initiate a socket connection to the host from which the applet was downloaded, but not to any other machine. Furthermore, an applet may not set itself up as a server and accept socket connections from another machine. This probably gives you enough information to get started; further information can be found in the online documentation for the classes Socket and ServerSocket in the package java.net. In a sense, sockets provide a rather primitive or low-level form of communication in that they only allow the two parties to exchange data as raw bytes. In addition, Java has APIs that offer higher levels of abstraction for client-server computing, principally Remote Method Invocation (RMI) and Common Object Request Broker Architecture (CORBA). However, we will not go into these here, and in any case it is important first to understand of the socket level communication on which these technologies are based. John Longley,

Framework. Set of cooperating classes/interfaces. Example: Swing package is framework for problem domain of GUI programming

Framework. Set of cooperating classes/interfaces. Example: Swing package is framework for problem domain of GUI programming Frameworks 1 Framework Set of cooperating classes/interfaces Structure essential mechanisms of a problem domain Programmer can extend framework classes, creating new functionality Example: Swing package