A Software Engineer Learns Java And Object

Orientated Programming Cameron download

https://ebookbell.com/product/a-software-engineer-learns-java-
and-object-orientated-programming-cameron-43039484

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

A Software Engineer Learns Java And Object Orientated Programming 1st

Dane Cameron

https://ebookbell.com/product/a-software-engineer-learns-java-and-
object-orientated-programming-1st-dane-cameron-6769022

A Software Engineer Learns Java And Object Orientated Programming Dane

Cameron

https://ebookbell.com/product/a-software-engineer-learns-java-and-
object-orientated-programming-dane-cameron-43187710

A Software Engineer Learns Java And Object Orientated Programming

Cameron

https://ebookbell.com/product/a-software-engineer-learns-java-and-
object-orientated-programming-cameron-22783254

A Software Engineer Learns Java And Object Orientated Programming Dane

Cameron Cameron

https://ebookbell.com/product/a-software-engineer-learns-java-and-
object-orientated-programming-dane-cameron-cameron-22783292
A Software Engineer Learns Java And Object Orientated Programming
Cameron

https://ebookbell.com/product/a-software-engineer-learns-java-and-
object-orientated-programming-cameron-22783336

A Software Engineer Learns Html5 Javascript And Jquery A Guide To

Standardsbased Web Applications Dane Cameron

https://ebookbell.com/product/a-software-engineer-learns-
html5-javascript-and-jquery-a-guide-to-standardsbased-web-
applications-dane-cameron-50196032

A Software Engineer Learns Html5 Javascript And Jquery A Guide To

Standardsbased Web Applications 1st Ed Cameron

https://ebookbell.com/product/a-software-engineer-learns-
html5-javascript-and-jquery-a-guide-to-standardsbased-web-
applications-1st-ed-cameron-11839472

A Software Engineer Learns Html5 Javascript And Jquery A Guide To

Standardsbased Web Applications 2nd Dane Cameron

https://ebookbell.com/product/a-software-engineer-learns-
html5-javascript-and-jquery-a-guide-to-standardsbased-web-
applications-2nd-dane-cameron-4953372

Building A Game With Unity And Blender Learn How To Build A Complete
3d Game Using The Industryleading Unity Game Development Engine And
Blender The Graphics Software That Gives Life To Your Ideas Lee Zhi
Eng
https://ebookbell.com/product/building-a-game-with-unity-and-blender-
learn-how-to-build-a-complete-3d-game-using-the-industryleading-unity-
game-development-engine-and-blender-the-graphics-software-that-gives-
life-to-your-ideas-lee-zhi-eng-38495364
A Software Engineer Learns Java and Object Orientated
Programming

By Dane Cameron
© 2015 Cisdal Publishing

All rights reserved. No part of this publication may be reproduced,

distributed, or transmitted in any form or by any means, including
photocopying, recording, or other electronic or mechanical methods,
without the prior written permission of the publisher, except in the
case of brief quotations embodied in critical reviews and certain
other non-commercial uses permitted by copyright law. For
permission requests, write to the publisher, addressed “Attention:
Permissions Coordinator,” at the address below.

Original and modified cover art by Karunakar Rayker and

CoverDesignStudio.com

Cisdal
dane@cisdal.com

www.cisdal.com
Table of Contents
Preface

Introduction to Java

About this book

Getting started with Eclipse

Hello World!!!

Classes and Objects

Data-types

Language Fundamentals

Operators

Looping and Branching

Debugging

Object References

Inheritance

Composition

Constructors

Exception Handling

Methods

Collections
Generics

Unit Testing

Enumerated Types

Inner Classes

Lambda Expressions

Streams API

Dates and Calendars

Date and Time API

Input and Output

Properties Files

Default Methods

Threading

Parallel Programming

Java Doc

Annotations and Reflection

Building and Deploying

Logging

Conclusion
Design Patterns
Template

Abstract Factory

Factory Method

Singleton

Clone

Visitor

Iterator

Command

Builder

Decorator
Preface
Tell me and I forget. Teach me and I remember. Involve me and I
learn.

Benjamin Franklin

I wrote my first Java code in 1998, just 2 years after its initial release.
In the subsequent 17 years I have continued to use Java, including
as a professional software engineer for the last 16 years.

A lot has changed in the world of technology in the last 17 years, but
in many ways Java has remained a beacon of stability. The code I
wrote 17 years ago does not look vastly different from the code I
wrote last week, and that code I wrote 17 years ago would still run
on modern versions of Java (for the most part).

Despite the fact that the Java language has remained relatively
stable, the role Java plays in the work of IT has changed
dramatically. Java first came to prominence as a language for writing
browser based applications (called Applets). Applets created a huge
sense of excitement around the language through the later part of
the 1990s and the Dotcom boom, but have fallen by the wayside as
native browser-based technologies have continued to improve.

Instead, Java became the dominant language for server-side

programming, and is now the driving forces behind many of the
world’s largest and most visited web sites, along with the business
applications powering the world’s largest corporations.

In 2014 Java underwent a number of dramatic changes with the

release of Java 8. This is the most significant release of Java since
the initial release of the language, and has the potential to
fundamentally change the way Java is used. This book has been
written from the ground-up to incorporate these features, and treats
them as integral to the language.

This book is my attempt to pass on what I have learned over the last
17 years. It is not intended as a simple primer on the syntax of the
Java language (although the syntax of the language is covered in
detail), it is intended to introduce you to the way a software engineer
thinks about Java, and the way they structure their code in a world of
large-scale, and increasingly complex software.

The intention of this book is to leave you in a position where you can
write useful, real-world Java programs that solve interesting
problems. This book will not teach you everything you know to
become an expert Java programmer; much of that knowledge can
only come through experience. I have, however, tried to write the
book I would want to read if I was starting from scratch with Java.
1
Introduction to Java
Java is a statically typed object-orientated programming language.
That sentence may mean a lot to you, or it may mean nothing. Rest
assured, this sentence will make sense to you by the end of this
book.

Java was originally created by Sun Microsystems in 1995. It has

subsequently undergone a number of major revisions, most recently
in 2014 with the release of Java 8, and has become one of the most
widely used programming languages.

Sun Microsystems was purchased by Oracle in 2009, and they have

continued to support and extend Java.

It is very difficult to describe the fundamental features of Java in an

introduction. Like anything complex, Java is best explained once it is
understood to some degree. This chapter will, however, provide
some background on what Java is and how it works - but you may
want to return to this section once you have progressed some way
through the book.
Compiled vs. interpreted languages
Programming languages can be classified in many ways; one form of
classification is whether they are compiled or interpreted.

In order for any software to run on a computer it must be converted

into machine code: the sequence of 0s and 1s representing a set of
instructions that can be comprehended by a computer processor. A
compiled language is one where the source code is converted into
machine code by a tool called a compiler, and packaged as a
program that can be distributed directly to end-users.

Because each operating system is different, compilers need to be

written for each operating system. The beauty of compilers, however,
is that the same source code can be used to create executable
programs for different operating systems. Examples of compiled
languages are C and C++.

Interpreted languages also need their source code to be converted

to machine code in order to be run on a specific operating system,
but with interpreted languages this happens in real-time as the
program executes. This means that the same code can be executed
on any operating system supporting an interpreter for that language
(which is the software that converts the source code into machine
code in real time).

Interpreted languages are generally slower than compiled

languages, because the compilation step is effectively happening
while the program executes. Examples of languages that can be run
by interpreters are JavaScript and Perl. Many interpreted languages
can also be compiled, however, therefore the line between
interpreted and compiled languages is sometimes blurred.

Java does not easily fit into either of these categories. Java is a
compiled language: all source code must be compiled before it can
be executed. As you will see, the Java Development Kit (JDK)
contains a utility program called javac that is responsible for
compiling Java source code.

Unlike traditional compilers however, the Java compiler does not

produce machine code for a specific operating system. Instead, it
produces Java bytecode.

Java bytecode does contain a set of instructions, just like machine

code. Unlike machine code, however, Java bytecode cannot be
executed directly by a computer. Java requires an intermediary
called the Java Virtual Machine – which is provided by the Java
Runtime Environment (JRE).

Any computer that wishes to run a program written in Java must

have a JRE installed, and this will perform the task of converting the
Java bytecode into machine code for the specific operating system
as the program executes.

If you use Windows or OSX you have probably noticed that you are
often requested to install a new version of Java: this is the Java
Runtime Environment. Once Java is installed you can run any
application written in Java.

You may be wondering why Java uses this approach? Java bytecode
can be thought of as a halfway house between source code and
machine code. It contains a set of instructions that can be executed
by an interpreter more efficiently than regular source code.

Java chose this approach as part of its “write-once, run-anywhere”

philosophy. The same compiled version of the program can be
executed on any computer that has a JRE installed: it is not
necessary to build different versions of the program for each
platform. This has been immensely valuable, because JREs are
available not just for desktop computers, but for mobile phones, set-
top boxes, and home appliances. In fact, Oracle claims some 3
billion devices run Java.
This approach was also intended to make the language more
secure. Traditional compiled programs can do anything on the
operating system that the user running them can do – including
deleting files, or sending them over the Internet to a hacker. The JRE
by comparison provides a sandbox that programs run inside of, and
it is possible to control what the program can do inside this sandbox,
or make it request the ability to perform certain operations. This
approach has become standard with Android and iOS in recent
years, but was built into Java from the very beginning.

Because Java bytecode is converted to machine code as the

program executes, Java shares characteristics with interpreted
languages. When Java was first released this was a reasonable way
to look at it, and Java was marketed as an interpreted language.

As mentioned earlier, however, interpreted languages tend to be

slower than compiled languages. Even though Java bytecode is
more efficient to convert to machine code than raw source code,
there is still some overhead. As a result, early versions of Java were
slow compared to compiled languages, and this perception has stuck
to some extent. Any discussion of Java on Slashdot still immediately
descends into a flame war on the performance of Java.

Java has not been an interpreted language for a long time however.
Almost all Java runtimes now use an approach called Just-in-Time
(JIT) compilation. The Java bytecode is compiled into machine code
as the program runs, just before it is needed. Although there is still
some overhead in this process, Java tends to perform as well as
compiled languages; with the added benefit that the same Java
bytecode can be run on many different operating systems.

One interesting aspect of Java bytecode is that languages other than

Java can generate it. There are now many languages that generate
Java bytecode, including several mainstream languages such as
Scala. In fact, the latest version of Java comes complete with a
JavaScript engine called Nashorn that integrates with the Java
language, and allows you to write JavaScript code that executes on
the Java platform.
Although the version of Java most commonly used is owned by
Oracle, anyone can technically write a JDK and JVM. The most
common alternative to the Oracle version is OpenJDK, which is an
open source implementation of Java.
Statically vs. dynamically typed languages
Another way to categorize languages is as statically typed or
dynamically typed languages: Java is a statically typed language.

When using a statically typed language, the programmer is

responsible for beginning by defining a type-system representing all
the different types of data that the program will work with and
manipulate. As an example, imagine you were writing software for a
rental car company: you might start by defining types such as Car,
Rental Agreement and Customer. As you will see shortly, these are
called classes in Java, and they describe the types of data the
program will use as it executes.

Once you have defined your type-system, you can start using these
types (by generating objects from them). In a statically typed
language the compiler can always determine which type you are
referring to. If you attempt to invoke behavior that is incompatible
with the type you are using the compiler will know. For instance, if
you try to rent a Customer to a Car, the program will know this is
invalid and generate an error. This means you never ship the faulty
version of the software to your customers.

With a dynamically typed language the compiler does not know what
types you are using, and therefore you can invoke any operation on
any type. It will not be until the program actually runs that the
language will determine whether the code is valid, and as a result
dynamically typed software can be more error prone.

Statically typed languages tend to produce fewer errors at runtime

because the compiler acts as a safety net and warns us that our
code is attempting to do something it shouldn’t. Statically typed
languages can be more cumbersome to use however, and many
programmers prefer the flexibility of dynamically typed languages.

There are strong arguments in favor of both statically and

dynamically typed languages. This is not the time to discuss those
arguments, but you should be aware that Java is statically typed. As
it happens many other dynamically typed languages do produce
Java bytecode, but these are outside the scope of this book.
Programming paradigm
A final important way to categorize languages is by their “family” or
“paradigm”, for instance:

• Imperative programming language (think C)

• Object-orientated programming language (think C++ and

Smalltalk)

• Functional programming language (think LISP and Haskell)

As you will see, Java started life an object-orientated language (don’t

worry if you do not know what this means at this stage, I will cover
the important aspects of object-orientated languages shortly).

Java has, however, become a multi-paradigm language; it shares

many traits with imperative programming languages, and, since Java
8, has incorporated many aspects of functional programming
languages.

This is not uncommon – many modern languages are multi-paradigm

languages. When done right this can add tremendous benefits to a
language, because it allows the language to incorporate the best
parts of each paradigm, and allows the programmer to use the
paradigm that is best suited to their task at hand.

Throughout this book we will look in-depth at the multi-paradigm

nature of Java, and look at how these different paradigms can be
used effectively together.

That is all that you need to know about Java to begin – its time to
write some code.
2
About this book
Who is this book for?
The books in the “Software engineer learns” series are typically
intended for existing programmers and software engineers
transitioning from other languages or technologies. This particular
book is also appropriate for anyone aspiring to become a software
engineer, and who wishes to use Java as his or her starting point.

If you do not have any programming experience some of the material

in the early chapters may feel daunting. My advice is to stick with it: it
will start to make sense the more you progress through the book.
Even the simplest Java program contains a number of advanced
concepts, and it simply is not possible to convey all these concepts
in a couple of pages, or even a couple of chapters.

The key purpose of this book is to provide you the skills required to
become a competent software engineer. This means gaining a firm
understanding not only of the language fundamentals, but also an
understanding of how the language should be used to create a
maintainable and adaptable code base

Java is a complex programming language. It cannot be learned in a

day, or even a week. In fact, I have seen many other programmers
make assumptions about how particular language features work, and
maintain these assumptions for years without even realizing the
problems these assumptions were causing them. It is not difficult to
learn these features, and there is no better time to learn them than
when you are starting out with the language.

This book will include many code examples, and it is recommended

that you work through these examples yourself. One of the keys to
learning a language is to experiment with it, and try things out. The
simple act of typing code, even if it is copied word for word, is an
important way to learn the language.

I encourage you to use the code examples as a starting point. Try

changing features in these programs, or think of alternative ways to
write the same functionality. The thought processes this will lead to
are an important component in consolidating your knowledge of the
language.
What is covered?
This book will not provide an introduction to the entire Java language
– although the vast majority of the language will be covered. There
are some features in Java that I have never used, and am unlikely to
ever use; therefore there is very little point providing information on
these features for the sake of completeness. Once you know the
fundamentals of the language, you will find these features if you
need them.

Java is now largely a server-side language rather than a client-side

language. Java EE (Enterprise Edition) is a set of APIs that are
commonly used to implement server-side Java components (running
on web servers or application servers): these APIs are also outside
the scope of this book, although I will be publishing a Software
Engineer Learns edition for Java EE in the near future.

Java is now seldom used to implement rich GUI applications that run
natively on desktop computers (although it is widely used to write
native mobile applications via the Android SDK). For this reason this
book will not examine the two main Java APIs for creating desktop
applications: Java FX and Swing. This is a shame; because it is
always nicer to write programs that can be interacted with via a GUI,
but the reality is that you are unlikely to use these APIs in
professional environments.

This book will also not focus on exhaustive lists of APIs. Web based
resources have improved significantly over the years, and they are
now by far the best source of information on specific APIs when you
need them. What these web based resources are not so good at,
however, is providing you the bigger picture of when the API should
be used, and what its trade-offs are. This is where a book such as
this can become valuable.

Before you start it is best that I warn you that Java is a large and
complex language. A similar book for many other programming
languages would be at most half the size of this book. I have tried to
write the shortest book that I could, but I simply couldn’t make it any
shorter than I have without omitting important material.

I also would like to apologize up front for the fact that many of the
programs in this book, particularly in the early chapters, are not
solving interesting real-world problems. It is difficult to write
interesting programs until you have a grasp of large portions of the
language, and therefore the early chapters use simple examples.
Versions of Java
This book will focus on Java 8, because this is the latest release of
the language, and contains many significant additions. Throughout
the book I will specifically point out features that relate to Java 8 (and
even Java 7 to some degree), because it is important for you to
know that these are recent additions to the language. There are
massive amounts of Java code already written in earlier versions of
the language, and it may be your job to work with these at some
stage, therefore you need to know the limitations of earlier versions
of the language.

Although versions of Java are technically backwards compatible, it

can take significant effort to upgrade a large Java program to a
newer version of Java, therefore a lot of programs continue using
older versions of the language.
Resources
All resources for this book can be found at the following website:

www.cisdal.com/java.html

Source code has been provided in HTML pages rather than Java
code files. The idea is that you can copy and paste this code in
cases where you do not want to type an entire example
Conventions
Code in this book will utilize the following font:
This is code

Instead of endnotes, this book will use the following convention for
asides that are related to the main content, but are not directly
associated with the main content.

// This is an aside
Feedback
I would love to hear your feedback (positive and negative) on this
book. Please email me at dane@cisdal.com. Additionally, reviews
are always appreciated because they are the most important way an
independent publishing house such as ours can gain traction for its
books.
3
Getting started with Eclipse
Technically all you need in order to write Java programs is a text
editor and the Java Development Kit (which includes a Java compiler
and a Java Runtime Environment for executing Java code). In reality,
almost all software engineers who use Java to write non-trivial
programs use an Integrated Development Environment (IDE).

An IDE provides an environment where code can be edited, built, run

and debugged. In the Java world, the open source Eclipse IDE has
become the most widely used, and therefore it will be used
throughout this book. If you have a preference for another IDE you
are welcome to use this instead of Eclipse.

The Eclipse IDE contains everything you will need to write and
execute Java code, including a Java compiler and code editor. This
section will guide you through the process of installing Eclipse.

Installing Eclipse on OSX

Before installing Eclipse, it is important to ensure you have the latest
version of Java installed. Specifically, you need to ensure you have a
Java 8 JDK installed (a Java JRE is not sufficient), this can be
downloaded from the following web site:

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-
downloads-2133151.html

Once downloaded, install the dmg file just like any other OSX
application.
You should now download Eclipse: open your favorite browser and
navigate to http://www.eclipse.org/. Click the “Download” button on
the homepage, and select to download the latest version of Eclipse
for your platform. I will use the “Luna” release of Eclipse (version
4.4), but if a more recent version is available you can choose to use
it.

The downloaded version of Eclipse is in the form of a zipped tar file.

Once the file has been downloaded, copy it to the directory where
you would like Eclipse to be installed, and double click on the file.
This it will unzip the Eclipse application inside a folder called
“eclipse”.

In order to run Eclipse, simply double click on the Eclipse application

(the one with the purple icon) inside this folder. You will likely receive
a warning that Eclipse has been downloaded from the Internet,
which you need to accept before continuing.

When Eclipse first starts it will ask you to select a workspace. An

Eclipse workspace is the directory where your code will be saved, so
choose an appropriate location on your computer, as seen in figure
3-1:
 Figure 3-1
It is also worth checking the “Use this as a default” option so that you
do not receive this prompt every time you start Eclipse.

Install on Windows
Before installing Eclipse, it is important to ensure you have the latest
version of Java installed. Specifically, you need to ensure you have a
Java 8 JDK installed (a Java JRE is not sufficient), this can be
downloaded from the following web site:

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-
downloads-2133151.html

Once downloaded, install the downloaded file just like any other
Windows application.

You should now download Eclipse: open your favorite browser and
navigate to http://www.eclipse.org/. Click the “Download” button on
the homepage, and select to download the latest version of Eclipse
for your platform. I will use the “Luna” release of Eclipse (version
4.4), but if a more recent version is available you can choose to use
it.

On Windows the download file is in zip format. Once the download

completes, copy the zip file to the location you wish to install Eclipse.
Once there, right click on the file and choose to extract its contents.

Eclipse does not need to be installed, the act of extracting it places

all files in the appropriate location, and it can be run immediately.

Inside the Eclipse folder that has been created you will find a file
called Eclipse.exe. Simply double click on this file to launch Eclipse.

When Eclipse first starts it will ask you to select a workspace, as

seen in figure 3-2. An Eclipse workspace is the directory that you
wish your code to be saved to:
 Figure 3-2
It is also worth ticking the “Use this as a default” option so that you
do not receive this prompt every time you start Eclipse.

Getting started with Eclipse

Eclipse is a platform for software development. Although it is most
closely related to Java (and is written in Java itself), Eclipse is a
platform for writing software in many programming languages.

As such, Eclipse has a certain level of complexity built into it.

Throughout this book I will introduce you to the most important
aspects of the IDE, but be sure to take the time to explore for
yourself – you will find lots of useful and time saving features.

When Eclipse opens for the first time you will be presented with the
screen seen in figure 3-3:
 Figure 3-3
Click the “Workspace” icon in the top right hand corner of the screen:
this will take you to the Eclipse workbench, which will appear as per
figure 3-4:

Figure 3-4
Once you have Eclipse up and running you are ready to start
working with the examples in this book.
4
Hello World!!!
There is a common convention when learning a new programming
language that the first program you write is one that prints “Hello
World!!!” to the console.

There is actually a very good reason for this. The act of producing the
most trivial program possible introduces you to many important
concepts, and involves the steps of writing source code, compiling
that code, and executing it.

Before writing any code, first create a project in Eclipse. Projects are
an Eclipse concept rather than a Java concept, and provide a
container for all the code and libraries that constitute a program.

From the main menu choose File -> New -> Java Project.
This option is shown in figure 4-1:

Figure 4-1
Inside the popup, use helloworld as the name of the project. It is
also important to ensure at this point that the execution environment
JRE is JavaSE1-8, as seen in figure 4-2.

Figure 4-2
Once the project name has been entered, simply press the “Finish”
button at the bottom.

You can now write the code to print “Hello World!!!” to the console.

All code in a Java program must be inside a class. I will explain what
a class is in detail in the next chapter, but for now just think of it as a
file containing Java source code. Each class has a name, and must
be created inside a file with this exact same name, along with the file
extension of .java.

Eclipse will always ensure that the name of the class and its filename
are the same, but if you were using a text editor instead of an IDE it
would be important to ensure this yourself.
When a class is compiled it will create a file with the same name, but
a .class extension: this contains the Java bytecode that will be
executed by the JRE.

There is a strict convention that classes should begin with capital

letters, and utilize camel case (where each word is capitalized). For
instance a class may be called HelloWorld, but should never be
called hello_world: even though this is technically a valid name for
a class.

Along with these conventions, Java does enforce a set of rules for
class names. A class must begin with a character, but can then
contain digits and the special characters “$” and “_”. It is also worth
mentioning at this point that everything in Java is case-sensitive – so
HelloWorld and Helloworld could coexist as two separate
classes.

Anything but the simplest Java program will contain many classes,
therefore it is customary to group classes inside “packages”. A
package is essentially a folder or directory, and is represented by a
directory on the file-system. Just like directories, packages can be
nested inside one another.

In this example the class will be placed in a package called hello. By

convention package names are entirely lower-case.

To create a class, use the File-> New-> Class option from the
main menu. Alternatively, you could right click on the project name on
the left of the screen and choose New-> Class.

After selecting this option you will be presented with a dialog box, as
seen in figure 4-3, where you can specify the basic details of the
class. Enter hello as the package name, HelloWorld as the class
name, and ensure that you check the option public static void
main(String args[]): I will explain this option shortly.
 Figure 4-3
Once these values have been provided, press “Finish”.
Eclipse will create the HelloWorld.java source file, and populate it with
relevant code. This will be displayed to you in the editor, as seen in
figure 4-4:

Figure 4-4
Additionally, if you look at the directory structure that has been
created on the file system it will look like figure 4-5:

Figure 4-5
• The top-level folder is the Eclipse workspace.

• Inside this is a folder for the project called helloworld. This in

turn contains two subfolders: a src folder for all source code, and a
bin folder for the compiled version of the program. These are simply
Eclipse conventions; the class files could just as easily be written to
the src directory.

• Inside the src directory is a directory for the package created

called hello, and finally, inside this is a file called
HelloWorld.java. Notice that Eclipse has automatically added the
.java extension for you, because this is a requirement of the
language.

One convenient aspect of Eclipse is that it compiles a class every

time it is saved (or attempts to at least). This means that if you look
inside the bin directory, you will find an identical structure to the src
directory hierarchy, except their will be a file called
HelloWorld.class, because it is the compiled version of the class.
You are now ready to look at the code that has been generated by
Eclipse. Because all Java classes contain the same basic structure,
Eclipse is able to generate some code for you: if you had been writing
this code with a text editor you would need to write this yourself.

Eclipse should have generated the following code:

package hello;

public class HelloWorld {

public static void main(String[] args) {

// TODO Auto-generated method stub
}
}

The first line of each class is the package declaration:

package hello;
Technically this line is optional, because the code could be placed
directly in the src directory, and would not be in a package. It is
advised to always place code inside packages however, because
even simple programs tend to grow over time, and packages are an
important way of maintaining the structure of a program.

You will also notice that the package declaration ends with a semi-
colon. All Java statements must end with semi-colons. Unlike some
languages (I’m looking at you JavaScript), semi-colons are not
optional in Java.

The empty line after the package declaration is not required, but
since white space is ignored in Java, adding an empty line such as
this can improve readability.

The next line provides the declaration of the class:

public class HelloWorld {

You can ignore the keyword public for now, I will explore this in
detail in subsequent chapters. The next keyword class indicates that
you are declaring a class, while HelloWorld is the name of the
class. All Java class files will begin with a similar declaration,
although, as you will see, there are many variants of this declaration.

This line of code ends with a curly bracket rather than a semi-colon.
Curly brackets are used in Java to wrap blocks of code: a “{“
indicates that a code block is beginning, while a “}“ indicates that a
code block is ending. A code block is a grouping mechanism for a set
of statements.

Although blocks can be nested inside one another, curly brackets

must always go in pairs because every code block must eventually
end. The entire class is considered a block of code; therefore the
closing curly bracket on the last line of the file signifies the end of this
block, and therefore the end of the class.
The next line of code is slightly more complex:
public static void main(String[] args) {

This is a method declaration. A method provides a container for code,

and therefore encapsulates the behavior of the program when it
executes. Classes can contain many different methods.

A method can be thought of as a function or a procedure if you are

familiar with these concepts in other languages, although as you will
see, there are important differences.

It is worth noting that these lines of code only exists because you
clicked the public static void main(String args[]) option
when you created the class. You clicked that because you wanted to
add a special kind of method to this particular class.

When a computer program executes it needs to start somewhere. In

some languages execution simply begins at the start of a specified
source file, and continues until the end of that source file. Java
always begins execution inside a method called main, and that
method must have the signature seen in this example. When you run
the Java program you will tell the JRE which class contains the main
method, and this will be implicitly executed when the program begins
executing.

// A method signature is the combination of its name, and the

types (and order) of parameters it accepts (main accepts
a single parameter of type String[]). Each method in a
class must have a unique method signature.
Technically multiple classes can contain main methods, but when
the program runs only the main method in the specified class will be
executed.

I will ignore the public and static keywords until later chapters. The
next keyword in the signature is void: this indicates the type of data
returned by the method when it finishes execution. Because the
main method does not return any data, it is always declared as
returning void.

The next identifier in the signature, main, is the name of the method.
Method names are usually arbitrary, with the exception that they
conventionally start with a lower case character. As mentioned, the
main name is not arbitrary in this case, because the Java Runtime
Environment will look for a method named main when the program
starts executing.

The main method accepts a parameter, as indicated by the following

syntax (String[] args). Parameters provide a mechanism for
passing data to methods. Each parameter has a type, in this case
String[] which means it is an array of character strings (i.e. zero or
more character strings), and a name: args in this case. The name of
the parameter is not important, this line could have just as easily
been declared:
public static void main(String[] arguments) {

The parameter accepted by main provides an important feature.

When any Java program begins execution it can be passed a set of
arguments: these will then be made available in this array. Passing
arguments to a program at runtime allows the same compiled
program to behave differently depending on the values passed to it.
For instance, in this case you could pass an argument specifying that
the program should print its output in capital letters.
You will not pass any arguments to this program, but it is still
necessary to declare that the main method accepts this parameter.

The main method also contains a block of code, therefore it uses

open and closing curly brackets to denote its start and finish: anything
inside these curly brackets is the method body.

Notice that these curly brackets are nested inside the curly brackets
for the class itself. Because Java code can consist of many nested
blocks of curly brackets, it is important to indent each block, as seen
in this example.

This is not a requirement of the language, but it makes it much easier

to find the closing bracket for an opening bracket because, as you will
see in future chapters, the nesting can sometimes be many levels
deep.

The final line of code that Eclipse has generated for us is a comment:
// TODO Auto-generated method stub

Comments can either be denoted with a double forward slash (as in

this case) or using the following construct if they span multiple lines:
/* This comment
spans multiple
lines */

Naturally comments have no bearing on the program at run time, but

they are an important way of conveying the meaning of code to other
programmers.

In order to print HelloWorld!!! to the console you need to add a

line of code to the main method as follows:

public static void main(String[] args) {

System.out.println("Hello World!!!");
}
I will not explain the full complexity of this line for now, but System
is a class that comes built into Java. The code .out accesses a utility
object held by the System class called a PrintStream, which
acts as the standard output for the program. The code System.out
therefore can be thought of as a mechanism for accessing the
standard output of the program.

.println is invoking a method on the

The next portion of this line
PrintStream object called println. This method is just like the
main method you have written, except it is provided by the Java
platform.

The println method can be passed an argument of type String. In

this case you will create a literal String by simply enclosing a set of
characters inside double quotes. Notice that the argument is
enclosed within () brackets.

// The terms parameter and argument are subtly different.

When methods are defined, the list of parameters is

specified. When the method is invoked, a set of arguments
is passed to these parameters.

The println method will print the string it is passed to the standard
output of the program, which in your case will be the Eclipse console.
If you were running this program from an operation system console or
shell, the standard output would be that console or shell.

You can now run the program by selecting Run -> Run from the
main menu. When you choose this option, Eclipse will look for a class
in the project with a main method and run it.

Alternatively you could have right clicked on the HelloWorld class

and chosen Run As -> Java Application.
When the program runs it will produce the output seen in figure 4-6 to
the Console tab of Eclipse:

Figure 4-6
Congratulations, you have just written and executed your first Java
program!
Trouble shooting
Even with simple programs such as this, it is important to know how
to trouble shoot problems that may arise. In order to demonstrate
this, go back to the editor and remove the semi-colon from the end of
the following line:
System.out.println("Hello World!!!")

This has introduced a syntax error into the code; meaning Eclipse is
unable to compile it.

Eclipse will warn you that a problem exists in the code by adding a
red dot to the margin of the editor at the appropriate line, as seen in
figure 4-7:

Figure 4-7
If you click on the red dot, Eclipse will tell you what the problem is:
Syntax error, insert ";" to complete

In this case the error tells you exactly what the problem is. Eclipse is
not always so helpful, but usually knowing where the problem is
provides enough information to know how to fix it.

You will also notice that you cannot run a Java program if it contains
any compilation errors. Attempting to run the program now produces
the following message:
Exception in thread "main" java.lang.Error: Unresolved compilation problem:
Syntax error, insert ";" to complete BlockStatements
at hello.HelloWorld.main(HelloWorld.java:6)
Conclusion
The Hello World program demonstrated in this chapter is not as
simple as Hello World programs in many other languages. Not only
is it several lines longer than many languages, it is difficult to
concisely explain many features of this program without
understanding more of the language. In fact, I have not explained
many of the keywords used in this program.

This in itself does not make Java a good or bad language, but it does
stem from an important principle in Java: everything is a class. Many
languages, including object orientated languages such as C++ allow
arbitrary code to be included in a source file and executed: Java
insists that all code is placed within a class structure. In many
languages this program could be written as a single line of code, for
instance:
print("Hello World!!! ")

In the next chapter you are going to take a closer look at classes,
and the related concept of objects, this will include a look at some of
the keywords I skipped over in this chapter.
5
Classes and Objects
As mentioned in the introduction, Java is an object-orientated
programming language. Object-orientated programming is a
paradigm that uses the concept of an object to encapsulate the data
and behavior of a program. Objects are reusable modules, and can
interact with one another as the program executes.

This differs from many other programming languages that use

functions or procedures to encapsulate the behavior of the program:
these languages are called functional-orientated and imperative
languages respectively.

Object-orientated programming was already well established when

Java was created, and can be traced all the way back to the 1960s.
Java was notable for being a more pure object-orientated language
than many of its direct competitors, however, most notably C++..

The most important concept to grasp in this chapter is the difference

between a class and an object. A class acts as a template for
objects: it declares the data that will be held by an object, and the
methods that operate on this data. Put another way, once a class is
defined, many instances of the class can be constructed, and these
are called objects.

You can think of classes as molds. Once you have constructed your
mold you can use it to create as many objects as you like from the
mold.

Some object-orientated languages let you create objects without

classes (yes, I am looking at you again JavaScript). With Java,
however, you always need to start with a class.

Each object created from a class is independent from the other

objects constructed from the same class, but the methods available
remain the same. Before explaining the concepts of classes and
objects in more detail it is worth doing so with examples.

Classes are usually thought of as the “nouns” of a program. You may

remember from grammar class that nouns are used to name “things”
such as people, places, ideas or animals. These are opposed to
verbs, which describe actions.

When you first sit down to write a Java program you need to think
about what the nouns will be. For instance, in a rental car program
the nouns may be Customer, Car and Rental agreement. In a
banking program the nouns may be Customer, Account and Branch.

Once you have defined the nouns, you next start thinking about the
data each of these nouns needs to hold. You describe the data that
will be captured by defining fields on the class. For instance, a
Rental agreement class might contain fields that capture the daily
rate, the date the agreement was signed, and any special charges
that will be applied to the rate. The class defines the fields, while
each object will be assigned specific values for these fields.

Finally you need to think about what behavior is required from the
class; the behavior will be captured in the class’s methods. For
instance, the Rental agreement class might have a method that
calculates the total cost to the customer. In order to achieve this,
methods can read and modify the data held by an object.

You will remember from the Hello World example that you declared a
class called HelloWorld. Before beginning the examples in this
chapter it is worth pointing out a quirk of the Hello World program. In
that program you did not create an object from the HelloWorld
class, yet its main method could still be invoked. This is because
the method was declared as static:
public static void main(String[] arguments) {

Static methods are different from most of the methods that you will
look at in this book because they can be invoked directly on the
class, rather than instances of the class (its objects). This is a
subject I will return to in later chapters.
Declaring a class
You will begin by creating a new project in Eclipse called
ObjectsAndClasses.
Inside this project, create a new class called Car, and place this
class inside a package called vehicles.

Because you now have multiple projects in Eclipse, Eclipse needs to

know which project the class should be added to. The easiest way to
ensure that the class is created in the correct project is to select that
project in the “Package Explorer” on the left hand side of Eclipse:
this automatically selects that project as the “current” project.

Unlike the HelloWorld class from the previous chapter, you will
not check the public static void main(String[] args) option
when creating this class.

When you click “Finish”, Eclipse will generate the following code:
package vehicles;
public class Car {
}

Everything about this code should look familiar from the

HelloWorld example in the previous chapter: the class resides in
a package, and consists of an empty code block.

The first step for defining a class is adding its fields. The fields that
the class needs will depend on the program in which the class will be
used. For instance, a Car in a vehicle registration program might
hold very different data to a Car in a taxi booking system.

The process of determining the fields that are relevant for the
program being written is called data-abstraction. This is because you
are creating an abstraction of a Car that models just the information
and behavior that is relevant for the context you are using it in.

Although computer programs often represent concepts in the real

world, they do not have to represent every aspect of the real world.
One of the most important skills you will need to acquire as a
programmer or software engineer (regardless of the language you
are using) is the ability to abstract the relevant features and
characteristics of real-world entities that are important for your task
at hand.

In this particular case you will focus on the fields that may be
relevant for a car in a vehicle registration system, therefore add the
following fields:
package vehicles;

public class Car {

private String registrationNumber;
private String make;
private String model;
private int engineSize;
private short yearFirstRegistered;
}

You have added five fields to this class. Each definition contains
three component parts:

• An access modifier: private in this case

• A data-type: this indicates the type of data that each field holds

• A name: this can be used to reference the field

These component parts will be described in more detail shortly.

Due to the fact that this is a class (or a template for objects), you do
not need to assign values to the fields; the values will be assigned to
each instance (or object) you create from this class.
 Another Random Document on
Scribd Without Any Related Topics
power of the stroke immediately the ball is reached."
This is an idea fatal to good golf. As I have frequently pointed out,
and as James Braid in How to Play Golf also emphasises, the
meeting between the ball and the club should be merely an incident.
Any attempt to try to do anything during impact in the drive is futile.
Mr. Travis at page 24 makes the same error with regard to the speed
of the club after the ball has been hit. He says: "A great deal more
depends upon the maintenance of speed after the ball is struck than
is commonly supposed. This part of the stroke is known as the
follow-through, and plays a very important part in the length of the
drive as in straightness." Mr. Travis evidently does not perfectly
realise that the follow-through is of no importance whatever except
as the natural result of the correctly played first part of the stroke,
and the maintenance of speed after the ball has been struck is of no
importance provided that the first portion of the stroke has been
properly executed and at a sufficient pace. The only importance of
the maintenance of speed in any way whatever is that this indicates
that the first half has been correctly performed.
Mr. Travis seems to be very hazy as to the causes of slicing and
pulling. A ball being hit slightly to the right of its centre would not
necessarily produce a slice, although it would probably deflect it
from its intended line of flight. A slice is produced by the amount of
rotation which is imparted to the ball by the glancing blow. He says:
"With a pulled ball it is just the opposite—the ball is hit to the left of
its centre, that is, nearer the player, producing a spin from right to
left." This is not in any way necessary. The ball may be hit absolutely
at the point farthest from the hole, and with the club at a perfect
right angle to the intended line of flight, but the point which Mr.
Travis does not mention is that the club is travelling upward across
the intended line of flight and outward from the player. This it is
which produces the beneficial spin of the ball in the pull.
At page 31, Mr. Travis says: "Every golfing stroke describes a circle,
or a segment of a circle." This is an egregious error, for the golf
stroke, quite naturally from the method of its production, bears a far
greater likeness to an oval than to a circle. Anyone endeavouring to
produce the golf stroke as a circle would certainly not get either a
very graceful or a very accurate result. Mr. Travis falls into the
astonishing error for a man who plays golf so well as he does, of
thinking that it is possible to juggle with the golf ball by means of a
golf club during impact. Speaking of brassy play, he says: "The
lofted face, joined to the slight whipping up of the hands at the
proper time—that is after the club meets the ball—will produce the
desired result. Don't on any account seek to bring the hands up too
quickly, otherwise a top will assuredly result."
Mr. Travis here falls into the common error with regard to using the
wrists during impact. It will be observed that he avoided it in dealing
with the follow-through, but in this matter he makes the usual error.
This turning up of the wrists which he refers to comes long after the
ball has been hit, and is the natural turn up which follows any slice
or any cut played to raise a ball suddenly.
At page 41 he makes the same error, for he says: "By striking the
ball slightly towards the heel of the club, and immediately after
bringing the arms somewhat in and finishing well out, a slight spin is
imparted to the ball which causes it to rise more quickly." Here it is
clear that he thinks that one may, after impact, do something with
the hands to affect the manner in which the ball leaves the club.
There could not possibly be any greater fallacy in golf than this. That
this is a rooted fallacy of Mr. Travis I shall show later on when I deal
with his remarks about bunker play.
Mr. Travis says at page 49: "Hitting with the heel of the club meeting
the ground after the ball is struck will cause the ball to rise more,
and, joined to the spin imparted by drawing in the arms and turning
the wrists upward, will produce a very dead ball with hardly any run.
The science of the stroke consists in hitting very sharply, and turning
the wrists upward immediately after the ball is struck."
Here we see the same delusion. The essence of this stroke is purely
a matter of practical golf which I have not seen mentioned in any
book or essay on golf. When one plays a ball off the heel of one's
mashie, it stands to reason that one gets the ball on the very
narrowest portion of the blade, and that therefore one hits the ball
as far beneath the centre of the ball's mass as it is possible to do—
so much so, in fact, that a very considerable portion of the ball
overlaps the top of the face of the club. This puts a tremendous
amount of undercut or stop on the ball. This is the practical golf of
the shot which Mr. Travis is attempting to describe, but his idea of
putting cut on it by juggling with it during impact is fatal.
In speaking of approach puts, Mr. Travis gives some wonderful
advice. He says: "You should aim to hit the ball as if it were your
intention to drive it into the ground.... This will cause the ball to
jump, due to its contact with the ground immediately after being
struck." This is practical golf of a nature which we may very well
pass without discussion. I think that there are very few golfers who
will desire to bounce the ball off the earth when they can play it off
the face of the club.
This is Mr. Travis' advice as to how to cut the put. At page 65 he
says: "Put cut on the ball by drawing the arms in a trifle just at the
moment of striking." The drawing of the arms across the ball is not
to be done at the moment of striking. It starts at the beginning of
the swing and finishes at the end thereof. This is how cut is put on a
put by practical golf. Mr. Travis advises for putting that people should
select "a particular blade of grass" on the line to the hole. He then
says: "Take your stance and square the face of the putter at perfect
right angles to the blade of grass you have picked out." As a matter
of practical golf I may remark that blades of grass have a
remarkable family likeness.
Mr. Travis says: "Close observation of all missed puts discloses the
interesting fact that by far the large majority go to the left of the
hole, thereby indicating the presence of the pull, due to the arms
being slightly drawn in just after striking." This is what is called a
sliced put in England, but again as a matter of practical golf I may
say that many of these puts are simply misdirected, such
misdirection being due to the turning over of the wrists too soon in
the action of striking the ball. Unless one determinedly follows
through well down the line the natural tendency is to hook one's put
across the line, but this does not indicate any pull. It merely
indicates, if of frequent occurrence, ignorance or carelessness.
Speaking of stymies, Mr. Travis says: "Occasionally you will be
confronted with an absolutely dead stymie by having your
opponent's ball just on the edge of the cup, your own being so
close, say seven inches to a foot away, that it is impossible to
negotiate the stroke by either curling around or lofting. In such
extremity there is only one way of getting your ball in the hole
unaccompanied by your opponent's, and that is by what is
technically known in billiards as the follow shot." As a matter of
practical golf the stymie stroke introduced by me is far more likely to
prove successful in this case than the follow shot, for we are dealing
with very tricky things when we try to play billiards with golf balls
covered with numerous excrescences or dimples. If the stymie
described by Mr. Travis is played by my stroke, it should be got five
times out of six, and I very much doubt if Mr. Travis or anybody else
could get anything like this with the run through stroke.
Writing of "Playing out of hazards," Mr. Travis says: "Then bring it
down again on the same line with all the force you can controllably
command, consistent with accuracy. As it sinks into the sand its
course may then, but not until then, be slightly directed towards the
ball."
Coming from a practical golfer this is an absolutely amazing
statement. The idea of attempting to deflect one's niblick from the
line originally mapped out for it as it enters the sand is too amazing
and too utterly unsound to merit any further comment or notice,
except to say that it would be impossible to deflect the club head
from the line of travel mapped out for it at this moment without
materially reducing the force of the blow, and when one is hitting
into heavy sand, to get underneath the ball and in many cases to
get it out of the bunker without even touching it with the club, every
pound of force that can be put into the club is necessary.
There is another thing which Mr. Travis tells us that certainly is not
practical golf, and it does not seem to me to be practical carpentry,
but he says at page 126, speaking of the brassy: "The screws which
hold the blade sometimes work loose. This trouble may easily be
remedied by putting glue in the holes before inserting the screws."
One is never too old to learn, and I think that in any future efforts I
may make at amateur carpentry, I shall glue my nails!
Mr. Travis makes a very remarkable statement at page 139, speaking
of the guttie ball as opposed to the Haskell: "The latter, by reason of
its greater comparative resiliency does not remain in contact with
the club head quite so long, and therefore does not receive the full
benefit of the greater velocity of the stroke in the same proportion
as the less resilient guttie"; but surely the greater the resiliency of
the ball the longer it will remain in contact with the club. It should
be obvious that one of the reasons for the greater swerve in the
sliced or pulled rubber-cored ball as compared with the guttie, is
that on account of the longer period of impact the ball acquires a
greater amount of spin.
Speaking of the waggle, Mr. Travis is delightfully indefinite. He says
"With the club gripped pretty firmly with both hands in the manner
already described, it is well to see that the whole machinery is in
good working order by waggling the club a few times over the ball,
allowing the wrists to turn freely, without, however, relaxing the grip.
The waggle should be entirely free from any stiffness, which simply
means that the wrists should be brought into active play."
This is certainly delightfully vague, and is not, I am afraid, of much
use to anyone as a matter of practical golf. The waggle is
unquestionably of importance in the game of golf, otherwise it is
quite improbable that we should see it employed by so many of the
famous players. The curious thing about this waggle is that it seems
to be confined to games wherein one plays a stationary ball. The
same operation is gone through at billiards with the cue, but is there
known as cueing at the ball. With a very great number of players the
waggle may be described as moral cowardice—an excuse for putting
off the evil moment. Many players convert the waggle into a
performance which is both tedious and stupid, and which instead of
giving them a better chance of hitting the ball, has a very great
chance of absolutely putting them off their stroke.
I do not know that I have ever seen the necessity for the waggle
explained, nor have I seen the waggle of any of the famous players
illustrated. There can, however, be very little question that in the
majority of cases the address and waggle is unnecessarily
exaggerated and prolonged.
In Modern Golf I have illustrated George Duncan's waggle. So far as
I am aware, this is the only time that such a thing has been done.
Duncan is probably the quickest player living, so that it will not be
necessary for us to assume that every one will be satisfied with so
little preliminary work as Duncan puts in before hitting the ball. His
method of playing is to take his line to the hole as much as he can
as he approaches the ball. He then marches straight up to it and
takes his stance, at the same time swinging his club head out so
that it is roughly on a level with his waist and pointing towards the
hole, but being at the same time almost above the line of flight to
the hole. He then brings his club back to the ball, and addresses it in
the usual way, soling his club close behind the ball. Now he lifts the
club practically straight up for six or nine inches and carries it
forward of the ball in a gentle curve for about six inches. From here
he carries the club head back along the plane of flight produced
through the ball as far as it will go without turning his wrists over.
The club then is swung easily and naturally back to the ball almost in
the same manner as it would come to it in the drive, until it arrives
close behind the ball, but about two inches from the turf, when it
sinks to rest by dropping straight down behind the ball. It is now
soled again as in the original address.
This sounds like a somewhat lengthy process, but as a matter of fact
it is probably the shortest waggle used by any golf player who is in
the front rank. In fact, so rapid is Duncan in his play, that very
frequently spectators who are not accustomed to his methods, do
not see him play the ball, as they allow for the more deliberate style
generally followed by the other leading professionals. In Duncan we
have a player who in my opinion is as good a golfer as anyone in the
world. We see clearly that he wastes very little time in addressing his
ball, either through the green or on the putting-green. On the other
hand, we see some men of greater fame than Duncan whose
deliberation is tedious in the extreme, although it must be admitted
that in so far as regards the waggle in the drive, the great players do
not overdo this nearly so much as do amateurs of an inferior class.
I am not aware that anybody has yet explained the reason for the
waggle. It seems that it is a natural movement, or in some cases a
very unnatural movement, which players fall into in endeavouring to
readjust their distance from the ball and their position with regard to
the line of flight. Very many players who waggle, produce most
remarkable flourishes with their club. The club is made to describe
curves in the air which it could not possibly do in any other
operation at golf than the waggle. The whole object of the waggle
seems to be to allow the player to get his eye in, as it is commonly
called, at the ball, to loosen his joints, and, which is a point that I
have not seen previously made, in a measure to produce in
anticipation the motions of his wrists and club immediately before,
at, and after impact with the ball.
If this view of the object of the waggle be accepted as correct, it is
obvious that in nine cases of ten the attempted waggle is force
hopelessly wasted—in fact, worse than wasted, for it has been
occupied in describing weird geometrical figures in the air, figures
which can have no possible reference whatever to the work which
the club is expected to do. In Duncan's waggle it will be observed
that firstly he swings his club head out down the line towards the
hole, and secondly that he carries it back for a considerable distance
from the ball in the plane of flight produced through the ball. It will
be seen from this that to a great extent he produces in the waggle
the same motions as his forearms and wrists go through
immediately before, at, and after impact with the ball. On examining
the photographs of Duncan's hands in the drive, we find that for the
space of nearly two feet before he reaches the ball, and probably for
quite that distance after the ball has been struck and he has
continued the follow-through, there is no turning over of the wrists—
that during this space of roughly three feet, the space wherein
James Braid says that the wrists have it all their own way, Duncan's
wrists are practically quiescent, and that during the whole of this
time the club is travelling at almost its maximum speed, but the
arms and wrists are doing very little more to it than to withstand the
centrifugal force developed in the earlier part of the swing and to
keep themselves braced to withstand the shock of impact.
These are merely a few instances taken haphazard from a book
called Practical Golf by one who is, undoubtedly, in so far as regards
his own play, a practical golfer. This does not, however, prevent him
from furnishing another and a very striking example of the curious
fact that nearly all good golfers teach the game in a manner entirely
different from that in which they play it, and that their tuition, if
followed out, must result in their followers learning to play in very
bad form, and probably also learning much which has to be painfully
unlearnt later on when they have discovered the truth.
 AFTERWORD
It would be very easy for me now to begin to explain in the ordinary
manner of golf books how the game is played, but to do so would be
going outside the scope of this work, and interfering either with the
proper functions of the professional, or the proper practice of the
intelligent golfer.
I have, in this book, taken my readers through all those matters
which are of the most vital importance to the game, and practically
everything which is contained between the covers of this book may
be better studied and digested by the golfer, be he a champion or a
beginner, in his arm-chair than on the links. He who wishes to know
golf to the core, must know what is in this book, all of which he can
thoroughly understand without taking a club in his hands.
The whole fault of the false doctrine which has been so plentifully
published about golf in the past, is that it has given the unfortunate
people who have taken notice of it an incalculable number of things
to think about. The truest and best tuition in golf is that which
advances by a process of elimination and so proceeds that it gives
the learner a minimum number of separate circumstances to think
about during his game; in fact, if the tuition has been properly
carried out the golfer will have astonishingly little to think of at the
moment when he is making his stroke. This is the ideal condition of
mind. The remark which the puzzled golfer made to me that when
he started on his downward swing he had so many things to think of
that he was "all of a dither" expresses marvellously accurately the
condition of mind of about ninety per cent of golfers who think they
have studied golf.
The golfer who studies this book soundly and intelligently will learn
what he will learn from no other book on golf, and that is what a
vast number of things there are in connection with the golf stroke
which it is expedient to forget at the moment one is making it.
Let me give an illustration of what I mean. The golfer is told now
that at the top of his swing he must get his weight on to his right
foot, and that he must keep his head still. The merest attempt to do
this produces a conflict at once. Then he is told that his left hand
must dominate the right: here is conflict again. But when he learns
that in order to keep his head still he must put his weight at the top
of his swing on his left foot, the conflict vanishes, he finds that it is
natural and easy to do; and he forgets to encumber his mind with
the fact that it has to be done, so that it becomes just as habitual
with him to put his weight in the right place as it is when he is
walking. The same thing applies with regard to the instructions
which he has always had drilled into him to allow the left hand and
arm to usurp the position of the right. Here again he is distinctly
exhorted to encourage these two members to enter into conflict
during the stroke. Although I explained to him most clearly that this
idea about the left being the more important member of the two is
utterly wrong, and that the right is, and always must be, the
dominant member in the golf swing, I did not tell him to remember
this during the golf swing, and he is indeed a very foolish person if
he attempts to remember it. All he has to do is to cut the false
doctrine out of his mind, and nature will attend to the rest. So it will
be seen that when one has grasped the truth in connection with golf
one has advanced by such a process of elimination that there is left
for the happy golfer when he addresses his ball very little to think of
but hitting that ball.
Golf in the past has suffered from the multiplicity of false directions.
It is by recognising these for what they are, and by forgetting them
that the golfer will ultimately arrive at The Soul of Golf.
 INDEX
Accelerating speed, Vardon on, 104
Address and impact similar, Braid on, 137
Address, Braid on, 133
Apportionment of back-spin, 263, 270, 271
Arm roll in stroke, 210
Arms measure distance, 46, 174
As you go up so you come down, 97, 219
Ayres, F. H., Ltd., 289, 324
Ayres, Mr. Rupert, 289-291

Back-spin at impact, rate of, 272

how obtained, 247
Professor Tait's experiment, 225
Professor Thomson's error, 246
Badminton Golf, 120, 158, 214, 218
Badminton Magazine, 222, 226
Ball, Mr. John, 153, 157
Ball, action of, during impact, 237
brambly, inaccuracy off putter, 287
centre of gravity, 292
centre of gravity, test for, 294
effect of marking, 302
effect of untrue centre, 299
flight parallel with earth, 265
guttie, truth of, 294
Haskell, 253
indented or dimpled, 286
instability of the golf, 284
smooth, flight of, 289, 311
tests, 296
 the golf, 283
track of, on green, 286
unscientifically made, 261
Balls, dimpled, 291
Base ball, spin in, 233
Beauty of flight, 3
Billiard balls, excrescences on, 283
Billiards, blind spot in, 175
Blackwell, Mr. Edward, 153
Blindfold golf, 164
Blind spot, 168, 169, 173
Blow in golf horizontal, Professor Tait, 265
upward, 265
Body movement after impact, 167
Braid on distribution of weight, 119, 135
on influence of club after impact, 101
on putting, 50, 55, 58, 77
Braid's putting, 75, 76
uncertainty about wrist work, 208
Bullet, drift of, 235

Catapults, Sir Ralph Payne-Gallwey's, 296

Cleek, push stroke with, 194
Vardon's push shot with, 194
Clubs, all illegal, 322
construction of, 316
rusty, 333
Contemporary Review, 320
Corkscrew action in stroke, Braid on, 213
Croome, Mr. A. C. M., 198, 199
Cross-bow, Professor Tait's experiment, 266
Cross wind, Professor Thomson on, 240
Sir Ralph Payne-Gallwey on, 298
Vardon on, 256
Cut, principles of, 89
Cutting round a stymie, 73
Direction, demand for, 3
Downward swing, control of, 133, 278
Downward swing, Duncan and Vardon, 130
Drag for bolting puts, 62, 63
in putting, 60
Drive, tension of muscles during, 38
Duncan, George, 7, 82
and mashie stroke, 72, 82
and smooth ball, 289, 309
Dynamical problems, Professor Thomson on, 228

Elimination the secret of coaching, 352

English mental attitude towards games, 4
English Review, The, 267
Evening Standard and St. James's Gazette, 288
Eye, lifting the, 34, 35
Eyes, effect of, on weight, 167
function of, 162, 163
movement of, 166
Vardon on movement of, 168

Fallacies of golf, 95
Feet, movement of, Duncan, Vardon, and Braid, 134
"Flick" in golf stroke, 213
Flight of ball, 222
Follow-through, 128, 129
control of, 278
Forearms, action of Duncan's, 210
in stroke, roll of, 210
Freemasonry of golf, 6
Fry's Magazine, photographs in, 125, 138

Golf books, unscrupulous practices, 10

Golf Illustrated, 197
and Professor Thomson, 253
Golfers groping their way, Braid, 269
Grip, apportionment of power in, 150
old, 152, 153
overlapping, 152
suggested new, 151
Gutta ball, Walter J. Travis on, 253

Haskell ball, 253

Head, keeping still, 162, 163
Taylor on position of, 171
High tee for low ball, 246
Hilton, Mr. H. H., 153
Hilton, Mr. H. H., in Concerning Golf, 160
Horizontal stroke, Professor Thomson's idea, 244
Hutchinson, Mr. Horace G., on distribution of weight, 120
on top of swing, 158

Impact, action during, 182

and address similar, Braid on, 137, 277
an incident of stroke, 45, 99, 100
arc during, 244
duration of, 165
length of, 277
muscles at time of, 30, 31
"no control over," Braid, 278
Professor Thomson on, 242
Walter J. Travis on, 253
Impatience to play, 5
Instruction by elimination, 352

Knee, left, Braid's action, 137

left, not loose, 127
right, and Vardon, 131

Laws of swerve of universal application, 234

Left and right wrists together, Vardon, 216
Left arm, power of, 12, 140
 Braid on, 142, 143, 148
Mr. Hutchinson on, 146
Taylor on, 144, 145, 148
Vardon on, 140, 141, 148, 149
Left hand, regulating grip, Vardon on, 150
Left wrist starts club down, Braid, 215
Le Golf, Arnaud Massy, 320
Literature of golf, 10, 334
Low, Mr. John L., Concerning Golf, 159, 256, 257
Low ball, high tee for, 246

Mashie, cut shot, 26

cut stroke, Vardon on, 191
for stymies, 70
stroke, Taylor's cut, 193
Mashies, short, for stymies, 330
Massy, Arnaud, 320
Master stroke, the, 178
Matter, definition of, 41
Mechanical accuracy demanded, 2
Mechanics of golf, 3
Mitchell, A., 327
Modern Golf, 59, 73, 83, 133, 210, 246
Morning Post, 198
Mystery, none in other games, 16
Mystery of Golf, 15, 125, 220

Newton, on principles of swerve, 223, 235, 228

"Nip" at impact, Professor Tait, 266
"Nose" of golf ball, 231

Palm grip, Mr. Horace G. Hutchinson on, 159

Payne-Gallwey, Sir Ralph, 292
tests, 296
Practical Golf, 120, 335 et seq.
Press, influence of, 33
Professionals and journalists, 10
lacking in theory, 9
Projectile Throwing Engines of the Ancients, 292
Pull, the, 179
axis of vertical, Professor Thomson on, 237
Braid on, 188
explanation of spin, 240
Mr. John L. Low on, 258
true axis of, 240
Vardon on, 183
Push stroke, Vardon's, 194
Put, Braid on cutting the, 83
not a wrist stroke, 67
position of ball, 67
run on, 69
short grip for, 84
Vardon on cutting the, 87
Put, short, the easiest stroke, 48
Braid on the, 50
should be taught first, 48
Taylor on the, 50
Vardon on the, 49
Putter, short, 326
Putting, 11, 47
chief point in, 64
fundamental principles of, 53
importance of address in, 65
mechanically simple, 57
most important factor, 52
off heel or toe, 64
pendulum action in, 66
tests, 304
with drag, 60

Ray, Edward, 301, 309

Roll of ball on club, 238, 245
"Ruff," the, golf ball, 300, 309

St. Andrews, Royal and Ancient Golf Club of, 322

Schenectady putter, 320, 326
Self-consciousness, 20
Shaft, torsional strain of, 321
Simplicity of golf, 2
Slice, the, 179
axis of, vertical, Professor Thomson, 237
impact in, 252
Mr. John L. Low on, 258
pressure on rear of ball, Professor Thomson, 241
Professor Thomson on, 250
true axis of, 238
Walter J. Travis on, 190
Slow back, 96
Smooth ball, uneven flight of, 311
Snap of wrists in drive, 205
Soles, broad, of clubs, 328
Spalding, A. G., & Bros., 291
Speed, gradually increasing, 29
Spin, 181
effect on flight, Braid on, 260
Spread of golf, 6
Style, 19
Stymie, cutting round, 73
run-through, 343
"Sweep," a hit with iron clubs, 109
Sweep, the, 12, 98
Swerve, or the Flight of the Ball, 224
Swerve, principles of, 223, 233
Swerve, double, 293
Sir Ralph Payne-Gallwey on, 305
Swing, premature teaching of, 5
the short, 110
top of, Mr. Horace G. Hutchinson on, 158
Tait, late Professor, 223
Taylor on distribution of weight, 120, 171
on putting, 50
on the sweep, 103
Teaching by elimination, 352
of golf unsound, 43
Temperament, golf the test of, 7
Tension during stroke, Braid on, 133
of muscles during stroke, 38
Thomson, Professor, and smooth ball, 312
Thomson, Professor Sir J. J., 227
Times, The, 292
Topped ball, 279
Top-spin, alleged possibilities of, 280
how obtained, 233
in lawn-tennis, Professor Thomson on, 232
nearest approach to, 280
not used in golf, 280
Travis, Walter J., fallacies of, 335 et seq.
on distribution of weight, 120

Under-spin not essential to long carry, 227

Professor Thomson's error, 246
properties of, 248
Upward concavity against back-spin, 267, 275

Vaile golf ball, 290

putter, 55
stymie stroke, 70
Vardon and blind spot, 169
on cross wind, 256
on cutting a put, 87
Vardon on distribution of weight, 118, 124
on follow-through, 131
on putting, 50, 75
Vardon's weight in follow-through, 131
Vertical axis of slice and pull, Professor Thomson on, 237

Waggle, the, 346

Duncan's, 346
Waist, pivoting from, 122
Weight, distribution of, 13, 25, 27, 97, 117, 171
Weight distribution, Vardon on, 118, 124
Braid on, 119, 121
fallacy, origin explained, 138
Horace Hutchinson on, 120
Mr. Haultain's explanation, 125
Taylor on, 120
W. J. Travis on, 120
Weight on right leg, test for, 122
Wind-cheater, 3, 179
Wind, cross, 242, 256, 257
Wrists, action of, 202
Mr. Horace Hutchinson on, 219
speed of, 217
turn over of, 107
Vardon on action of, 203

Printed by R. & R. Clark, Limited, Edinburgh.

THE MYSTERY OF GOLF

By ARNOLD HAULTAIN
Second and Cheaper Edition. Crown 8vo. 2s. 6d. net.
 Mr. Henry Leach in the EVENING NEWS.—"Mr. Haultain's book
answers to all the tests to which it may be submitted, and I am
strongly disposed to regard it as the best book of its kind that
has ever been written."
Mr. J. Sutherland in the DAILY NEWS.—"A short time ago I was
asked by a young aspirant ... to point out the book I liked best.
'That wee one?' he inquired, and on my nodding assent he ...
took the book down and read ... The Mystery of Golf
(Haultain)."
THE PROFESSIONAL AND GREENKEEPER.—"The book is
undoubtedly one of the best ever written dealing with the Royal
and Ancient Game."
"Looker-on" in GOLF ILLUSTRATED.—"In my opinion, the best
book that has ever been written on golf.... On every page there
scintillates a jewel of golfing wisdom."
GOLFING.—"A book in which every golfer must delight.... There
is not a stale word in the book from beginning to end."

THE ART OF PUTTING. By W. J. Travis and Jack White. Crown 8vo.

1s.
GREAT LAWN TENNIS PLAYERS. Their Methods Illustrated. By G. W.
Beldam and P. A. Vaile. With 229 Action-Photographs. Medium
8vo. 10s. 6d. net.
GREAT BATSMEN: Their Methods at a Glance. By G. W. Beldam and
Charles B. Fry. With 600 Action-Photographs. Medium 8vo. 10s.
6d. net.
GREAT BOWLERS AND FIELDERS: Their Methods at a Glance. By G. W.
Beldam and Charles B. Fry. With Contributions by F. R. Spofforth,
 B. J. T. Bosanquet, R. O. Schwarz, and G. L. Jessop; and 464
Action-Photographs. Medium 8vo. 10s. 6d. net.
LAWN TENNIS, ITS PAST, PRESENT, AND FUTURE. By J. Parmly Paret.
With a Chapter on Lacrosse by W. H. Maddren. Illustrated. Extra
crown 8vo. 8s. 6d. net.

BOOKS ON SPORT
THE ADVENTURES OF AN ELEPHANT HUNTER. By James Sutherland.
Illustrated 8vo. 7s. 6d. net.
A COLONY IN THE MAKING: or Sport and Profit in British East Africa.
By Lord Cranworth. With Map and Illustrations. 8vo. 12s. net.
SPORT ON THE NILGIRIS AND IN WYNAAD. By F. W. F. Fletcher.
Illustrated. 8vo. 12s. net.
THE MAN-EATERS OF TSAVO, AND OTHER EAST AFRICAN
ADVENTURES. By Lieut.-Colonel J. H. Patterson, D. S. O.
Illustrated. With a Foreword by Frederick Courteney Selous. 8vo.
7s. 6d. net. Cheap Edition. Globe 8vo. 1s. net.
IN THE GRIP OF THE NYIKA. Further Adventures in British East
Africa. By Lieut.-Colonel J. H. Patterson, D. S. O. Illustrated. 8vo.
7s. 6d. net.
A HUNTER'S WANDERINGS IN AFRICA. Nine Years amongst the
Game of the Far Interior of South Africa. By Frederick Courteney
Selous. Illustrated. Fifth Edition. Extra crown 8vo. 7s. 6d. net.
AFRICAN NATURE NOTES AND REMINISCENCES. By Frederick
Courteney Selous. With a Foreword by Theodore Roosevelt, and
Illustrations by E. Caldwell. 8vo. 10s. net.
NOTES ON SPORT AND TRAVEL. By George Kingsley. With
Introductory Memoir by his Daughter, Mary H. Kingsley. Extra
crown 8vo. 8s. 6d. net.
AN ANGLER'S HOURS. By H. T. Sheringham. Extra crown 8vo. 6s. net.

MACMILLAN AND CO., Ltd., LONDON.

Transcriber's Notes

Obvious printer errors were repaired.

Hyphenation variants retained as in original.
Copyright page showed no date.
Both "putts" (in quoted material) and "puts" (in author's
voice) were present in the original.
*** END OF THE PROJECT GUTENBERG EBOOK THE SOUL OF GOLF
***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United

States and most other parts of the world at no cost and
with almost no restrictions whatsoever. You may copy it,
give it away or re-use it under the terms of the Project
Gutenberg License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country
where you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
 containing a part of this work or any other work associated with
Project Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute

this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or

providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
 payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com