appendixb.html
来自「java 是一个很好的网络开发环境。由于它是通过解释的方法」· HTML 代码 · 共 463 行 · 第 1/2 页
HTML
463 行
against any other <B>synchronized</B> method using that object and
“unlocks” the object only upon exiting the method. There are no
explicit locks; they happen automatically. You’re still responsible for
implementing more sophisticated synchronization between threads by creating your
own “monitor” class. Recursive <B>synchronized</B> methods work
correctly. Time slicing is not guaranteed between equal priority
threads.</FONT><LI><FONT FACE="Georgia"> Instead of controlling blocks of
declarations like C++ does, the access specifiers (<B>public</B>,
<B>private</B>, and <B>protected</B>) are placed on each definition for each
member of a class. Without an explicit access specifier, an element defaults to
“friendly,” which means that it is accessible to other elements in
the same package (equivalent to them all being C++ <B>friend</B>s) but
inaccessible outside the package. The class, and each method within the class,
has an access specifier to determine whether it’s visible outside the
file. Sometimes the <B>private </B>keyword is used less in Java because
“friendly” access is often more useful than excluding access from
other classes in the same package. (However, with multithreading the proper use
of <B>private</B> is essential.) The Java <B>protected</B> keyword means
“accessible to inheritors <I>and</I> to others in this package.”
There is no equivalent to the C++ <B>protected </B>keyword that means
“accessible to inheritors<I> only</I>” (<B>private protected</B>
used to do this, but the use of that keyword pair was
removed).</FONT><LI><FONT FACE="Georgia"> Nested classes. In C++, nesting
a class is an aid to name hiding and code organization (but C++ namespaces
eliminate the need for name hiding). Java packaging provides the equivalence of
namespaces, so that isn’t an issue. Java 1.1<A NAME="Index3114"></A> has
<I>inner classes</I> that look just like nested classes. However, an object of
an inner class secretly keeps a handle to the object of the outer class that was
involved in the creation of the inner class object. This means that the inner
class object may access members of the outer class object without qualification,
as if those members belonged directly to the inner class object. This provides a
much more elegant solution to the problem of callbacks, solved with pointers to
members in C++.</FONT><LI><FONT FACE="Georgia"> Because of inner classes
described in the previous point, there are no pointers to members in
Java.</FONT><LI><FONT FACE="Georgia"> No <B>inline</B> methods. The Java
compiler might decide on its own to inline a method, but you don’t have
much control over this. You can suggest inlining in Java by using the
<B>final</B> keyword for a method. However, <B>inline</B> functions are only
suggestions to the C++ compiler as
well.</FONT><LI><FONT FACE="Georgia"> Inheritance in Java has the same
effect as in C++, but the syntax is different. Java uses the <B>extends</B>
keyword to indicate inheritance from a base class and the <B>super</B> keyword
to specify methods to be called in the base class that have the same name as the
method you’re in. (However, the <B>super</B> keyword in Java allows you to
access methods only in the parent class, one level up in the hierarchy.)
Base-class scoping in C++ allows you to access methods that are deeper in the
hierarchy). The base-class constructor is also called using the <B>super</B>
keyword. As mentioned before, all classes are ultimately automatically inherited
from <B>Object</B>.<B> </B>There’s no explicit constructor initializer
list like in C++, but the compiler forces you to perform all base-class
initialization at the beginning of the constructor body and it won’t let
you perform these later in the body. Member initialization is guaranteed through
a combination of automatic initialization and exceptions for uninitialized
object handles.</FONT>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>public</font> <font color=#0000ff>class</font> Foo <font color=#0000ff>extends</font> Bar {
<font color=#0000ff>public</font> Foo(String msg) {
<font color=#0000ff>super</font>(msg); <font color=#009900>// Calls base constructor</font>
}
<font color=#0000ff>public</font> baz(<font color=#0000ff>int</font> i) { <font color=#009900>// Override</font>
<font color=#0000ff>super</font>.baz(i); <font color=#009900>// Calls base method</font>
}
}</PRE></FONT></BLOCKQUOTE>
<LI><FONT FACE="Georgia"> Inheritance in Java doesn’t change the
protection level of the members in the base class. You cannot specify
<B>public</B>, <B>private</B>, or <B>protected</B> inheritance in Java, as you
can in C++. Also, overridden methods in a derived class cannot reduce the access
of the method in the base class. For example, if a method is <B>public</B> in
the base class and you override it, your overridden method must also be
<B>public</B> (the compiler checks for
this).</FONT><LI><FONT FACE="Georgia"> Java provides the <B>interface</B>
keyword, which creates the equivalent of an abstract base class filled with
abstract methods and with no data members. This makes a clear distinction
between something designed to be just an interface and an extension of existing
functionality via the <B>extends</B> keyword. It’s worth noting that the
<B>abstract</B> keyword produces a similar effect in that you can’t create
an object of that class. An <B>abstract</B> class <I>may</I> contain abstract
methods (although it isn’t required to contain any), but it is also able
to contain implementations, so it is restricted to single inheritance. Together
with interfaces, this scheme prevents the need for some mechanism like virtual
base classes in C++.</FONT><BR><FONT FACE="Georgia">To create a version of
the <B>interface</B> that can be instantiated, use the <B>implements
</B>keyword, whose syntax looks like inheritance:</FONT>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>public</font> <font color=#0000ff>interface</font> Face {
<font color=#0000ff>public</font> <font color=#0000ff>void</font> smile();
}
<font color=#0000ff>public</font> <font color=#0000ff>class</font> Baz <font color=#0000ff>extends</font> Bar <font color=#0000ff>implements</font> Face {
<font color=#0000ff>public</font> <font color=#0000ff>void</font> smile( ) {
System.out.println(<font color=#004488>"a warm smile"</font>);
}
}</PRE></FONT></BLOCKQUOTE>
<LI><FONT FACE="Georgia"> There’s no <B>virtual</B> keyword in Java
because all non-<B>static</B> methods always use dynamic binding. In Java, the
programmer doesn’t have to decide whether to use dynamic binding. The
reason <B>virtual</B> exists in C++ is so you can leave it off for a slight
increase in efficiency when you’re tuning for performance (or, put another
way, “If you don’t use it, you don’t pay for it”), which
often results in confusion and unpleasant surprises. The <B>final</B> keyword
provides some latitude for efficiency tuning – it tells the compiler that
this method cannot be overridden, and thus that it may be statically bound (and
made inline, thus using the equivalent of a C++ non-<B>virtual</B> call). These
optimizations are up to the compiler.</FONT><LI><FONT FACE="Georgia"> Java
doesn’t provide multiple inheritance (MI), at least not in the same sense
that C++ does. Like <B>protected</B>, MI seems like a good idea but you know you
need it only when you are face to face with a certain design problem. Since Java
uses a singly-rooted hierarchy, you’ll probably run into fewer situations
in which MI is necessary. The <B>interface</B> keyword takes care of combining
multiple interfaces.</FONT><LI><FONT FACE="Georgia"> Run-time type
identification functionality is quite similar to that in C++. To get information
about handle <B>X,</B> you can say, for
example:</FONT><BR><TT><FONT FACE="Courier New">X.getClass().getName();</FONT></TT><BR><FONT FACE="Georgia">To
perform a type-safe downcast you
say:</FONT><BR><TT><FONT FACE="Courier New">derived d =
(derived)base;</FONT></TT><BR><FONT FACE="Georgia">just like an old-style
C cast. The compiler automatically invokes the dynamic casting mechanism without
requiring extra syntax. Although this doesn’t have the benefit of easy
location of casts as in C++ “new casts,” Java checks usage and
throws exceptions so it won’t allow bad casts like C++ does.
</FONT><LI><FONT FACE="Georgia"> Exception handling in Java is different
because there are no destructors. A <B>finally</B> clause can be added to force
execution of statements that perform necessary cleanup. All exceptions in Java
are inherited from the base class <B>Throwable</B>, so you’re guaranteed a
common interface.</FONT>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>public</font> <font color=#0000ff>void</font> f(Obj b) <font color=#0000ff>throws</font> IOException {
myresource mr = b.createResource();
<font color=#0000ff>try</font> {
mr.UseResource();
} <font color=#0000ff>catch</font> (MyException e) {
<font color=#009900>// handle my exception</font>
} <font color=#0000ff>catch</font> (Throwable e) {
<font color=#009900>// handle all other exceptions</font>
} <font color=#0000ff>finally</font> {
mr.dispose(); <font color=#009900>// special cleanup</font>
}
}</PRE></FONT></BLOCKQUOTE>
<LI><FONT FACE="Georgia"> Exception specifications in Java are vastly
superior to those in C++. Instead of the C++ approach of calling a function at
run-time when the wrong exception is thrown, Java exception specifications are
checked and enforced at compile-time. In addition, overridden methods must
conform to the exception specification of the base-class version of that method:
they can throw the specified exceptions or exceptions derived from those. This
provides much more robust exception-handling
code.</FONT><LI><FONT FACE="Georgia"> Java has method overloading, but no
operator overloading. The <B>String</B> class does use the <B>+</B> and <B>+=
</B>operators to concatenate strings and <B>String </B>expressions use automatic
type conversion, but that’s a special built-in
case.</FONT><A NAME="OLE_LINK7"></A><LI><FONT FACE="Georgia"> The
<B>const</B> issues in C++ are avoided in Java by convention. You pass only
handles to objects and local copies are never made for you automatically. If you
want the equivalent of C++’s pass-by-value, <A NAME="OLE_LINK8"></A>you
call <B>clone( )</B> to produce a local copy of the argument (although the
<B>clone( ) </B>mechanism is somewhat poorly designed – see Chapter
12). There’s no copy-constructor that’s automatically called. To
create a compile-time constant value, you say, for example:</FONT>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE><font color=#0000ff>static</font> <font color=#0000ff>final</font> <font color=#0000ff>int</font> SIZE = 255;
<font color=#0000ff>static</font> <font color=#0000ff>final</font> <font color=#0000ff>int</font> BSIZE = 8 * SIZE;</PRE></FONT></BLOCKQUOTE>
<LI><FONT FACE="Georgia"> Because of security issues, programming an
“application” is quite different from programming an
“applet.” A significant issue is that an applet won’t let you
write to disk, because that would allow a program downloaded from an unknown
machine to trash your disk. This changes somewhat with Java
1.1<A NAME="Index3115"></A> digital signing, which allows you to unequivocally
<I>know</I> everyone that wrote all the programs that have special access to
your system (one of which might have trashed your disk; you still have to figure
out which one and what to do about it.). Java 1.2 also promises more power for
applets</FONT><LI><FONT FACE="Georgia"> Since Java can be too restrictive
in some cases, you could be prevented from doing important tasks such as
directly accessing hardware. Java solves this with <I>native methods</I> that
allow you to call a function written in another language (currently only C and
C++ are supported). Thus, you can always solve a platform-specific problem (in a
relatively non-portable fashion, but then that code is isolated). Applets cannot
call native methods, only
applications.</FONT><LI><FONT FACE="Georgia"> Java has built-in support
for comment documentation, so the source code file can also contain its own
documentation, which is stripped out and reformatted into HTML via a separate
program. This is a boon for documentation maintenance and
use.</FONT><LI><FONT FACE="Georgia"> Java contains standard libraries for
solving specific tasks. C++ relies on non-standard third-party libraries. These
tasks include (or will soon
include):</FONT><BR><FONT FACE="Georgia">–
Networking</FONT><BR><FONT FACE="Georgia">– Database Connection (via
JDBC)</FONT><BR><FONT FACE="Georgia">–
Multithreading</FONT><BR><FONT FACE="Georgia">– Distributed Objects
(via RMI and CORBA)</FONT><BR><FONT FACE="Georgia">–
Compression</FONT><BR><FONT FACE="Georgia">–
Commerce</FONT><BR><FONT FACE="Georgia">The availability and standard
nature of these libraries allow for more rapid application
development.</FONT><LI><FONT FACE="Georgia"> Java 1.1 includes the Java
Beans standard, which is a way to create components that can be used in visual
programming environments. This promotes visual components that can be used under
all vendor’s development environments. Since you aren’t tied to a
particular vendor’s design for visual components, this should result in
greater selection and availability of components. In addition, the design for
Java Beans is simpler for programmers to understand; vendor-specific component
frameworks tend to involve a steeper learning
curve.</FONT><LI><FONT FACE="Georgia"> If the access to a Java handle
fails, an exception is thrown. This test doesn’t have to occur right
before the use of a handle; the Java specification just says that the exception
must somehow be thrown. Many C++ runtime systems can also throw exceptions for
bad pointers.</FONT><LI><FONT FACE="Georgia"> Generally, Java is more
robust, via:</FONT><BR><FONT FACE="Georgia">– Object handles
initialized to <B>null</B> (a
keyword)</FONT><BR><FONT FACE="Georgia">– Handles are always checked
and exceptions are thrown for
failures</FONT><BR><FONT FACE="Georgia">– All array accesses are
checked for bounds violations</FONT><BR><FONT FACE="Georgia">–
Automatic garbage collection prevents memory
leaks</FONT><BR><FONT FACE="Georgia">– Clean, relatively fool-proof
exception handling</FONT><BR><FONT FACE="Georgia">– Simple language
support for multithreading</FONT><BR><FONT FACE="Georgia">– Bytecode
verification of network
applets</FONT></OL><DIV ALIGN="LEFT"><P><A NAME="Appendix_C"></A><A NAME="_Toc375545509"></A><BR></P></DIV>
<DIV ALIGN="CENTER">
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixA.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="AppendixC.html">Next Chapter</a> ]
</FONT>
<BR>
Last Update:02/04/2000</P></DIV>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?