Java网络编程深入探索

需积分: 3 48 浏览量更新于2024-08-02 收藏 2.35MB PDF 举报

"这篇资源主要讨论的是高级Java网络编程，揭示了Java在处理网络应用时的强大潜力，而不仅仅是用于网页编程。它强调了Java作为替代传统痛苦编程方式的有力选择，能够减少调试时间，提高软件设计效率，使开发者有更多时间进行创新思维，将互联网的海量信息更好地整合到桌面应用中。" 在深入探讨“高级Java网络”之前，我们需要理解Java在网络编程中的基础。Java通过其强大的套接字（Socket）编程能力，提供了跨平台的网络通信支持。套接字是Java网络编程的核心，允许应用程序与其他网络上的程序进行双向通信。Java的`java.net`包包含了处理网络连接所需的所有类和接口，如Socket、ServerSocket、URL和URLConnection等。 1. **Socket编程**：Java的Socket是TCP/IP协议的实现，提供可靠的、面向连接的数据传输。Socket类代表了客户端连接，而ServerSocket类用于监听并接受来自客户端的连接请求。通过这两个类，开发者可以创建出客户端-服务器架构的应用。 2. **多线程**：在处理多个网络连接时，Java的多线程特性显得尤为重要。每个连接都可以在一个单独的线程上运行，使得服务器可以同时处理多个客户端请求，提高了服务的并发性。 3. **NIO（非阻塞I/O）**：Java的NIO库（New I/O）提供了异步I/O操作，允许程序在不阻塞当前线程的情况下读写数据，提高了性能，尤其适合高并发的网络环境。 4. **HTTP和HTTPS**：Java内置对HTTP和HTTPS的支持，使得开发基于这些协议的Web应用变得简单。`java.net.HttpURLConnection`类可以用来发送HTTP请求和接收响应，而`javax.net.ssl.HttpsURLConnection`则提供了安全的HTTPS连接。 5. **XML和SOAP**：Java与XML的紧密集成使得处理结构化数据和构建Web服务（如SOAP）成为可能。`javax.xml.parsers`和`javax.xml.transform`包提供了解析和操作XML文档的功能，而`javax.xml.soap`包则用于创建和处理SOAP消息。 6. **Java EE（企业版）**：对于更复杂的企业级网络应用，Java EE提供了一整套框架和服务，包括Servlet、JSP、EJB（Enterprise JavaBeans）、JMS（Java Message Service）等，它们用于构建分布式、可扩展的Web应用和企业信息系统。 7. **网络安全**：Java提供了一系列的安全机制来保护网络通信，如SSL/TLS加密、数字证书、以及访问控制等，这些都集成在`java.security`包中。 8. **UDP编程**：除了TCP，Java也支持无连接的UDP协议，通过`DatagramSocket`和`DatagramPacket`类实现。UDP适合于实时应用，如在线视频或音频流，因为它不保证数据的顺序和可靠性，但提供了更高的速度。 9. **RPC（远程过程调用）**：Java RMI（Remote Method Invocation）允许对象在不同的JVM之间进行远程调用，使得分布式系统开发变得更加容易。 10. **Java WebSocket**：Java提供WebSocket API来创建双向通信的长连接，允许服务器和客户端实时交换数据，常用于游戏、聊天应用或股票交易等需要低延迟的场景。 "Advanced Java Networking"涵盖了从基础的网络连接到复杂的分布式系统设计的各种主题，旨在帮助开发者充分利用Java在创建高效、安全的网络应用方面的优势。通过学习这些知识，开发者不仅可以构建出功能强大的网络应用，还能更好地利用互联网的资源，为用户提供更加丰富和创新的体验。

input end of a pipe in one application is directly connected to the output end of the

same pipe on another application. If you write to the input of the pipe, you will read

the same exact data at the pipe's output end. As you can see in Figure 1-3 this is a

pretty nifty way to promote interapplication communication.

Figure 1-3. Pipes enable interaction between two or more applications.

Last, you will eventually want to fiddle with files on your local file system. The

FileInputStream and FileOutputStream enable you to open, read, and write files as we

will show you in a moment. Remember that Java has strict restrictions on applet

security, so most file streams can be manipulated only by applications. For more

information, consult Chapter 13, "Java and Security."

The Java Core System

In Java, applications are allowed to write to the standard output devices on a machine.

If you use a Web browser such as Netscape, the standard output to which Java writes

is the "Java Console" mentioned in one of Navigator's windows. If you write a Java

application (i.e., a stand-alone applet), the standard output device is the command line

from which you execute the program.

The System Class

One of the classes Java includes in every applet or application, whether you specify

that it do so or not, is the System class. The System class provides support for

input/output (I/O) using the Java console; you are to provide the ability to write to the

console, read from the console, and write errors to the user. The Java console is

provided in two ways, one for browsers and one for applications. In the browser

environment the console is a separate browser window that has controls for scrolling

and clearing. For applications run from the operating system (OS) command line, the

console is the text interface you see and suffers the same problems as the text base OS

environment (lack of scrolling backwards). The Java console is really intended to

provide the same level of user interactivity as the C++ cin, cout, and cerr objects. The

names of the standard Java streams are in, out, and err; these names can be changed

using the System classes setIn, setOut, and setErr methods. Changing the names of

these streams can only be done by the SecurityManager.

Input Using the System Class

Input in the System class is actually handled by the InputStream class contained in the

Java I/O routines. System.in is an object of type InputStream that is created,

maintained, and initialized by the System class. In other words, it's yours for the

taking; you don't have to do a thing to use it.

The InputStream class assumes that you will be reading from the standard input

stream (the keyboard you are sitting at). A stream is a sequence of characters retrieved

from somewhere. The standard input stream is the location that your operating system

uses to get data from you. Because streams are defined as characters from a source, it

is entirely conceivable that a stream could be a file, a modem, a microphone, or even a

connection to another process running on your computer or another computer. As a

matter of fact, Java treats files and other peripherals as streams. This abstraction of a

stream simplifies I/O programming by reducing all I/O to a stream.

So, how do you get input from the user? Simply use the System class's input stream to

get the information you require. The input stream is an object with several methods to

facilitate data input. For example, there are primitive, yet useful, routines to get

characters and strings, to read integers and other numbers, and even to get a stream of

unfiltered and untranslated bytes. Deciding which routine to use is simply a matter of

which kind of data you wish to read. In our example, we will read and write strings:

public class InputOutputTest()

{

String str; //private data

public void getInput(){

// read a string from the Java console keyboard (sysin)

str = System.in.getln();

}

Output Using the System Class

As with input, output is handled through streams. How can output be a stream if a

stream is a sequence of characters from a source? Well, the source is your application,

and the stream is routed to a device known as the standard output. The standard output

is usually your monitor, but it could be other things as well. Most notably, the

standard output is set to be the Java console when an applet runs within Netscape

Navigator. When you run the following example from within an applet, watch your

Java console for the output. If you run it from within an application, the output should

show up on the command line.

public class InputOutputTest(){

String str; // classdata

public void getInput(){

// read a string from the keyboard

str = System.in.getln();

}

public void drawOutput(){

// write a string to the console screen

System.out.println(str);

}

Files

The stream classes would be pretty useless if you couldn't manipulate files as well.

There are several security mechanisms defined in the security model used by Java-

capable browsers for running applets. These mechanisms prevent unguarded file

access and will be discussed in more depth in Chapter 13, "Java and Security." But for

now, simply assume that as long as you are not writing an applet, you will be able to

manipulate files. In the purest sense, standard input and output are files. As such, they

are sometimes subject to the same applet security restrictions, so be forewarned.

The Basics

When reading and writing to and from files, there are three steps that must be

followed:

1. Open the file for reading or writing.

2. Read or write from the file.

3. Close the file.

It is important to do each step. Failing to open a file will, obviously, prevent you from

reading. But perhaps not as intuitively, you must still close the file or you may wreck

your file system. Every application is allowed a certain number of file descriptors

(handles) that maintain the status of a file. If you run out of available file descriptors,

you will no longer be able to open any other files. The following snippet uses the

FileReader class to read the contents of a file specified on the command line and the

PrintWriter class to write it to the Java console:

import java. io.*;

public class ShowFile{

public static void main (Stringargs[]){

try{

FileReader fin = new FileReader(args[0]);

PrintWriter consoleOut = new PrintWriter(System.out, true);

char c[] = new char[512];

int count = 0;

while ((count=fin.read(c))!=-1)

consoleOut.write(c,0,count);

consoleOut.flush();

consoleOut.close();

fin.close();

}

catch(FileNotFoundException e){

System.out.println(e.toString());

}

catch(IOException e) {

System.out.println(e.toString());

The AWT is a half-baked attempt to create a user interface toolbox for programmers.

Because all the various classes, containers, and widgets in the toolkit are capable of

being used both in the applets embedded in Web pages and in the stand-alone

applications on your desktop, it is a powerfully extensible tool. At the heart of this

kind of flexibility is the idea that the toolkit is an abstraction—in other words, a layer

on top of your current windowing system. This abstraction is more understandable if

you know the background behind it. When Sun was courting its early customers,

Netscape insisted that the Java Virtual Machine (JVM) included in its browser must

create widgets that had the exact look and feel of the host operating system's widgets.

Since "Swing" wasn't yet a gleam in its father's eye, the only way to accomplish this

was to use the peer components of the host operating system. Thus we can truly say

that the AWT is an abstraction of the windowing system of the operating system.

Your current windowing system may be anything from X11/Motif to Windows 95's

own window system. In any event, the AWT ensures that native calls are made to

these windowing systems in order to allow applications to run on top of the desktop.

For applets within a Web page, the browser manufacturer essentially creates a

windowing system that renders the AWT's widgets within itself.

The end result of all this is that eventually a native call is made for each action taken

by the AWT. Your applications need not be aware of this, for Java's platform

independence ensures that, no matter the platform on which you execute bytecodes,

the results will be identical.

One of the problems with this approach to user interface (UI) implementation is that

when making a UI that must be rendered the same way on all the platforms it is to be

targeted to, small differences in the way that components are rendered on each of the

targeted systems may cause the overall effect to have problems. For instance, a UI

having several closely aligned text fields may look good on Windows platforms but

appear overlayed on UNIX machines.

One of the major complaints about the AWT by people used to building user

interfaces for enterprise applications was that it had a relatively small set of widgets

and low functionality. AWT provided only slightly more functionality than the

widgets provided in HTML's forms controls. In early 1997 the work on JDK 1.1

incorporated a number of new pieces including Netscape Corporation's Internet

Foundation Classes (IFC), components from IBM's Taligent Division, and Lighthouse

Design. The first release of Swing 1.0 in early 1998 contained almost 250 classes and

80 interfaces. The art of user interface creation had been raised to a new level and was

now able to go head to head with platform-specific development tools.

The Java 1.2 platform provides a set of components (Swing) that eliminate this

problem by eliminating the use of peer components. The Swing components are pure

Java and will render reliably on all host platforms. With Swing the native look and

feel of Windows, Motif, or Mac widgets are options from a predefined list of look and

feels that are extensible by the user.

Input Alternatives

剩余362页未读，继续阅读

cutesource

粉丝: 5045
资源: 12

Java网络编程深入探索

Advanced JAVA Networking.pdf(2nd Edition)

Advanced JAVA Networking

advanced java networking

advanced-networking:对各种云的高级网络支持

Core Java. Volume II. Advanced Features_ 8th Edition

Core Java(Volume II--Advanced Features 9th Edition)

Core.Java.Vol.2.Advanced.Features.8th.Edition.pdf

udemy-android-advanced

500 JAVA Tips

Java for Programmers

最新资源