Effective Java 2.0_ in Chinese and English _ the first chapter __java

Article Author: Tyan
Blog: noahsnail.com Chapter 1 Introduction

This book are designed to help with the most effective use of the JAVATM programming language and its fundamental libra Ries, Java.lang, Java.util, and, to a lesser extent, java.util.concurrent and java.io. The book discusses, libraries, but it does not cover graphical user interface programming, ENTERPRI Se APIs, or mobile devices.

The purpose of this book is to help you make the most effective use of the Java programming language and its base library, Java.lang,java.util, to a lesser extent, including java.util.concurrent and java.io. This book sometimes discusses other libraries, but does not include graphical user interface programming, Enterprise APIs, or mobile devices.

This book consists to seventy-eight items, each of which conveys one rule. The rules capture practices generally held to is beneficial by the best and most experienced. The items are loosely grouped into ten chapters, each concerning one broad aspect of software. The book isn't intended to being read from cover to Cover:each item stands on it own, more or less. The items are heavily cross-referenced can easily plot your own course the book.

This book contains 78 entries, each of which conveys a rule. These rules are usually derived from the practice and the best experienced programmers believe it to be useful. These items are loosely divided into 10 chapters, each of which is an extension of the software design. This book is not intended to be read from beginning to end, and each item is more or less dependent on itself. The cross references between these entries are very serious, so you can easily divide your progress through this book.

Many new features were added to the platform in Java 5 (release 1.5). The Most of the "items in" book is in some way. The following table shows you where to go for primary coverage of these features:

The Java 5 platform adds many new features. Most of the entries in this book use these features in some way. The following table lists the location of these new features in this book:

Most items are illustrated with program examples. A key feature of this book are that it contains the code examples illustrating many design patterns and idioms. Where appropriate, they are cross-referenced to the standard reference into this area [work].

Most entries are explained by a program instance. An important feature of this book is that it contains code examples that illustrate many design patterns and idioms. Where these entries are placed is appropriate, and they are cross-referenced to the standard reference works in this field [Gamma 95].

Many items contain one, or more, examples illustrating some practice to be avoided. Such examples, sometimes known as antipatterns, are clearly labeled with a comment Such as "//Never do this!" In each case, the item explains why the example are bad and suggests a alternative approach.

Many entries contain one or more instances of the program that are used to indicate that some should be avoided in practice. These examples are all added with clear annotations such as "//Never do this!", and sometimes these examples are also referred to as inverse patterns. In each case, this entry explains why this example is not good and suggests an alternative approach.

This book isn't for Beginners:it assumes, are already comfortable with the Java programming language. If you are not are, consider one of the many fine introductory texts [ARNOLD05, Sestoft05]. While the book are designed to being accessible to anyone with a working knowledge of the language, it should provide for Thought even for advanced programmers.

This book is not for beginners: It assumes you are already familiar with the Java programming language. If you are unfamiliar with the Java language, consider one of the many good introductory books [Arnold05, Sestoft05]. While the goal of this book is anyone with practical Java programming experience, it should be able to provide something to think about, even for advanced programmers.

Most of the rules in this book derive from few fundamental principles. Clarity and simplicity are of paramount importance. The user of a module should never is surprised by its behavior. Modules should be as small as possible but no smaller. (as used in this book, the term module refers to all reusable software component, from a individual method to a complex s Ystem consisting of multiple packages.) Code should be reused rather than copied. The dependencies between modules should is kept to a minimum. Errors should is detected as soon as possible after they are made, ideally at compile time.

Most of the rules in this book derive from some basic principles. Simplicity and clarity are the most important. The user of the module should not be surprised by its behavior. Modules should be as small as possible, but not smaller. (The term module used in this book refers to any reusable software component, from a single method to a complex system composed of multiple packages). The code should be reused rather than copied. Dependencies between modules are kept to a minimum. Errors should be detected as early as possible and ideally found at compile time.

While the "rules in" book does not apply to percent of the time, they does characterize best programming practices in the great majority of cases. You should the slavishly follow these rules, but violate them only occasionally and with good reason. Learning The art of programming, like most to other disciplines, consists of the the "the" and "Learning" when To break them.

Although the rules in this book cannot be applied to any time, in most cases they are characterized by the best programming practices. You should not follow these rules blindly, but only occasionally violate them when there is sufficient reason. Like most other disciplines, learning the art of programming involves learning the rules first, and then learning when to break the rules.

For the "most part", this book isn't about performance. It is about writing programs that are clear, correct, usable, robust, flexible, and maintainable. If you can does that, it's usually a relatively simple matter to get the performance you need (Item 55). Some items do discuss performance concerns, and a few of these items provide performance. These are numbers, which are introduced with the phrase "in my machine," should is regarded as approximate at best.

Most of the book is not about performance. It is about writing clear, correct, usable, robust, resilient, and maintainable programs. If you can do this, to get the performance you need it is usually relatively simple (entry 55). Some of the entries discuss performance concerns, some of which provide performance indicators. These indices should be considered as the best approximation, and these indices are introduced using the words "on my Machine".

For what it's worth, my machine is a aging homebuilt 2.2 GHz Dual-core AMD OPTERONTM 170 with 2 gigabytes of RAM, running Sun ' s 1.6_05 release of the Java SE Development Kit (JDK) atop Microsoft windows®xp Professional SP2. This JDK has two virtual machines, the Java Hotspottm Client and Server VMs. Performance numbers were measured on the Serv Er VM.

Notably, my machine is an old assembled computer, 2.2G Hertz Dual-core AMD Hao long processor 170,2g memory, running the Sun's JDK 1.6_05 version on Microsoft's Windows XP SP2. The JDK has two virtual machines, a Java hot swap client and a server virtual machine. The performance metrics are measured on the server virtual machine.

When discussing features of the Java programming language and its libraries, it's sometimes necessary to refer C releases. For brevity, this book uses the "Engineering version numbers" in preference to official release names. This table shows the mapping between release names and engineering version numbers.

When discussing the characteristics of the Java programming language and its libraries, it is sometimes necessary to indicate a specific version. For brevity, this book uses the project version number rather than the official release name. The following table shows the mapping relationship between the release name and the project version number.

The examples are reasonably complete, but they and favor readability over completeness. They freely use classes from the packages Java.util and java.io. In order to compile the examples, you could have to add one or more of this import statements:

While these examples are fairly complete, they focus on readability over completeness. They can be very free to use the classes in the package Java.util and java.io. To compile these examples, you may have to add one or more import declarations:

Import java.util.*;
Import java.util.concurrent.*;
Import java.io.*;

The other boilerplate is similarly omitted. The book ' s Web site, http://java.sun.com/docs/books/effective, contains a expanded version of each example, which can Compile and run.

Similar omissions are also available in other examples. This book's website: Http://java.sun.com/docs/books/effective, contains an extended version of each example that you can compile and run.

For the most part, this book uses technical terms as they are defined in the Java Language specification, third Edition [J LS]. A few terms deserve special mention. The language supports four kinds of types:interfaces (including annotations), classes (including enums), arrays, and prim Itives. The three are known as reference types. Class instances and arrays are objects; Primitive values are not. A class ' s members consist of their fields, methods, member classes, and member interfaces. A method ' s signature consists of its name and the types of its formal parameters; The signature does not include the "method" s return type.

Most of the technical terms in this book are the same as the terminology in the Java Language Specification (third edition). Some terminology needs to be highlighted. The Java language supports four types: interfaces (including annotations), classes (including enumerations), arrays, and basic types. The first three are reference types. class instances and arrays are objects, and the base type is not. A class member consists of its domain, method, member class, and member interface. The signature of the method consists of its name, the formal parameter type, and the signature does not include the return value type of the method.

This book uses a few terms differently from the Java Language specification. Unlike the Java Language specification, this book uses inheritance as a synonym for subclassing. Instead of using the term inheritance for interfaces, this book simply states that a class implements a interface or One interface extends another. To describe the "access level", "applies is specified", this book uses the descriptive term Package-private Inst EAD of the technically correct term default access [JLS, 6.6.1].

This book uses a number of terms that are different from the Java language specification. Unlike the Java language Specification, this book uses inheritance as a synonym for subclasses. No longer uses the terminology of interface inheritance, this book simply describes a class that implements an interface or an interface that extends another interface. To describe a situation where there is no specified access level, this book uses the term package private instead of the technically correct term default access [JLS, 6.6.1].

This book uses a few technical terms which are not defined in the Java Language specification. The term exported API, or simply API, refers to the classes, interfaces, constructors, members, and serialized forms by WH Ich a programmer accesses a class, interface, or package. (The term API, which is short for application programming interface, are used in preference to the otherwise preferable M interface to avoid confusion and the language construct of that name.) A programmer who writes a program that uses the API is referred to as a user of the API. A class whose implementation uses API is a client of the API.

This book uses terms that are not defined by some Java language specifications. The term exported API or simply API, refers to classes, interfaces, constructors, members, serialization forms, through which programmers access classes, interfaces, or packages. (The Terminology API, an abbreviation for the application interface, uses APIs rather than other terminology interfaces that others prefer, to avoid confusion with interfaces in the Java language.) Programmers write programs that use APIs to refer to users of APIs. Class to implement a client called an API that uses the API.

Classes, interfaces, constructors, members, and serialized forms are collectively as API known. An exported API consists to the API elements that are accessible outside of the package the API. These are the API elements so any client can and the author's API commits to support. Not coincidentally, they are also the elements for which the Javadoc utility generates documentation into its default mode O F operation. Loosely speaking, the exported API of a package consists of the the public and protected of all members and constructors of every pub Lic class or interface in the package.

Classes, interfaces, constructors, members, and serialization forms are collectively referred to as API elements. The export API consists of API elements that are accessible outside the package of the package that defines the API. These API elements are available to any customer and are supported by the authors of the API. Coincidentally, the Java Tools class also produces documents for these elements in the default operating mode. Strictly speaking, the export API for a package consists of public members, protected members, and the interfaces in each public class constructor or package.