- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
No, a pass by reference method argument means that if the called method updated the argument then the value of the variable used as the parameter in the calling method would change too.
void foo(Object ref) { ref = new Object(); }
Object o1 = new Object(); Object o2 = o1; foo(o1); // if pass by ref then o1 != o2 // if pass by value, as Java is, then o1 still == o2
Admin
My thoughts exactly. Using this logic, everything is Pass by Value in some way.
Admin
My thoughts exactly. Using this logic, everything is Pass by Value in some way.
Admin
You are kind of right, yet kind of wrong.
In practice Java does not work the way you are describing. Let me explain.
You create an object, and the variable that points to that object. Remember these are in two locations in memory. The variable is simply a pointer that addresses a memory location.
Now when this pointer is passed in to a java function it is passed by value. What this means is that a new variable is created that has the same value as the variable passed by value, it points directly to the object.
If this pointer was passed by reference, you would have something slightly different. A new variable would be created that would point to the memory location of the first pointer which points to the object.
So passing by value you are actually bypassing the original pointer, but by reference you still have to go through the original pointer to get to the object.
Admin
Sandy has it right. Passing a reference by value is different than passing a value by reference.
Admin
What's really irritating about all this is that, when Java was introduced, I specificly remember part of the sales pitch being 'No More Pointers!'. Which, as this entire discussions illustrates, is bullshit.
Captcha: photogenic (I sure am)
Admin
What Java got better by "removing pointers" as you say, is the whole memory allocation/deallocation problem, as well as suppressing the dangerous side effects of pointer arithmetic and the likes.
Admin
The very first thing (after HelloWorld) most folks try in Java is usually something along the lines of:
Integer value; value.someMethod(); // generates NullPointerException
Admin
Captcha: WHO GIVES A FLYING FUCK!!
They're all tech related you f'ing morons!!
Admin
One of my former coworkers (an extremely bright and talented programmer) was absolutely certain that, as you state, it was not possible to change the value of an immutable object. I wrote a very short program using JNI to get at the underlying bytes, and changed the value of a String from Hello to World. Without having seen the code, it took him quite a while to figure out how I was able to do it.
Admin
That won't even compile.
Admin
This WTF could have occurred if someone kept changing the definition of someMethod() back and forth between int or string.
When that happens, I typically will go into that person's code myself and add an overload.
Admin
Look, you all misunderstand. Java always optimizes code by finding a less primitive way of representing data. This is a feature. Other more primitive language will still let you deal with numbers as primitive integers!
If you do want to deal with a primitive integer for some reason (not recommended) you need to keep reminding Java, or it will auto-cast it to an object type. The real WTF here is that the developer wrote a function that takes a primitive integer!
Admin
"Java is always Pass-By-Value. The confusion is from the fact that when passing an object, it is the objects reference that is being passed by value." ~Tim
And that's called.... "Pass by reference"....
Admin
Yep I have learned lots of ways NOT to do things from reading here.. :-)
Yours Yazeran
Plan: To go to Mars one day with a hammer.
Admin
This looks a lot like a developer IDE problem. Likely, it used to be an int (the base type) that it would accept, and the developer changed it to accept an Integer (the class). Then the IDE went through and made all the changes necessary to accommodate the change, and the developer let it without reviewing the changes.
I can think of several reason why and why not to change from 'int' to Integer, but it really is bad practice to let the tool make reviewed changes to code.
Oh, and I didn't read ALL the comments before posting, so this may not be the first time some put forward this theory.
CAPTCHA: initech.... SWEEET!!!!
Admin
I don't see any problem with it. Sometimes you want a primtive, opaque value. Sometimes you want an object. Java 5 autoboxes, so that interconverting between the two representations is syntactically simplified.
Admin
That tangled knot almost looks like an intentional obfuscation, except for the the potential performance implications of such gymnastics...
And yes, I've seen the same sort of twisted goo in various languages, and it typically seems to result from either a fundamental confusion over how variables work, or an inheritance of code by developers less experienced than the original author who thereafter hacked and rearranged it into some rather odd constructs...
Admin
A magic number that's used more than one time, certainly bad. But (as near as we can tell) a zero passed one time, in one location? Not worth the effort, especially if some nimrod is going to declare the enum value as ZERO.
Admin
No, it is not. Really not. Read the links given by an earlier poster. "Pass by reference" is a technical term of compiler building with narrowly defined meaning, and by that definition, all Java method parameters are passed by value.
Admin
hah... delivered code on one of the largest airlines websites
public class UpdateResponseDTO{ private boolean success; public Boolean isSuccess(){ return new Boolean(success); } }leveraged of course something like
if(request.execute(requestParams).isSuccess().booleanValue()){ //blah }refactored to a much cleaner if conditional by another enterprising developer to read
UpdateResponseDTO response = request.execute(requestParams); Boolean successfullOperation = response.isSuccess(); if(successfullOperation.booleanValue()){ //blah }I guess returning a boolean in the first place just didn't have enough patterns in it. :)
Admin
Or like it was done in Smalltalk (my first OO love) nearly 30 years before Ruby.
Admin
And to further illustrate the point:
Passing a pointer by reference: Object <- Pointer1 Becomes: Object <- Pointer1 <- Pointer2 Because it is a reference to the pointer, the address of the passed in object is what is passed when passed by reference.
Passing a pointer by value: Object <- Pointer1 Becomes: Object <- Pointer2 Because the value of Pointer1 (the address it is pointing to) is passed in and the new pointer points to that location.
Ultimatly giving you the exact same results but with one less jump. The only reason you would really need to worry about this is for performance reasons, try this same example but walk down a call stack 10 levels and you will see what happens.
This is a basic idea and the sole difference between passing by reference and passing by value. The real WTF is that half of us apparently don't understand it.
Admin
The code given is actually very, very clean and perfect considering most "offshore" developed Java code.
I would have more expected something along the lines of: try { //IntegerEval #1106 int x = new Integer( 0 ).intValue();
} catch (IOException e) { e.printStackTrace(); e.printStackTrace(System.out); IntegerEval1106Failed = TRUE; } catch (Exception e) {
e.printStackTrace(); e.printStackTrace(System.out); IntegerEval1106Failed = FILE_NOT_FOUND; } IntegerEval1106Failed = FALSE;
Admin
Yes, a reference is a pointer to an object. When working with Java objects, your local variables are always references, not the actual objects.
Pass by value / pass by reference refers to how the local variables are passed on to functions. Are you directly passing the value of those variables, or the address of them? It doesn't matter what those variables actually are.
Here's where the difference comes in...
void function() { String x = new String("Hello world"); function2(x); if (x != null) System.out.println(x); else System.out.println("x is null"); } void function2(String y) { y = null; }If parameters are passed by value, function() will print "Hello world". If parameters are passed by reference, function() will print out "x is null". With Java, you'll get "Hello world" as your output.
(Yes, I realize the "new String()" isn't necessary, but I'm trying to make it more obvious what's going on)
Admin
Part of the confusion seems to revolve around the fact that the word "reference" is being used with two different meanings. A similar problem occurs when talking to people about objects in languages that feature some distinct kind of object called "object"--people keep assuming that objects in general and the "object" object in the language are identical, when they're not. The opposing sides of the argument choose the meanings of the words that make their premises match reality (and since compilers are relatively abstract beasts, the realities might even be slightly different). Since neither the correct nor incorrect side of the argument sees any logical contradiction in what they're saying, the only way to figure out who is right is for both sides to agree on a dictionary which will ultimately show one side is wrong. Agreement of this kind is hard, so these arguments go on for days.
It's much easier to do this in a language that doesn't have anything in its jargon called a "reference", but has objects with reference semantics (even broken ones).
So for example in C we can clearly see that arguments are passed by value, even when the arguments are pointers. No confusion since C doesn't have anything called a reference (other than the verb "dereference" used to explain what unary "*" does), and anyone who has any success programming in C quickly learns how pointers behave when they're used directly and when they're used in expressions with operators that turn them into the objects they point to. Both cases are syntactically distinct--"p" is the pointer, "*p" is the object, "p->m" uses p as a pointer to an object with some member named "m", and "p.m" is a syntax error. Clearly C is a pass-by-value language, even when the value happens to be a pointer.
In C++ we can actually choose which arguments are passed by reference and which are not. Here we have no confusion since a C++ reference has no distinct identity from its underlying object, so the word "reference" has only a single meaning when talking about the things in C++ called references and passing arguments by reference. C++ does not allow the memory location implied by a reference to be modified, so there's no such thing as assignment between references in C++. Instead, the assignment operator of the lhs object (not the reference) is called with the rhs object (not the reference) as its argument. By default, this performs member-by-member copy of the rhs object on top of the lhs one, so if you pass a reference as a function argument you get pass-by-reference semantics. No confusion here, unless you're expecting C++ references to behave like C pointers or Java objects. "r1 = r2" replaces the object at r1 with a copy of the object at r2, but r1 and r2 point to distinct memory and future modifications of r1 will not affect r2 and vice versa (unless the caller intentionally passed r1 and r2 to the same object in the first place). "r1.m" is a member named "m" of the object that r1 is a reference to. "r1" is valid, but only if the object that r1 refers to is of a type that has a unary "" operator. "&r1" in an expression is the contents of the implied but not directly accessible pointer in r1 (and its type is pointer-to-whatever-r1-was-a-reference-to), while "&r1" in a declaration creates an implied (but not necessarily instantiated, if the C++ compiler can get away with it) pointer to some object. There's a reason why the C++ standard is ~750 pages long.
In Java we have what C++ people would call "smart pointers" or "proxies" that contain the address of, but are distinct from, the objects they point to. Java calls them "objects", which is a misleading name since the one thing they are not is an object. When people want to explain what the Java "object" objects really are, they have to borrow terminology from other languages, and if they use the word "reference" when they do so then people get confused. When you assign two pointers (non-primitive variables) to each other in Java, the lhs pointer (not the object) is replaced with a copy of the rhs pointer (not the object), and both pointers point to the same object (both are aliases for the same memory). Neither object is actually modified by this process (well, maybe the lhs object is destroyed); however, either pointer can be used to modify the object in the future. The syntax is less explicit in Java--"o" is the pointer, "o.m()" calls method "m" on the object that "o" points to, "o2 = o1" makes o1 and o2 point to the same object that was previously available only through o1. The available operator set is limited, which makes it somewhat harder to observe how the objects really behave--in Java you can't easily print out the addresses of a bunch of objects and object variables and see that they're different. Unlike C++, the memory address (pointer value) implied by a Java object is modifiable but only in strictly limited ways (i.e. by assignment from another valid object).
When a Java object is passed as an argument, only the pointer that is accessible from the language is passed--the object remains on the heap where it was allocated. We still call this pass-by-value since the pointer value can be modified in the method without affecting the pointer value in the method's caller. If that condition was not met, Java would probably be a pass-by-reference language.
Admin
I just want to say that it is generally ok use numeric literals of -1,0 and 1. Some coding conventions enforce just 0 and 1 or just 0 and -1, but in the above example the use of literals is acceptable (not to excuse other issues with the code)
If during future development the value may change then it should have been originally coded as a constant but we don't know if that was the case here. It is very likely the developer was using the value of 0 to represent a value that will always, regardless of future development be 0 then he/she should use a literal.
If we were to keep a constant called one_or_maybe_two and apply that through out the whole code it is very like that one of the instances may need to change and the others don't. This is because it these numbers are used so much through out the code. To handle this future proofing we would need to keep an individual constant for each instance it is used it is used in code, which now starts to defeat the purpose of using constants in the first place.
I think Rob is incorrect and if he looks at enough open source projects, read a few coding conventions or talked to a developer with a few years experience he may be a bit hesitant to define a 'real programmer'
Admin
this code is pretty bad. The programmers should of done this instead.
someMethod(0); someMethod(1); someMethod(FileNotFound);
Admin
Actually you don't even need to go the JNI route. Provided you are not operating under a SecurityManager simple reflection can change any 'immutable' object.
Admin
Admin
It's not the first time I've seen this. I was going to post to say that it'll just get optimized away. The real WTF is that it doesn't get optimized away (at least on my Sun JVM). This isn't a difficult special case to look for.
Admin
You obviously do not understand the basic difference. In C/C++ pointers are actual memory locations which can be altered by "pointer arithmetic", i.e. you can add or substract values from pointers and thua effectively step forward and back in memory, which is of course extremely dangerous when not done with extreme care.
Because this was one of the major sources of segmentation faults and sometimes memory leaks, this kind of pointers where not intorduced in Java.
But of course you do need something like Java "references" (which is not exactly the same as C++ references, see the long post above by Zygo (110856) where this is explained in detail) because instances are allocated on the heap and have to be accessed (referenced) somehow. These Java references have very concise semantics and are therefore less error prone.
Additionally, the second major problematic C/C++ feature, namely explicit memory management, was replaced by the concept of garbage collection in Java. It is therefore much harder to create a memory leak in Java, albeit not impossible: If you hold on to "hard references" longer than intended (or indefinitely), the referenced objects (instances) are never garbage collected and continue to take up heap space.
So in the C/C++ sense there are really no "pointers" in Java itself. The virtual machine is of course using them internally in abundancy ;o)
CAPTCHA: knowhutimean ;o)
Admin
Offshoring and outsourcing are a measure of the competence of a company's IT management. It is measured by a simple formula...
rManagementCompetence = 1 / (1 + (rOffShoring + rOutSourcing) )
In other words, if they were competent as managers, they should be able to develop software inhouse for less.
Admin
Admin
Passing a reference by value is not the same as passing a value by reference. If the method being called changes the value of the parameter (not some part of the object the parameter's value may refer to) then with pass by reference semantics that change is seen by the caller. With pass by value semantics it isn't.
See http://www.pobox.com/~skeet/csharp/parameters.html for an explanation in C# terms - it's basically the same in Java, except Java doesn't have out/ref parameters or user-defined value types.
Admin
This reminds me of a subtle memory leak I found once. It went something like this:
BSTR bstrOrginal = some random bstr; BSTR bstrCopy = bstrOriginal.copy();
If you can't spot the memory leak, the problem is that .copy() generates a copy. Then = is overloaded and generates a copy and assigns it to bstrCopy. bstrCopy will be cleaned up when it leaves scope, but the temp .copy value is leaked.
The realt WTF is i have to "sign on" every hour, AND it doesn't remember who I am
Admin
Passing by ADT makes sense sometimes. Like when another piece of code needs to change the ADT and the function the ADT is being passed to needs access to those changes.
What stuffs it up is that they don't seem to grasp the differences between temporary and local variables sufficiently to make use of them sensebly.
Admin
There is no reason not to call someMethod(0); unless there is both a someMethod(Integer) and a someMethod(int), in which case the programmer should be fired for deing that.
Admin
should've.. not really english either.. but it does get used (especially in the vernacular.)
Which, I suppose you could misunderstand (if your hearing isn't that great) to be 'should of' instead of the contracted 'should have'.
captcha: stfu. heh.
Admin
Are you retarded?
Admin
The biggest WTF is the amount of people who don't understand what pointers/references are, and how Objects really work.
Also the fix to the WTF code is also a WTF(not as much as the original code but still WTF, I some cases this would be better than just inserting the value it's self). The best solution would be to do as other people said.
someFunction(0);
or:
class SomeClass { private static final int CONSTANT_NAME = 0; ... public void someFunctionThatCallsSomeFunction(){ ... someFunction(CONSTANT_NAME); ... } ... }Admin
Admin
Admin
I've never programmed in VB but it's an amazing lack of understanding within Java. In fact, since Java 5, there has been a feature called autoboxing where the compiler handles all this stuff for us so we don't need to even worry about it in many situations. That code is just written by some very junior Java developer. That does NOT mean the entire app is junk. It just means that some very junior person wrote that part of it. We were all junior developers at some point in time.
Admin
It results from a complete misunderstanding of how variables work.
I've seen the same thing in C++ code, made offshore, as far back as 1996.
Admin
It's a misunderstanding of the spoken English. Commonly English speakers say "should've" instead of "should have", this gets interpreted as "should of".
Admin
If you pass by Reference, you are passing the 4 bytes to the function.
If you pass by Value, you are passing the 16K Object (meaning it gets recreated at another 4 byte memory location, and is now referenced there).
There's a damn reason that in C++ the int &X thing is there...
/sigh.
Admin
And when the requirements change, do this:
private static final Integer ZERO = new Integer(1); someMethod(ZERO);
Admin
This reminds me of a piece of crap I downloaded once, which included the magic line (this is VB.NET mind!)
i = val(str(8))\
I saw, I shuddered, I deleted.
Admin
Sadly, this is something I've seen far too often. An even worse construct that has cropped up recently is:
boolean result = value ? new Boolean(true).booleanValue() : new Boolean(false).booleanValue()
How many WTFs are in that!???