Java and C are both pass by value only.  However, the possible values
differ.

In Java, you cannot have a 'stack object'.  Within a method:
Object object=new Object();

The Object resides on the heap.  Only the variable, object, resides on
the stack.

So this is somewhat related to:

void *pointer=malloc(100);

So the *value* passed to a method is the reference (a reference is a
pointer [1] ).

Tony Morris, the guy who wrote JTiger, wrote something on this. [2]

[1]
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#106237
[2] http://jqa.tmorris.net/faq/GetQAndA.action?qids=37&showAnswers=true

oh yes - its coming back now - cheers.

yes actually that will do it - but you have to be careful if you're using
compound classes (ie classes that contain references to other objects).

For example:

<java code snippet>

class SomeClass
{
  private int attribute;

  public SomeClass()
  {
     attribute == -1;
  }

  public void setAttribute(int i)
  {
     attribute = i;
  }

  public int getAttribute()
  {
     return attribute;
  }
}

class Money
{
  int amount;
  SomeClass someClass;

  public Money()
  {
     amount = 0;
     someClass = new someClass(); // attribute = -1;
  }

  public Money(Money old)
  {
     this.amount = old.amount; // safe
     this.someClass = old.someClass; // dangerous!
  }
}

Money aMoney = new Money();
Money bMoney = new Money(aMoney);

bMoney.someClass.setAttribute(5);

if(aMoney.someClass.getAttribute() ==
 bMoney.someClass.getAttribute())
    System.out.println("Error!");
</java code snippet>

Here you will have two different objects aMoney and bMoney in memory,
however - and this is something a lot of people make mistakes against -
when changing bMoney.someClass you're also changing aMoney.someClass!!

Why?  Because aMoney.someClass and bMoney.someClass point to the same
object in memory, even though aMoney and bMoney are different objects.  
This is because the copy constructor has an error: it makes the someClass
reference in the new object point to the same memory space as someClass
in the old object.

This is a very dangerous and often overlooked mistake.

Yes that's what I meant.  I haven't studies heaps & stacks in detail, so
I kinda make up my own words ;-)  Here, bMoney is the name of the actual
object in memory, while aMoney is actually the name of a pointer to an
object in memory.  In Java, every variable (except for primitives) is a
pointer to an object - or actually a reference, but it looks a lot like a
pointer to C++ programmers.

 From the point of view of the JLS3, a "reference" is a term of
 the specification of the language Java, while a "memory
 address" is not. So the meaning of "reference" is specified,
 while the meaning of "memory address" is not.

 (JLS3 mentions "address" twice in 17.5.1, but this only
 applies to the semantics of final fields.)

In the early JVM a reference was a handle, the address of an
addresses. That was how the JVM planned to move objects around without
having to find and patch all the references to them.

In C++ a pointer is a memory address, no discussion about that.  However in
Java, like you said, a reference is not defined as being a memory address,
and could be implemented very differently in any VM.  It is entirely
possible that it is indeed implemented as a direct memory location, but
saying that a java reference is a memory address does not hold true -
unless you're talking about a specific VM of which you know it to be true.
That's what I meant.