...

I thought you had made a typo with 'JAVA', but..

<http://images.amazon.com/images/P/0131002252.01.LZZZZZZZ.jpg>
..certainly speaks a thousand 'JAVA's.

...

What does it get right?

I would toss it, except for the fact it
is your 'class' text. (no apologies for pun)

He is probably a professor.  They learn to talk that way.

Try my explanation. See if it makes any more sense.

start at http://mindprod.com/jgloss/static.html and chase the links.

Personally I like to think of methods being per object rather than per
class.
The same method is executed in parallel for many objects.  So there are as
many instances of the methods as there are objects.

--
Mike W

I think you are making a mountain out of a molehill.  Yes, there is
only one set of methods stored in memory.  Big deal.  That saves
memory, since the code for the methods is identical.

The point is that in OOP, an objects instance variables and instance
methods are joined-at-the-hip, unlike procedural languages where the
data and methods are separate.

I wouldn't waste too much time worrying about a minor inaccuracy.

Yes, that's true.

I believe you're confusing model with implementation.  It's not
specified in the general OO model, nor in Java, whether there is only
one copy of a method's code held in memory, or one copy per object, or
anything else.  The one-copy case is more likely than the per-object
case for performance reasons... but that's an implementation concern
about the existence of code; the ownership of a method is a different
matter.

You'll often hear OO people proclaim that an object owns its "state",
"behavior", and "identity".  What we mean by an object owning its
behavior is that the behavior depends on which object you're working
with.  Basically, that's polymorphism.  You can interact with two
objects in exactly the same way, and they may act differently because
they are different objects.  (Your author's use of the term
"operations" instead of "behavior" is somewhat ambiguous because the
former could be interpreted as the client interface, i.e. the set of
possible operations, which is not owned by the object at all.)

Note that this doesn't conflict with methods being defined in classes.  
In Java, they definitely are (though there are other class-less or
prototype-model OO languages where this isn't necessarily the case
either).  Another way of putting it is that the point really relates to
locating knowledge.  When code A interacts with object B, is the
behavior determined by prior knowledge from A, or from B.  In an OO
language (and using OO language features... hence, not with static
methods in Java, nor with non-virtual methods in C++), the answer is B.

I hope that clarifies things.  In essence, I think your author is right.

One thing I liked is how it started with a simple construct and then
showed how using it in more complicated cases was ugly but there's a
more powerful construct that makes the code better, progressing from
simple IF to IF ... ELSE to nested IF ... ELSE IF ... to select case.
For example:

Good:
if (x<0) ...;

Bad:
if (x<0) ...;
if (x>=0) ...;

Replace above with:
if (x<0) ...;
else ...;

Nested OK:
if (...)
 if (...) ...;
 else ...;
else ...;

Ugly:
if (...)
 ...;
else
 if (...)
   ...;
 else
   if (...)
     ...;
   else
     ...;

Better:
if (...)
 ...;
else if (...)
 ...;
else if (...)
 ...;
else
 ...;

Not the best:
if (n=1)
 ...;
else if (n=2)
 ...;
else if (n=3)
 ...;
else
 ...;

Best:
switch (n) {
 case 1: ...;
         break;
 case 2: ...;
         break;
 case 3: ...;
         break;
 default: ...;
}

I would hope an introductory tutorial on control structures in LISP
would likewise start with simple (if test action) then introduce (if
test action otheraction) then nest them a little, then replace deep
nesting with COND, then replace special case of COND with
(case n
 (1 ...)
 (2 ...)
 (3 ...)
 (otherwise ...)
 )

(Same hope for tutorial for any other language that has these same
kinds of control structures.)

Another thing I like is that he has lots of NOTEs that explain side
things that readers might worry about. Most of these are premature in
some sense, but it's still nice to see the topic mentioned in a NOTE at
first opportunity rather than just left hanging until several chapters
later.