• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Java - return types

D

duragezic

Lifer
I'm doing some work with Real-time Java (the product I'm using is based off the Real Time Specification for Java) but I'm hoping my question applies to any type of Java.

One concern of the ability for RTJ to meet the timing constraints is the garbage collector. To test this, I will write simple program that does a lot of dynamic creation and deletion of various objects... something to get the garbage collector to be run a bunch of times, and see how it affects things.

I'm wondering if the following statement is true or false:

In Java, passing return values that are not of a primitive type creates an Object.


I think this should make sense. Thanks.
 
Originally posted by: Lt 486
Actually the object would be created explicitly in the code of the function.
Click to expand...

And then copied to the return value?
 
Interesting, thanks. So that's really pass-by-reference on the return types. What about the rules for parameter passing?
 
Same.
Primitives passed by value.
Objects passed by reference (address of object on the heap is passed).

There are a lot of arguments what to call pass-by-value and pass-by-ref in Java world.

So, puttig it down very simple:
int variable is passed as 32-bit value containing actual 32-bit value of variable.
object variable is passed as 32-bit (or 64-bit) value containing and address of an object on the heap.
 
So the article I linked to above (admittedly old) just gets it wrong, since it says that all method arguments are passed by value, including objects.
 
No, the article you linked is fine. Everything is passed by value, but what's actually passed in most cases is a pointer passed by value. He explains why this is relevant in the article, particularly dealing with reassignment.

 
Well, all these statements can't be correct 🙂. We should probably agree that when we talk about pass by ref vs. pass by value whether a pointer/reference is what is passed is irrelevant. What we want to know is whether the object is copied or not (relevant to the 'swap' problem the article uses as an example). Lt 486 was saying that an object created in the body of a method and then returned is not copied, but just has its reference returned. If the same is also true of method params then the overall semantic is pass-by-ref not pass-by-value. The article, on the other hand, seems to say pretty clearly that objects passed in to a method are copied, i.e. pass-by-value.

So color me confused too 🙂.
 
Originally posted by: Markbnj
Well, all these statements can't be correct 🙂. We should probably agree that when we talk about pass by ref vs. pass by value whether a pointer/reference is what is passed is irrelevant. What we want to know is whether the object is copied or not (relevant to the 'swap' problem the article uses as an example). Lt 486 was saying that an object created in the body of a method and then returned is not copied, but just has its reference returned. If the same is also true of method params then the overall semantic is pass-by-ref not pass-by-value. The article, on the other hand, seems to say pretty clearly that objects passed in to a method are copied, i.e. pass-by-value.

So color me confused too 🙂.
Click to expand...

Yes, it is confusing.
Different people mean different thing by using terms "by-value" and "by-ref".

For some people (group 1) passing value of an address of an object is "pass-by-val", for some - "pass-by-ref" (group 2, including me).

Group 1 calls "pass-by-ref" the following scenario:
passing value of an address of value of an address of an object. so, reference to an object is passed as reference.

Group 2 calls "pass-by-ref" the following scenario:
passing value of an address of an object (which is "pass-by-val" for group 1).

Terminology sucks. I hope its clear now.
 
Ah, yeah, I get what is confusing people. Thanks. Sounds like java is pretty close to C#, and people in that world get confused as well. It just seems clearer, I guess, if you come at it from a background in C++: If the thing you're passing into a method is copied, and changes made to it within the method are discarded when the method returns, that's pass by value. If instead the method implicitly recieves the address of (reference to) the thing being passed, and changes made to it within the method are persistent in the original object after the method returns, that's pass by reference.

It sounds like people get confused over what "thing" is actually being passed into and out of a method that takes an object in managed languages. In Java and C# you never deal with blocks of memory that represent "objects" directly, and so anywhere that you manipulate a variable that has the type of an object, you're actually manipulating a reference to that object. So pass-by-value semantics are respected with regard to the reference itself, but whether that reference and some other reference address the same object is a separate question.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top