java tutorial for complete programmer

Introduction

THIS blog is designed to help you make the most effective use of the JavaTM programming language and its

fundamental libraries, java.lang, java.util, and, to a lesser extent, java.util.concurrent and java.io. The blog

discusses other libraries from time to time, but it does not cover graphical user interface programming,

enterprise APIs, or mobile devices.

This blog consists of seventy-eight items,

each of which conveys one rule.

The rules capture practices

generally held to be beneficial by the best

and most experienced programmers. The

items are loosely grouped

into ten chapters, each concerning

one broad aspect of software design.

The blog is not intended to be read

from cover to cover: each item stands on

its own, more or less. The items are heavily

cross-referenced so you

can easily plot your own course through the

blog. Many new features were added to the

platform in Java 5

(release 1.5). Most of the items in this blog use

these features in some way. The following

table shows you

where to go for primary coverage of

these features:

Feature Chapter or Item

Generics Chapter

Enums Items

Annotations Items

For-each loop Item

Autoboxing Items

Varargs Item

Static import Item

java.util.concurrent Items

C H A P T E R

1

Most items are illustrated with program

examples. A key feature of this blog is

that it contains code

examples illustrating many design

patterns and idioms. Where appropriate,

they are cross-referenced to

the standard reference work in this

area [Gamma95].

Many items contain one or more program

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 is bad

and suggests

an alternative approach.

This blog is not for beginners: it assumes

that you are already comfortable

with the Java programming language.

If you are not, consider one of the many

fine introductory

texts [Arnold05, Sestoft05]. While the

blog is designed to be acces- sible to

anyone with a working

knowledge of the language, it should

provide food for thought even for

advanced programmers.

Most of the rules in this blog derive

from a few fundamental principles.

Clar- ity and simplicity are

of paramount importance. The user

of a module should never be surprised

by its behavior. Modules

should be as small as possible

but no smaller. (As used in this blog,

the term module refers to any

reusable software component,

from an individual method to a

complex system consisting of

multiple packages.) Code should be

reused rather than copied.

The dependencies between modules

should be kept to a minimum.

Errors should be detected as soon as

possi- ble after they are made,

ideally at compile time.

While the rules in this book do not apply

100 percent of the time, they do

characterize

best programming practices in the

great majority of cases. You should not

slavishly follow these

rules, but violate them only occasionally

and with good reason. Learning the art

of programming,

like most other disciplines, consists of

first learning the rules and then learning

when to break them.

For the most part, this blog is not about

performance. It is about writing

pro- grams that are clear,

correct, usable, robust, flexible, and

maintainable. If you can do 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

numbers. These numbers, which are

introduced

with the phrase “On my machine,”

should be regarded as approximate

at best.

For what it’s worth, my machine is

an 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 Server

VM.

When discussing features of the Java

programming language and its libraries,

it is sometimes

necessary to refer to specific releases.

For brevity, this blog uses “engineering

version

numbers” in preference to official release

names. This table shows the mapping

between release

names and engineering version numbers.

Official Release Name Engineering Version

Number

JDK 1.1.x / JRE 1.1.x 1.1

Java 2 Platform, Standard Edition, v 1.2 1.2

Java 2 Platform, Standard Edition, v 1.3 1.3

Java 2 Platform, Standard Edition, v 1.4 1.4

Java 2 Platform, Standard Edition, v 5.0 1.5

Java Platform, Standard Edition 6 1.6

The examples are reasonably complete,

but they favor readability over

com- pleteness. They freely use

classes from the packages java.util

and java.io. In order to compile the

examples, you may have to add

one or more of these import statements:

import java.util.*; import java.util.concurrent.*;

import java.io.*;

Other boilerplate is similarly omitted.

For the most part, this blog uses technical

terms as they are defined in The Java

Language Specification,

Third Edition [JLS]. A few terms deserve

special mention. The language supports

four kinds of types:

interfaces (including annota-tions),

classes (including enums), arrays, and

primitives. The first three are

known as reference types. Class instances

and arrays are objects; primitive values

are not. A class’s

members consist of its 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.

This blog uses a few terms differently

from the The Java Language Specifica-

tion. Unlike The Java

Language Specification, this blog uses

inheritance as a syn- onym for subclassing.

Instead of using

the term inheritance for interfaces,

this blog simply states that a class implements an interface or that

one interface extends another.

To describe the access level that

applies when none is specified, this blog

uses the descriptive term package-private instead of the technically cor- rect term default access [JLS,

6.6.1].

This blog uses a few technical terms

that are not defined in The Java Lan-

guage Specification.

The term exported API, or simply API,

refers to the classes, interfaces,

constructors, members,

and serialized forms by which a

programmer accesses a class, interface,

or package. (The term API,

which is short for applica- tion

programming interface, is used in

preference to the otherwise

preferable term interface to avoid

confusion with the language construct

of that name.)

A programmer who writes a program

that uses an API is referred to as a user

of the API. A class whose

implementation uses an API is a client

of the API.

Classes, interfaces, constructors,

members, and serialized forms are

collec- tively known as

API elements. An exported API consists

of the API elements that are accessible

outside of the

package that defines the API. These are

the API ele- ments that any client can use

and the author

of the API commits to support. Not

coincidentally, they are also the elements

for which the Javadoc

utility generates documentation in its

default mode of operation. Loosely

speaking, the exported API

of a package consists of the public and

protected members and constructors

of every public class

or interface in the package.

Next page