ch1.htm

JAVA Developing Professional JavaApplets

is so strict, many errors that would otherwise appear at runtime
are caught at compilation. Since runtime bugs are potentially
dangerous and can be time-consuming and difficult to track down,
it's good to catch as many mistakes as possible during compilation.
Java's strict compiler is one reason the environment is said to
be <I>robust</I>.
<H4>Second Security Layer: The ByteCode Verifier</H4>
<P>
The bytecode verifier is the most critical line of defense in
the Java security system. If a rogue class can get through this
layer, you could be in real trouble! However, this is unlikely.
The verifier uses various techniques, including a theorem prover,
to ensure that the bytecodes of the class being loaded do not
violate any of the structural constraints Java places on incoming
code. The verifier is, therefore, positioned to catch any potential
malicious actions caused by bytecodes produced by a hostile compiler
or subject to post-compilation tampering.
<P>
Verification goes through a couple of steps. The first step is
to verify the format of the incoming file to make sure it is indeed
a Java class and has been properly constructed. The next step
is much more complex. The verifier basically sets out to prove
that the code has a variety of properties. If the bytecodes make
it through this phase of the verifier, then you'll know the following
things:
<UL>
<LI><FONT COLOR=#000000>The code does not cause stack overflows
or underflows.</FONT>
<LI><FONT COLOR=#000000>The operand types of the bytecode opcodes
are proper. For example, an opcode that works with an integer
operand cannot have an operand that is an object reference.</FONT>
<LI><FONT COLOR=#000000>No illegal casting is attempted.</FONT>
<LI><FONT COLOR=#000000>Object access rules are followed.</FONT>
</UL>
<P>
As a result of these properties being proved, the runtime system
will know a couple of other important things, the most important
being no forged pointers in the code.
<P>
A beneficial side effect of the verification process is that the
interpreter is free from performing many of these checks as the
code is being executed. For example, it does not need to conduct
expensive checks to see if a stack overflow is about to occur.
Because such checks are not necessary, the interpreter will run
much faster.
<P>
Another security-related step occurs when the interpreter loads
the verified bytecodes. When the interpreter brings in a class,
it defines the <I>memory layout</I> of the class. Recall that
this is a feature of Java's dynamic linking used to solve the
&quot;fragile superclass&quot; problem. Dynamic linking also has
a security advantage. In traditional languages, memory is laid
out at compile time. A malicious programmer, knowing the layout
of memory in the executable code, could then tamper with the pointers
to get around security problems. Since Java performs memory layout
at runtime, however, this potential security bypass is thwarted.
<H4>Third Security Layer: The Class Loader</H4>
<P>
After a class is verified, it's ready for runtime use. The Class
Loader brings each class into a unique <I>namespace</I> that corresponds
to its origin. The default namespace is for classes that come
from the local file system. Such classes are called <I>built-ins</I>;
they can never be replaced by a class that comes from an external
source because there is a separate namespace for each network
source of classes. When a class is referenced, Java looks first
for a built-in class. If it isn't found, then Java inspects the
namespace of the referencing class. This approach prevents network
classes from replacing a built-in, or a class from one network
source overriding one from another source. The security implications
of this approach are subtle but important. Java tries to implement
as much as possible through Java classes; for example, the Security
Manager module is represented by a SecurityManager class, you
get access to system resources through the System class, and,
as will be seen shortly, class loader policies are implemented
by ClassLoader classes. By preventing built-ins from being overridden,
Java protects critical modules, such as the SecurityManager or
System. It's easy to imagine what could happen if a network class
was allowed to replace the SecurityManager class.
<P>
Subclasses of the ClassLoader class are used to enforce namespace
policies. The Class Loader system can consist of multiple instances
of ClassLoader subclasses. For example, one Class Loader can be
used for classes brought from inside a firewall, but another Class
Loader class can be used for those brought in from the Internet.
The local file system, by default, does not use a ClassLoader
class. Instead, it searches for classes in directories listed
in the <TT>CLASSPATH</TT> environment
variable; you can modify this path to include the directories
that have your classes. Keep in mind that there's a subtle difference
between the Class Loader mechanism, which applies to the entire
Java runtime environment, and instances of the ClassLoader class,
which implement specific policies.
<H4>Fourth Security Layer: The Security Manager</H4>
<P>
Even after a chunk of bytecode has gotten past the verifier and
the class loader, it is still technically in a position to cause
some damage. Suppose that a class downloaded from the Internet
has some code to delete files from your hard disk. This can be
done legitimately by calling the <TT>delete()</TT>
method of the File class and so will pass the verifier and class
loader. Fortunately, the final security layer, represented by
the SecurityManager class (also known as the Security Manager),
will prevent this from occurring. The Security Manager is responsible
for enforcing a set of policies for protecting the runtime environment
from unauthorized transactions. Whenever a potentially &quot;dangerous&quot;
action is about to happen, the Security Manager is asked for authorization
to perform the action. Based on how the manager is implemented,
the action may be denied or granted.
<P>
Different browsers and applet viewers can use the Security Manager
in an appropriate way. Once installed into the runtime system,
the Security Manager cannot be replaced. These browsers may grant
levels of authorization for different actions. For example, the
Netscape Navigator has a very conservative Security Manager. The
most dangerous class of actions, those of reading and writing
from the hard disk, are prohibited altogether. On the other hand,
the HotJava browser has a more flexible configuration. It can
be set up to grant full disk access from applets loaded locally,
some access to applets loaded from within the firewall, and no
access for those brought in over the Internet.
<P>
A wide variety of actions are subject to authorization by the
Security Manager. When a class is asked to perform a potentially
dangerous action, such as a file delete, it will ask the SecurityManager
class for authorization. If it isn't permitted, a security exception
will occur. Besides all file-related activities, the actions of
the most importance to security are network accesses. Once more,
restrictions are usually based on how the SecurityManager is set
up, but there are a few generalities. An applet loaded over the
Internet can connect only to the host from which it originated;
it will not be allowed to connect to anywhere from inside the
client's firewall, nor will it be permitted to use the client
to act as a launching pad into some other Internet site. An applet
is also prevented from running as a network server (this has some
implications that are explored later). Restrictions enforced by
the SecurityManager will be discussed throughout the book as the
appropriate topics dictate.
<H2><A NAME="GeneralFeaturesoftheJavaProgramming"><FONT SIZE=5 COLOR=#FF0000>General
Features of the Java Programming Language</FONT></A></H2>
<P>
You will now be guided through a very quick tour of the basics
of the Java language. If you have experience with C or C++, then
much will be familiar-you might want to skip over parts of this
section. If you don't know these languages, don't worry. The basic
mechanics of the language are easy, and you will see many examples
throughout the book. Discussion of classes, methods, and objects
will be postponed until the next chapter.
<H3><A NAME="DataTypes">Data Types</A></H3>
<P>
As stated earlier, everything in Java is an object. The <I>partial</I>
exception to this is the primitive data types. These data types
have a standard size across all platforms; this standardization
is a key aspect of Java's portability. Table 1.1 lists the primitive
data types.<BR>
<P>
<CENTER><B>Table 1.1. Primitive Java data types.</B></CENTER>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=88><I>Data Type</I></TD><TD WIDTH=150><I>Size</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>byte</TT></TD>
<TD WIDTH=150>8-bit</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>short</TT></TD>
<TD WIDTH=150>16-bit</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>int</TT></TD>
<TD WIDTH=150>32-bit</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>long</TT></TD>
<TD WIDTH=150>64-bit</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>float</TT></TD>
<TD WIDTH=150>32-bit floating point</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>double</TT></TD>
<TD WIDTH=150>64-bit floating point</TD></TR>
<TR VALIGN=TOP><TD WIDTH=88><TT>char</TT></TD>
<TD WIDTH=150>16-bit Unicode</TD></TR>
</TABLE></CENTER>
<P>
<P>
If you are a C or C++ programmer, you might have noticed a couple
of things. First of all, there is no <TT>unsigned</TT>
type specifier. The <TT>char</TT>
data type has been replaced by the <TT>byte</TT>
primitive. The <TT>char</TT> type
is now 16 bits, instead of the old 8 bits, because Java bases
character data on the Unicode character set. Unicode is a standard
that supports international characters, thus broadening the potential
base in which your application can run. Although Unicode is a
much broader standard than ASCII, you will probably have many
opportunities to program in the 8-bit standard. Some default class
behavior and localization methods will be available for doing
this. This book will focus on ASCII output.
<P>
The only primitive data type not in Table 1.1 is <TT>boolean</TT>.
A <TT>boolean</TT> variable cannot
be converted to a number and has only two values: <TT>true</TT>
or <TT>false</TT>.
<P>
You might have noticed that these primitive data types present
a <I>partial</I> exception to Java's pure object-oriented nature.
It is &quot;partial&quot; because Java has a suite of classes
used to encapsulate these data types as objects. These classes
are called <I>type wrappers</I> and are discussed in <A HREF="ch2.htm" >Chapter 2</A>,
&quot;Object-Oriented Development in Java.&quot;
<H3><A NAME="Literals">Literals</A></H3>
<P>
<I>Literals</I> are used to represent the primitive types. Integers
are defined in a manner similar to C. They can be literally set
to a decimal value, such as 10. A hexadecimal value is indicated
with a leading 0x; 15 is represented by 0xF. Octal values (base
8) are prefaced by 0.
<P>
Floating point numbers are represented by the standard decimal
point notation, such as 3.1415. These can be stored as a 32-bit
<TT>float</TT> or a 64-bit <TT>double</TT>;
the latter is the default. The notation style of 6.1D or 6.1F
can also be used to designate the number as a <TT>double</TT>
or <TT>float</TT>, respectively.
<P>
Characters can be represented by a single character in quotes
such as <TT>'a'</TT>. Escape sequences
are used to represent special characters and are preceded by a
backslash (<TT>\</TT>). For example,
tab is <TT>\t</TT>, newline is <TT>\n</TT>,
and so forth. See your Java references for a listing of all the
escape characters.
<P>
The last literal is not based on a primitive data type. Strings
are represented by zero or more characters in double quotes. An
example is <TT>&quot;This is a Java book!&quot;</TT>.
The literal string can also use escape characters. For example,
to add a new line to the previous example you would write: <TT>&quot;This
is a Java book!\n&quot;</TT>.
<P>
String literals are implemented as objects of the String class.
Operations on strings do not occur on character arrays (as in
C), but through class methods; these operations are discussed
in more detail in the next chapter.
<H3><A NAME="Variables">Variables</A></H3>
<P>
Java has three types of variables: <I>instance</I>, <I>class</I>,
and <I>local</I>. The first two types are talked about in the
next chapter in the context of the discussion on classes. Local
variables can be declared inside methods or blocks. <I>Blocks</I>
are statements appearing in braces { }. Any local variable declared
inside a left brace is valid until the right brace, at which point
the variable goes out of scope.
<P>
Individual variables are declared in the general format:
<BLOCKQUOTE>
<TT>&lt;type&gt; &lt;variable name&gt;</TT>
</BLOCKQUOTE>
<P>
For example, to declare a <TT>double</TT>
called pi:
<BLOCKQUOTE>
<TT>double pi;</TT>
</BLOCKQUOTE>
<P>
You can also asign a value to it:
<BLOCKQUOTE>
<TT>double pi = 3.1415;</TT>
</BLOCKQUOTE>
<P>
Variable names are prefaced by letters, an underscore, or a dollar
sign. They can use most characters, including numbers. However
some symbols, such as those used in operators, should not be used.