> I'd like to see some more context from Eckel's Chap. 3 section.
> Specifically, how does he introduce the aliasing issue for the case
> of Java? How does he define aliasing?
A more objective summary than what I just posted is:
In Java, almost everything is on the heap, and the names you manipulate
are really the names of the pointers. So
X = Y
is (usually) equivalent to Ada's
X : Number_Access_Type;
Y : Number_Access_Type;
X := Y;
Thus, a Java programmer has to think about aliasing almost continuously.
It's like telling an Ada programmer, "You are required to use access types
and the heap for anything larger than 32 bits. And you are not allowed to
use ".all" I'll tell you a workaround when the course is almost over."
Of course, much code will use the object's methods to change things, if
the object is well designed. Perhaps I'll change my tune after more Java
experience, but at the moment, this seems counter-productive.
Eckel offers a FREE download of his book in PDF. This is actually
more up-to-date than the published version.
http://www.BruceEckel.com (his C++ book is also there)