To solve the terminology problem first, the best fit for "pass by value" appears to be the argument. "Pass by value" and what it means depends on how you understand how the program works. The most common meaning is to get a local copy of anything to pass, but the real question here is how to look at what you are ready to deliver. For the meaning of "passing by value", there are two kinds of opinions with obvious differences:
(1) Java passes anything by value. If you pass a basic data type into a method, you explicitly get a copy of the underlying data type. But if a handle is passed into the method, a copy of the handle is obtained. So people think that "everything" is passed by value. Of course, this statement also has a premise: the handle will certainly be passed. But the Java design seems a bit advanced, allowing us to ignore (most of the time) dealing with a handle ourselves. That is, it allows us to imagine the handle as "object" because the system automatically takes care of the difference between the two when the method call is emitted.
(2) Java is mainly passed by value (no arguments), but the object is passed by reference. The premise of this conclusion is that the handle is only an "alias" of the object, so it does not take into account the problem of passing the handle, but simply indicates that "I am ready to pass the object". The object was clearly not passed by value because it was passed into a method without obtaining a local copy of the object. Sun seems to support this view to some extent, because one of the key words "reserved but not implemented" is byvalue (by value). But no one knows when that keyword will work.
Although there are two different opinions, the differences are ultimately caused by different interpretations of the "handle". I intend to avoid this problem in the remainder of this book. It will soon be known that there is no point in arguing about this issue-the most important thing is to understand that the passing of a handle can cause unexpected changes to the caller's object.