Trouble with Java concepts

[Jim Cochrane]

A pretty good definition by the way.

Thanks to all who posted on this. I've learned from this discussion
the conventional terminology and explanation for how arguments are passed.
I'm not sure I'll be using the phrase "pass-by-value" if I need to explain
how passing arguments works, but at least I'll know not to use the phrase
"pass-by-reference".

 

[pentium77]

Hello everyone,
I am slightly confused here. Here is some code:

public class samp{


public int f(StringBuffer str){
if(str == null)
str = new StringBuffer(10);
str.append("inside f");

return 0;
}

public static void main(String args[]){
samp obj = new samp();
StringBuffer str = null
obj.f(str);
System.out.println(str);
}
}

If I run the code above, the System.out.println line prints null. If
however, I allocate a new StringBuffer(10) in main() instead of
assigning it null, then it prints "inside f".

If I replace all StringBuffer with String, it prints null, no matter
where it gets initialized.

My problem is I am not able to explain this behaviour. Can someone
please explain why this is so ?

Thanks in advance.

Best Regards.

Hi,
In Java all variables are passed by value only. A good explanation of
this concept can be found at :-
http://www.yoda.arachsys.com/java/passing.html

Hope this helps,
-MK.

 

[Tor Iver Wilhelmsen]

Actually, the conventional meaning of pass by value is to pass a copy (as
in pass by value in the C language), but this is not the case here,

Yes it is; but the value passed is that of a pointer. Since Java does
not have the pointer syntax or semantics of C, it's hard to miss at
first.

 

[Gary Labowitz]

I would try to explain to an incoming C/C++ programmer that passing objects
is functionally identical to passing pointers in C.

And at that point you would be wrong. Virtually everything you say beyond
that point is also wrong. You are starting with a nonsense concept of
"passing objects" in Java and go astray from there.
Unlike C++, Java does not pass objects. It passes variables. Period. This is
a change in mindset which causes some C++ programmers to think of Java as
"flawed" in some way. Perhaps some Java programmers think of C++ as "flawed"
in the opposite direction. The actually state of affairs is that they are
two different languages (just as C and C++ are) and cannot be thought of in
the same mindset.
I am amused/bemused/frustrated at one time or another trying to teach these
concepts in class and grow weary of arguing with some VB-student about
passing conventions in Java. The only saving grace is to be precise in the
programming language you are using and apply consistent terminology
regardless of which language one is using.

For example, you say
"I would try to explain to an incoming C/C++ programmer that passing objects
is functionally identical to passing pointers in C. Except that since the
use of pointers is implicit (you cannot have an Object, only a reference)
there is no need for the java syntax to constantly mention the fact that the
reference is being used. Thus, you could pretty-much convert java to C by
replacing "." with "->" and putting a "*" before all object (i.e. non-
primitive) variable definitions.

All java objects are on the heap."

This is a hodge-podge of terminology that will lead to a partial
understanding of what is going on, mixes up what a pointer is and isn't,
uses the term "object" in various ways, and drags in operators that don't
exist in one language and have multiple (context sensitive) meanings in the
other. The end result is a statement like
"All java objects are on the heap." which isn't strictly true either (unless
you consider the literal pool as part of the heap, another misnomer).

I prefer the straighter path of defining the terms and using them
consistently. Unfortunately, this takes more space than we are willing to
use in usenet postings, although there have been many and eventually they
all come to the same conclusion; namely, it ain't easy.

 

[Steve Horsley]

And at that point you would be wrong.

Yes, I should have said that passing object in java is functionally equivalent
to passing pointers _to_those_objects_ in C.

Virtually everything you say beyond
that point is also wrong. You are starting with a nonsense concept of
"passing objects" in Java and go astray from there.

Nope. "passing an object", a phrase commonly uses, passes a reference,
functionally equivalent to passing a pointer in C. Not the object.

Unlike C++, Java does not pass objects.

That's what I said.

It passes variables.

That doesn't help clarify things much.

Period. This is
a change in mindset which causes some C++ programmers to think of Java as
"flawed" in some way.

For a newcomer from C/C++, I think it helps to be able to compare what
java does with what C/C++ does, to help them understand what java will do,
in terms of what they know. And I believe that thinking of java as passing
pointers to objects is the closest model a C programmer has to the way
java behaves. Right down to creating NullPointerExceptions.

I know it isn't necessarily a memory address that's passed - it might
be an array index or any other unique value, but since it is impossible
in java to see the actual value passed, the implementation is opaque
and unimportant.

Perhaps some Java programmers think of C++ as "flawed"
in the opposite direction. The actually state of affairs is that they are
two different languages (just as C and C++ are) and cannot be thought of in
the same mindset.

But as with any language you are learning, you have to start by referring
back to the language you know, looking for similarities (and noting the
differences) to work outwards from.

In the same way that I know that "spasiba" (proper spelling unknown) is
Russian for "thank you". I also know this model isn't quite right because
the word is also used for "please" in some circumstances. But I'm two steps
better off than not knowing what the word means at all. And some pedant
insisting 'No it doesn't mean "thank you", it just means "spasiba", why can't
you understand that you moron?' doesn't really help.

No, passing a reference is not exactly the same as passing a C pointer, but
it's close enough in behaviour to get a C programmer started without too many
surprises. And this thread is about java beginners coming from C/C++.

Steve

 

[Gary Labowitz]

Yes, I should have said that passing object in java is functionally equivalent
to passing pointers _to_those_objects_ in C.

That's what I said.


That doesn't help clarify things much.

<snip>

But "passing object" is exactly what you said. And Java doesn't pass
objects. When I say it passes variables I mean it makes a copy of the
contents of a variable into the parameter of the called method. And it
passes one of the nine variable types, which is all there is in Java. The
first eight are called "primitives" in most books, and the ninth is either
"reference" or "reference variable," the latter being preferable in my
opinion since it keeps the emphasis on its being a variable.
Trying to get this across to C++ programmers is important because in C++ you
CAN pass objects by value. And to top it all off, everything allocated in
memory in C++ is called an "object." So, there is a double ambiguity in the
statement for Java users.

It's because of all this that I insist that we say "Java passes reference
variables by value." They are not the same as C++ reference. They are not
the same as C++ pointers. They are Java!

No, passing a reference is not exactly the same as passing a C pointer, but
it's close enough in behaviour to get a C programmer started without too many
surprises. And this thread is about java beginners coming from C/C++.

"...close enough..." is why bridges fall down, and other man-made disasters.
(Check out the poem by Edgar Guest (?)). Also, there is no language C/C++.
That difference makes the discussion about references really difficult,
since they don't exist in C.

 

[Roedy Green]

Unlike C++, Java does not pass objects. It passes variables. Period.

oops. Java does not pass objects. Java does not pass variables.
Java passes the values of primitives and references.

 

[Roedy Green]

"All java objects are on the heap." which isn't strictly true either (unless
you consider the literal pool as part of the heap, another misnomer).

Also the compliler is free to optimise by putting some objects on the
stack. The Jet compiler does that. That gives faster
allocation/deallocation.

Where objects go in Java is automatic. In C/C++ it is under explicit
programmer control.

see http://mindprod.com/jgloss/jet.html

 

[Roedy Green]

Yes, I should have said that passing object in java is functionally equivalent
to passing pointers _to_those_objects_ in C.

Except that in Java terminology, you never pass objects, only
references to objects. In C any can push an entire object to the stack
and pass that as a parameter, not just a pointer to it. You don't
ever do that in Java.

Since the term "passing an object" has a particular meaning in C, it
would be confusing to introduce it to Java with a different meaning.
Imagine how confusing things would get in JNI where you have both Java
and C conventions.

This is all confusing enough without people trying to redefine the
terminology. That is why people attempting to do so get their heads
bitten off.

 

[Roedy Green]

Nope. "passing an object", a phrase commonly uses, passes a reference,
functionally equivalent to passing a pointer in C. Not the object.

It may be commonly used, but when it is, it is incorrect, and one
should strenuously avoid it when trying to explain the details of
parameter passing.

If you must use it, reserve it as shorthand when talking with people
who know that you mean "push the value to the stack of a reference to
an object as the parameter".

 

[Roedy Green]

. When I say it passes variables I mean it makes a copy of the
contents of a variable into the parameter of the called method.

But you are explaining. You don't want to use any terminology not
clearly defined in your explanation. Sometimes a metaphor will help,
but using technical terms in a idiosyncratic way will not.

You have tried to explain something mysterious (passing references) in
terms of something even more mysterious (passing variables) -- like
some private joke. This is vaguely reminiscent of the arguments you
usually get in discussions about religion.

Eventually it has to work by you creating a model in your head of how
it works. For me the model was one based on my knowledge of
assembler. For others it might be based on their knowledge of C.
For others it might be from knowledge of JVM byte codes.

What would do this best is some sort of animation to show how parms
get passed in C and Java. You could see the parms like little logs
with values written on them, and objects like hot air balloons
tethered in field.

 

[Timo Kinnunen]

On Sun, 04 Jul 2004 17:53:23 GMT, Roedy Green wrote:

[Of passing things in different languages]

What would do this best is some sort of animation to show how parms
get passed in C and Java. You could see the parms like little logs
with values written on them, and objects like hot air balloons
tethered in field.

May I suggest that in this animation, references in C++ are to be
represented like pointers in C++, but with a different color.

 

[Stefan Ram]

May I suggest that in this animation, references in C++ are to be
represented like pointers in C++, but with a different color.

Here's an animation:

http://cslibrary.stanford.edu/104/

 

[Timo Kinnunen]

Here's an animation:

http://cslibrary.stanford.edu/104/

Oh damn, they were the same color

 

[Roedy Green]

May I suggest that in this animation, references in C++ are to be
represented like pointers in C++, but with a different color.

The java ones might be represented as having a tendril out to the
corresponding object where the C++ ones have a "house" number.

I remember wishing desperately for some 3D animations when I was
learning organic chemistry. Playing with little springs and wooden
balls was so clumsy.

Years later on late night TV was a series of shorts showing a great
many quite complex organic chemistry reactions animated. It was a snap
to follow what was happening, even if I could not remember it all.

The people who design languages typically are extremely familiar with
what is going on under the hood. They have a mental model of the
internals of a computer. They will never tell it to you. I have no
idea how people who have no assembler background can even begin to
think about programs with no mental picture of what is happening
inside. Perhaps they imagine sheets of paper for each class and
object with places to write down the values.

I also realise my mental images are nothing like the actual invisible
slosh of electrons. There is nothing to see inside.

My mental model is shaped by my early exposure to watching binary
patterns on an oscilloscope as the calculations progressed on my old
LGP-30.

I used to think mostly about the registers, like some giant abacus.

Another image was the system clock like the slave driver in some Roman
tireme, where everybody jumped on the beat of the clock/drum.

Sometimes I use a mental image like a jungle, where everything is tied
to nearly everything else by vines. Your job is to try to ignore the
underbrush to see the overall pattern of important connections.

Queues, particularly queues of ready tasks are like people lining up
at a doctor's office, ready for their shot at the important man.

Transaction processing is like an assembly line.


Another analogy I use is plumbing. You want the facilities available
where needed, and you want the piping accessible when needed, but you
don't want the pipes running through the middle of the living room
obscuring the view of the fireplace.


Another analogy I use is housekeeping. Some coding you do to keep the
computer happy. Other code is key to the algorithm. The key is to
keep the busywork out of the way of the crucial code so that it does
not obscure it. Ideally, your tools should automatically generate the
housekeeping, much the way CSS style sheets generate precise HTML
layout.

 

[Roedy Green]

Here's an animation:

http://cslibrary.stanford.edu/104/

That is helps explain the basics of pointers. We need something
similar for parameter passing.


One that showed the various possible styles including Algol callbacks,
etc. and showing you how to simulate them in Java.

 

[Roedy Green]

Oh damn, they were the same color

they used the same claymation and sound with different text overlays.

That is why he referred to Objects as "pointees". He wanted a generic
term he could use in any language.

 

[Gary Labowitz]

oops. Java does not pass objects. Java does not pass variables.
Java passes the values of primitives and references.

Yes.

 

[Gary Labowitz]

Since the term "passing an object" has a particular meaning in C, it

Well, in C++, unless you mean the definition that "anything that is
allocated in memory is an object."
C has no objects in the OOP sense.

 

[Gary Labowitz]

The java ones might be represented as having a tendril out to the
corresponding object where the C++ ones have a "house" number.

I tried something like the Stanford animation in class once, using index
cards as storage locations. Each card had a number (the address) and written
on it was a number (the data). Passing by value involved the CPU (one of the
students) copying the value on an index card to the blackboard (the stack)
and the called routine (a student) copying that onto his own index card
(local variable in the routine). Passing by pointer involved putting the
index card number on its own index card and then passing that by value.
Passing by reference involved the calling routine (another student) allowing
the called routine to look over his shoulder at the original index card. It
all got too involved, took too much time, and I'm not sure the students knew
what was going on anyway since they still made the same old mistakes
(passing a copy of a variable and modifying the copy).

BTW, are we the only ones here who ever worked on an LGP-30?