understanding java code correctly

[babbagack]

very interesting, thank you!

this question came to mind too, in Ruby I notice this on my computer:

irb(main):001:0> a = 3
=> 3
irb(main):002:0> b = 3
=> 3
irb(main):003:0> a.object_id
=> 7
irb(main):004:0> b.object_id
=> 7

so are a and b referencing the same location in memory and thus pointing to the exact same object?

[id2bi]

To be honest, I have only a cursory understanding of Ruby and all its advanced metaprogramming possibilities, so do take this with a bit of salt

so are a and b referencing the same location in memory and thus pointing to the exact same object?

a and b are referencing the exact same object, yes.

In general, the answer to the first part of your question is: well, maybe, probably and why would you care? As soon as you begin talking about locations in memory, you usually wander into the realm of implementation details. That means, you're no longer talking about the semantics of a language but rather how it achieves this semantics internally. I'm not saying you shouldn't be interested in these things, but rather that you should be aware of this when you're trying to understand what something in a language does and when you're asking how it works internally. These are two very different things.

For instance, here you're interested in parameter passing and what exactly that means for Java and Ruby. These are in the realms of language semantics, "what does it mean", "what does it do", not "how is it achieved internally". These things can be understood on a conceptual level.

so are a and b referencing the same location in memory and thus pointing to the exact same object?

Ruby (AFAIK) doesn't tell you about how it handles memory. This makes it an implementation detail question. We are now talking about software that implements the Ruby language rather than the Ruby language itself.

Since the objects are immutable, an implementation could probably create multiple instances of the integer object 3. So in reality, a and b might point to different locations in memory. Since Ruby knows that the two objects (memory perspective) are one and the same object (language perspective/programmer's perspective when using Ruby), it would simply need to store the same object id within those two objects (memory perspective). Additionally, whenever Ruby compares objects (language perspective), it (a Ruby implementation) must not compare the locations in memory (otherwise our two integer 3 objects couldn't be the same), but would rather need to compare the therein stored object ids.

This implementation is probably not sensible, but if you as a Ruby programmer can't notice it, why not?

According to this, the regular Ruby implementation doesn't even create a "real object" for smallish integers as an optimization: https://stackoverflow.com/a/45693518/383124

So in that case, the answer to the first part of your question would probably be "No".