ch4.htm

JAVA Developing Professional JavaApplets

give you a sophisticated system of security layers. At the top
of this security hierarchy is protection for the local file system.
After all, the most prevalent methods for a virus to inflict pain
on its victim is to destroy his or her file system. Consequently,
protection of the file system where the applet is running is paramount.
<P>
A Java environment enforces a security policy through its security
manager. This is implemented as an object through the SecurityManager
class and is created once and only once by a browser at startup.
Once established, a SecurityManager cannot be changed or replaced.
The reasons for this are obvious. If a rogue applet can modify
the SecurityManager object, then it can simply remove all access
restrictions and wield unlimited power over your hard disk. However,
it is possible to get a reference to the SecurityManager through
the System object's <TT>getSecurityManager()</TT>
method. Once obtained, methods can be applied on the object to
see what security constraints are currently being applied.
<P>
The strictness of a security policy depends on the runtime Java
environment. Netscape Navigator, for example, cannot perform any
file operations. The simple File class example in the previous
section causes a security violation. This occurs when the File
<TT>exists()</TT> method is invoked,
which is the first file operation in the code (the File constructor
simply associates the String name with the object).
<P>
Sun's HotJava browser allows some file operations on the client
running an applet. Note that where the applet is loaded from is
important. The client is the site running the applet; the server
is where the applet was loaded from. The security that concerns
Java the most is that of the client site. In Hot Java, the operations
allowed on the client are based on the concept of <I>access control
lists</I>. By default, any file not covered in the list cannot
be accessed in any fashion, including the simple File <TT>exists()</TT>
operation. The access control list can be found in the properties
file of the .hotjava directory located under the parent.
<P>
File security is even weaker for the appletviewer program that
programmers can use to test an applet. In this environment, most
file operations are allowed for applets loaded from the client.
Some file operations performed by applets loaded from a server
over the network are also permitted. Standalone Java applications
have no file security. If a sophisticated Java application is
being developed, such as over an internal corporate network, it
probably would be best to create a subclass of SecurityManager
to set up a security policy appropriate for that environment.
<P>
When a file operation violates a security policy, a SecurityException
object is thrown. This can be caught by the program to prevent
abnormal termination.
<H3><A NAME="IOExceptions">I/O Exceptions</A></H3>
<P>
Besides thrown SecurityException objects, Java I/O programs need
to be concerned with handling other exceptions. In particular,
they need to catch IOException objects that are thrown. The IOException
class embraces the category of errors related to input/output
operations. Many of the methods in the java.io package throw IOException
objects that must be caught. The typical structure of code that
performs I/O operations is, therefore, as follows:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;// IO operations<BR>
}<BR>
catch (IOException e) {<BR>
&nbsp;&nbsp;// Handle the error<BR>
}</TT>
</BLOCKQUOTE>
<P>
Two subclasses of IOException are noteworthy. A FileNotFoundException
object is thrown when there is an attempt to open a file that
doesn't exist. For example, the constructor for the FileInputStream
class tries to open the file specified in its parameter. If it
cannot do so, an object of class FileNotFoundException is thrown.
<P>
Another notable subclass of IOException is EOFException, which
typically occurs in read operations when an end of file has been
reached. This indicates that there are no more bytes to be read.
<H3><A NAME="InputStreamClasses">InputStream Classes</A></H3>
<P>
Figure 4.7 illustrates the class hierarchy that descends from
the InputStream class. InputStream is an abstract class that defines
the basic operations that must be implemented by its subclasses.
The most noteworthy of these is the <TT>read()</TT>
method. This is used to read in bytes one at a time or into a
byte array. The System.in variable, which represents that standard
input stream, is based on the InputStream class and is now used
to illustrate the <TT>read()</TT>
method:
<P>
<A HREF="f4-7.gif" ><B>Figure 4.7 :</B><I> Input stream classes</I></A>
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;int b;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b = System.in.read();
<BR>
}<BR>
catch (IOException e) {<BR>
&nbsp;&nbsp;// Handle any exception&#133;<BR>
}</TT>
</BLOCKQUOTE>
<P>
This example reads in a byte that is, confusingly, converted to
an integer by the <TT>read()</TT>
method. The method returns <TT>-1</TT>
if there is no input to be read. For many subclasses of InputStream,
an EOFException object is thrown in these circumstances.
<P>
Table 4.2 lists other notable methods of the abstract InputStream
class.<BR>
<P>
<CENTER><B>Table 4.2. Notable InputStream methods.</B></CENTER>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=124><I>Method</I></TD><TD WIDTH=409><I>Description</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>available</TT>
</TD><TD WIDTH=409>A non-blocking way to find out number of bytes available to read.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>Close</TT></TD>
<TD WIDTH=409>Closes the input stream.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>mark</TT></TD>
<TD WIDTH=409>Marks the current stream position.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>read</TT></TD>
<TD WIDTH=409>Reads a byte or array of bytes.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>reset</TT></TD>
<TD WIDTH=409>Resets stream to last marked position.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=124><TT>skip</TT></TD>
<TD WIDTH=409>Skips over specified number of input bytes.</TD>
</TR>
</TABLE></CENTER>
<P>
<H4>FilterInputStream classes</H4>
<P>
The FilterInputStream class is at the top of a branch of the InputStream
hierarchy that can be used to implement some very powerful operations.
In particular, this class is used to chain a series of FilterInputStream
classes so that one stream can process data before passing it
&quot;up&quot; to the next stream. This chaining technique is
excellent to use when encapsulating classes that interact with
streams at a lower level (such as bytes) into streams that read
in data at a higher level, such as Strings. The following example
illustrates how this works.
<P>
As seen in the previous overview of the InputStream class, the
System.in object reads data in a byte at a time. This will prove
to be cumbersome for many standard input operations that typically
want to work on String objects. Fortunately, FilterInputStream
classes make it easy to abstract this byte-level functionality
into a higher and more usable interface. The code in Listing 4.6
takes the System.in object and creates a DataInputStream object
that can be used to read in a String of text delimited by a newline
or EOF. This is then sent to the System.out object, which prints
the string to the standard output stream.
<HR>
<BLOCKQUOTE>
<B>Listing 4.6. Chaining Input Stream classes.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Create
the data input stream...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DataInputStream
dis =<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;new
DataInputStream(<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;new
BufferedInputStream(System.in));<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Read
in a line of text...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;String s
= dis.readLine();<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Send
it to standard output...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(s);
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Handle any exceptions caused
by the process...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;catch (IOException e) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Just
print out the error...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;System.out.println(e.getMessage());
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}</TT>
</BLOCKQUOTE>
<P>
The first line inside the <TT>try</TT>
clause is full of material; the innermost part of the clause introduces
the BufferedInputStream class:
<BLOCKQUOTE>
<TT>new BufferedInputStream(System.in)</TT>
</BLOCKQUOTE>
<P>
This subclass of FilterInputStream simply allows the reading in
of data more efficiently. Reading a file so that every byte request
requires a new input read is very slow. The BufferedInputStream
class reads data into a buffer in a series of large chunks. This
prevents each request for a byte of data resulting in a read from
the underlying input stream, such as a file or network read. If
the BufferedInputStream already has the data in the buffer, it
can return the data directly from its memory cache. This is also
useful for operations that require movement back and forth in
a stream, such as a &quot;push back&quot; of an unneeded byte.
Since this class will improve the efficiency of input stream operations,
it should be used liberally.
<P>
Once the BufferedInputStream object is created, it is used as
the constructor for a DataInputStream object:
<BLOCKQUOTE>
<TT>DataInputStream dis =<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
new DataInputStream(<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;new
BufferedInputStream(System.in));</TT>
</BLOCKQUOTE>
<P>
This code means that the DataInputStream object's request for
input is actually made to a BufferedInputStream object. This object
in turn makes its requests for input to the System.in object (which
is based on InputStream) when it needs more data.
<P>
The code can now use DataInputStream methods, such as <TT>readLine()</TT>,
to hide the underlying request of data at a byte-by-byte level.
The DataInputStream methods return the data formatted in a data
type that the user needs. In this case, <TT>readLine()</TT>
reads in a String of text delimited by a new Line (a carriage
return/line feed, or EOF). The delimiter is not included in the
stream.
<P>
The DataInputStream class supports over a dozen data type operations,
as listed in Table 4.3. These include most of the basic data types
supported from Java, ranging from a single byte to an integer
to a floating point number to a full-text String in Unicode format.
The DataInputStream class is an implementation of the DataInput
stream interface, which defines the data type methods that need
to be supported.<BR>
<P>
<CENTER><B>Table 4.3. Data-type reads supported by DataInputStream.</B></CENTER>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=186><I>Method</I></TD><TD WIDTH=306><I>Description</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>read</TT></TD>
<TD WIDTH=306>Reads data into byte array.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readBoolean</TT>
</TD><TD WIDTH=306>Reads a boolean.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readByte</TT>
</TD><TD WIDTH=306>Reads an 8-bit byte.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readChar</TT>
</TD><TD WIDTH=306>Reads a 16-bit char.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readDouble</TT>
</TD><TD WIDTH=306>Reads a 64-bit double number.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readFloat</TT>
</TD><TD WIDTH=306>Reads a 32-bit floating point number.</TD>
</TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readInt</TT>
</TD><TD WIDTH=306>Reads a 32-bit integer.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readLine</TT>
</TD><TD WIDTH=306>Reads String terminated by newline or EOF.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readLong</TT>
</TD><TD WIDTH=306>Reads a 64-bit long.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readShort</TT>
</TD><TD WIDTH=306>Reads a 16-bit short.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readUTF</TT>
</TD><TD WIDTH=306>Reads a Unicode formatted String.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readUnsignedByte</TT>
</TD><TD WIDTH=306>Reads an unsigned byte.</TD></TR>
<TR VALIGN=TOP><TD WIDTH=186><TT>readUnsignedShort</TT>
</TD><TD WIDTH=306>Reads an unsigned 16-bit short.</TD></TR>
</TABLE></CENTER>
<P>
<P>
From the powerful chaining operation supported by FilterInputStream,
it's easy to imagine interesting new possible classes. For example,
a WordProcessStream could be written to read paragraphs and images
into a word processing application.
<P>
Two other FilterInputStream classes are worth mentioning. The
LineNumberInputStream class associates the data streams with line
numbers. This means that the class supports such operations as
<TT>setLineNumber()</TT> and <TT>getLineNumber()</TT>.
The PushBackInputStream class is used for the kind of operations
that parsers typically perform. Parsers need methods such as <TT>unread()</TT>,
which pushes a character back into a stream. This kind of operation
is needed when a token has been identified by the parser.
<H4>Other InputStream classes</H4>
<P>
Although the FilterInputStream classes are the most powerful part
of the InputStream hierarchy, other classes are also useful. If
applets read from a file, an instance of the FileInputStream class
will probably be used. It includes the same operations as its
superclass, InputStream. Therefore, it can be used to pass data
to FilterInputStream classes, as in the previous section's example.
Listin