Classic Java language WTF
-
Points if you can figure out why these methods return the values indicated.
static boolean compare1() //returns true
{
Integer a = 300;
Integer b = 400;
return a < b;
}
static boolean compare2() //returns true
{
Integer a = 127;
Integer b = 127;
return b == a;
}
static boolean compare3() //returns false (!)
{
Integer a = 128;
Integer b = 128;
return b == a;
}
-
@subanark said:
Points if you can figure out why these methods return the values indicated.
I suspect you answered your own riddle:
@subanark said:
Filed under: Java
-
I don't really know Java, but I would assume... That at 128, new objects are instantiated for each Integer while there are existing objects cached for a range up to 127?
-
The simple solution is to add a webservice layer in here.
-
@quamaretto said:
I don't really know Java, but I would assume... That at 128, new objects are instantiated for each Integer while there are existing objects cached for a range up to 127?
Looks like this is a test because somone does not trust the JVM doing object creations... This is actually useful because the code might return different values depending on the JVM. There are multiple JVMs out there that follow the java spec. == means that you are doing a primitive comparison, well Integer objects are pointers, so you are comparing pointers. Since you are using an implicit casting the writer wanted to make sure that the JVM follows a certain behavior...
Having said that, this is the only rational reason I can think of for doing that. If my assumption is true, then the coder is retarded because he should be using .equals or just do Integer.intValue and do his thang, if JVM behavior can be different.
Ok done.
-
@MasterPlanSoftware said:
The simple solution is to add a webservice layer in here.
Clearly this can be extracted to a propper class hierarchy. We create two servers which create two integers, then they send using Remote Method Invocation an invocation of a comparison and reply with a SOAP package to a third server which picks up the response and restarts the computer.
-
-
I wrote a quick "hello world" app incorporating the OP's code. Does not compile under JDK 1.4 (no, I will not upgrade my Java SDK):
In any case, I don't think object references can be compared with relational operators such as "<". I think only "==" and "!=" are defined for objects.$ javac bla.java
bla.java: In class `testprog':
bla.java: In method `testprog.compare1()':
bla.java:7: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer a = 300;
^
bla.java:9: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer b = 400;
^
bla.java:11: Incompatible type for `<'. Can't convert `java.lang.Integer' to numeric type.
return a < b;
^
bla.java: In method `testprog.compare2()':
bla.java:19: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer a = 127;
^
bla.java:21: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer b = 127;
^
bla.java: In method `testprog.compare3()':
bla.java:31: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer a = 128;
^
bla.java:33: Incompatible type for declaration. Can't convert `int' to `java.lang.Integer'.
Integer b = 128;
^
7 errors(I apologize if the Java language has changed significantly since 1.4 to allow this kind of stuff. Obviously I don't do Java in my day job.)
-
@MasterPlanSoftware said:
@subanark said:
Points if you can figure out why these methods return the values indicated.
I suspect you answered your own riddle:
@subanark said:
Filed under: Java
Is this a Java troll? Every language has its WTFs, I just happen to know Java very well, and where the obscure oddities occur. This one is of paticular intrest since its not some obscure API, but core to the language, and it is very easy to see how a programmer could make the assumption that comparing Integer values this way is valid.
I know some C#, C, and C++. If you want I could pull out language oddities from those too.
-
@CodeSimian said:
In any case, I don't think object references can be compared with relational operators such as "<". I think only "==" and "!=" are defined for objects.
Yeah, this looks like the classic noob assumption that Integer is the same as int.
http://mindprod.com/jgloss/intvsinteger.html
I dunno, Java is not my thing, but I vote the OP as TRWTF.
-
(I apologize if the Java language has changed significantly since 1.4 to allow this kind of stuff. Obviously I don't do Java in my day job.)
Yep, this oddity was added in Java 1.5, where automatic conversion from primatives to/from their wrapper classes is done.
-
@subanark said:
Should've guessed. Is it also doing the implicit conversion when you use "<", ">", ">=" and "<="? That seems dangerous, because it makes the following code ambiguous (to the novice programmer, not the compiler):(I apologize if the Java language has changed significantly since 1.4 to allow this kind of stuff. Obviously I don't do Java in my day job.)
Yep, this oddity was added in Java 1.5, where automatic conversion from primatives to/from their wrapper classes is done.
Integer a = 300;
Integer b = 400;
return a == b; // Is this supposed to compare Integer references or int values?
-
@subanark said:
I just happen to know Java very well
Obviously not. You don't seem to understand primitives vs objects.
@subanark said:
it is very easy to see how a programmer could make the assumption that comparing Integer values this way is valid.
Perhaps, but most of the newcomers who are ever going to become anything actually RTFM and move on. This is the argument between understanding the language topically, and actually having a core understanding of programming.
@subanark said:
I know some C#, C, and C++. If you want I could pull out language oddities from those too.
So could I. For instance, this same thing *should* occur in C#. What is your point though? That you don't actually understand any of those langauges?
-
I assume that autoboxing of an Integer works differently for values above 127, but TRWTF is that the programmer didn't declare them as int, since even if he did need to use them as Integer, he could use autoboxing to handle that, since this is definitely Java 5 code.
-
@Physics Phil said:
TRWTF is that the programmer didn't declare them as int
Right. There are very few instances I can think of at the moment that require you to use an Integer and not just an int.
-
@MasterPlanSoftware said:
Yeah, this looks like the classic noob assumption that Integer is the same as int.
http://mindprod.com/jgloss/intvsinteger.html
I dunno, Java is not my thing, but I vote the OP as TRWTF.
The part I don't get is why does == work for 127 and lower but not for numbers larger than 128?
-
@MasterPlanSoftware said:
Actually, I checked and Java 1.5 added the "autoboxing" language feature, which converts primitives to object and vice-versa, like subanark said. Hmm, now that I think of it, I was interested when I first read this years ago, shortly after I finished school (which was my last exposure to in-depth Java programming), then I obviously forget I ever heard about it. Go figure.@subanark said:
I just happen to know Java very well
Obviously not. You don't seem to understand primitives vs objects.
EDIT: I found the answer to the OP's challenge (okay, I cheated and used Google, instead of relying on my own poor knowledge of modern Java)
http://www.davidflanagan.com/blog/000022.html
Wow, that autoboxing spec sucks!Another wrinkle is that we'd get different results if we'd used autoboxing to create the two wrapper objects we wanted to compare. Unlike the code above, this code prints true:
Integer i = 0, j = 0;
System.out.println(i == j);
<font color="#000000" size="2">The reason is that the autoboxing spec requires that small integers (-128 to 127) always box to the same wrapper object. Implementations are encouraged, but not requied, to do the same for larger values as well. So if we used 1023 instead of 0 in the code above it might print "true" or it might print "false".</font>
-
@CodeSimian said:
@subanark said:
Should've guessed. Is it also doing the implicit conversion when you use "<", ">", ">=" and "<="? That seems dangerous, because it makes the following code ambiguous (to the novice programmer, not the compiler):(I apologize if the Java language has changed significantly since 1.4 to allow this kind of stuff. Obviously I don't do Java in my day job.)
Yep, this oddity was added in Java 1.5, where automatic conversion from primatives to/from their wrapper classes is done.
Integer a = 300;
Integer b = 400;
return a == b; // Is this supposed to compare Integer references or int values?
Boxing occurs whenever the operation would not be valid without boxing. This is doen to maintain backwards compadibility. It would not be a good thing if older code would compile differently under a newer compiler. In this case == and != are valid for objects, while <. >, <=, >= are only valid if both sides were an int. The reason it works for values between -128 and 127, is that as you guessed, they are cached for values in that range.
When a boxing occurs the compiler using the valueOf method in the wrapper class. So...
Integer a = 127;
changes to:
Integer a = Integer.valueOf(127);
In this trivial case it is clear that the programmer should have been using int instead of Integer. But some times this is unavoidable, since generics can only have Object type parameters...
List<int> is not a valid type, but List<Integer> is.
Due to boxing though, we don't need to:
list.add(list.valueOf(3));
but instead with boxing we can:
list.add(3);
Very few programmers read the entire language spec. Most just try and see if it works, which for this case it works for values between -128 and 127.
-
@subanark said:
Very few programmers read the entire language spec. Most just try and see if it works, which for this case it works for values between -128 and 127.
But what about the blog I quoted:
<font color="#000000" size="2">
The reason is that the autoboxing spec requires that small integers (-128 to 127) always box to the same wrapper object. Implementations are encouraged, but not requied, to do the same for larger values as well.</font>
If he is correct, then the actual range is implementation-specific (must be at least between -128 and 127, could be larger.) In that case, the only thing you can really do is try and see if larger ranges work for a given implementation, or read the implementation documention (not the language spec). Of course, I'm guessing most non-embedded developers are probably using Sun Java.
Obviously, the correct thing to do would be to always assume the range is between -128 and 127, even if other implementations are "encouraged" to do more.
I can see why autoboxing is useful for reading and writing concise code, but I agree this detail is a bit of a WTF.
-
@MasterPlanSoftware said:
Again my Java knowledge is very rusty, but I think collections such as vectors and maps in Java always wrap Objects, not primitives. So if you wanted a collection (not primitive array) of integer values, you would have to use Integer. I think the whole point of the autoboxing feature was to make that code of code easier to read and write.@Physics Phil said:
TRWTF is that the programmer didn't declare them as int
Right. There are very few instances I can think of at the moment that require you to use an Integer and not just an int.
Anyway, IMO, just because you are not "required" to use Integer in all cases doesn not mean that the language features should not act sanely when you decide to use Integer. It is almost like saying it doesn't matter whether Sun adds a broken feature to their language, as long as they don't force you to use it. And that feature can very easily be used implicitly. (You don't even have to know what autoboxing is to take advantage of autoboxing).
-
@CodeSimian said:
<font color="#000000" size="2">
The reason is that the autoboxing spec requires that small integers (-128 to 127) always box to the same wrapper object. Implementations are encouraged, but not requied, to do the same for larger values as well.</font>
If he is correct, then the actual range is implementation-specific (must be at least between -128 and 127, could be larger.) In that case, the only thing you can really do is try and see if larger ranges work for a given implementation, or read the implementation documention (not the language spec). Of course, I'm guessing most non-embedded developers are probably using Sun Java.
Obviously, the correct thing to do would be to always assume the range is between -128 and 127, even if other implementations are "encouraged" to do more.
I can see why autoboxing is useful for reading and writing concise code, but I agree this detail is a bit of a WTF.
This was posted against the beta version, I'm not sure of any spec that gives a minimum range of automatic caching. The simple solution is, don't use == on non-primative values.
Correct versions of the code would be:
return a.equals(b);
or
return (int) a == (int)b;
But... if you had Integer values and wanted to see if one is less than the other, using < is the simplist way of doing so. I could very easily see a programmer needing to tweak code and changing < to ==, testing the code and see it works for some small values, and fails to realize it doesn't work for larger ones.
-
@CodeSimian said:
I think the whole point of the autoboxing feature was to make that code of code easier to read and write.
As well as introducing reliance on the voodoo magic created by the priestess who was responsible for the particular JVM it's running on.
-
@CodeSimian said:
to use Integer in all cases doesn not mean that the language features should not act sanely when you decide to use Integer.
When you understand how the primitives work and how the wrappers work it WILL make sense.
Anyone who would use == on a wrapper like Integer doesn't know what they are doing. I agree it would be nice to have a noob warning, but everything is working as expected/documented.
-
@subanark said:
This was posted against the beta version, I'm not sure of any spec that gives a minimum range of automatic caching. The simple solution is, don't use == on non-primative values.
@subanark said:But... if you had Integer values and wanted to see if one is less than the other, using < is the simplist way of doing so. I could very easily see a programmer needing to tweak code and changing < to ==, testing the code and see it works for some small values, and fails to realize it doesn't work for larger ones.
Yeah, that's why autoboxing's unexpected behaviour seems like an easy trap to fall into, since you can implicitly switch from object reference comparison (==) to unboxed primitive comparison (<) or vice-versa, without having any knowledge of autoboxing. And of course, the whole "caching of small values from -128 to 127" thing doesn't help matters.
Obviously the problem is, like you said, backwards compatibility had to be maintained, so they had to treat ==, != differently from <, >, etc.
-
@MasterPlanSoftware said:
Perhaps, but several people in this thread (including myself) with a passing knowledge of Java did not seem to know about autoboxing or the special behaviour for small integers between -128 to 127. Call me crazy, but I think it kind of proves my point. I knew about object reference comparison, but not autoboxing, so coming from my Java 1.4 background I assumed the following code would return false:When you understand how the primitives work and how the wrappers work it WILL make sense.
Anyone who would use == on a wrapper like Integer doesn't know what they are doing. I agree it would be nice to have a noob warning, but everything is working as expected/documented.
Integer a = 127;
Integer b = 127;
return a == b;
You have to get down to the nitty-gritty to understand why it returns true for 127 and false for 128. And also to understand why < ALWAYS works (due to autoboxing), but == and != don't.
-
@CodeSimian said:
but == and != don't.
Again. When using a wrapper class for a primitive, this should be obvious.
The behavior is inconsequential, because it should not be used. The wrapper has a method specifically for this purpose.
-
I like box.
-
-
@MasterPlanSoftware said:
@Digitalbath said:
I like box.
AbbydonKrafts like fox.
Whats your point?
No point. Since everything seemed cleared up and with all the talk of (auto)box(ing), I just felt like jumping in with a sex joke. Perhaps I should have linked the first time. Or said something funnier, like I prefer box over autoboxing?
-
@Digitalbath said:
Perhaps I should have linked the first time.
I got the joke. It wasn't all that funny on it's own. Decided to help you out by adding on to it and insulting AbbydonKrafts odd furry obsession.
Of course now that you have decided to explain it, it is even LESS funny.
-
I'm having trouble understanding how this is "Classic." It's only an issue with newer Java versions, and is not really well known.
Anyways,
-
@MasterPlanSoftware said:
Okay, do you think <, >,<=, and >= should ever be used to compare objects (with autoboxing)? The language was specifically revised to allow for this case. If != and == are bad for objects (unless you want to compare-by-reference), why are the other operators good?@CodeSimian said:
but == and != don't.
Again. When using a wrapper class for a primitive, this should be obvious.
The behavior is inconsequential, because it should not be used. The wrapper has a method specifically for this purpose.
I guess we'll have to agree to disagree. You seem to have backpedelled slightly, though. First you said there are very few reasons to use the Integer object wrapper instead of the int primitive. Off the top of my head, I mentioned the use of collections, which IIRC are an important part of Java. Now you are saying that when a wrapper is used, the behaviour should be "obvious". I don't think the following rules are obvious:
- If you use a relational operator that didn't work with objects in Java 1.4 or earlier (<, >, <=, >=) then the value will be auto[un]boxed.
- Otherwise, the standard comparison-by-reference semantics apply.
- Oh, and objects whose value is between -128 and 127 will be cached, so comparison-by-reference will appear to be just like comparison-by-value
Personally I would expect all the relational operators to behave the same way, with regards to implicit conversion (autoboxing): =, !=, <, >, <=, >=. They don't, and I can see good reasons for it (e.g. backwards compatibility, the need to compare actual references for [in]equality), but I still don't like it.
I agree that anyone who does serious programming in Java will need to learn this. However, maybe it would've been better not to add a language feature (autoboxing) that could serve to confuse newcomers.
-
@MasterPlanSoftware said:
I got the joke. It wasn't all that funny on it's own. Decided to help you out by adding on to it and insulting AbbydonKrafts odd furry obsession.
Ah, thanks, I suppose. I was unaware of the fox obsession. I know I didn't have anything useful to say, but it's a slow work day, and I'm bored. Actually, you're probably a little dumber for reading this. You're welcome.
-
-
@MasterPlanSoftware said:
Filed under: Behavior is expected and documented.
Behavior is also stupid and counter-intuitive.
-
@MasterPlanSoftware said:
Filed under: Behavior is expected and documented.
Behaviour is documented, but it may not be expected, nor is it necessarily intuitive. This is the same reason that many people frown on operator overloading in C++. There's a reason operator overloading was not implemented in Java: AFAIK, it was because they didn't want to confuse people. So why add the confusing "autoboxing" feature, which makes implicit (object-to-primitive conversion) what used to be explicit? Following your argument, the relationship between objects and primitives is a basic part of the language, so why not make the programmer do explicit conversion? Just for the sake of readability?
-
@CodeSimian said:
Okay, do you think <, >,<=, and >= should ever be used to compare objects (with autoboxing)?
Not really, but they are available and documented as such.
@CodeSimian said:
If != and == are bad for objects (unless you want to compare-by-reference), why are the other operators good?
Because != and == don't work. They simply don't. No amount of whining will change that.
@CodeSimian said:
First you said there are very few reasons to use the Integer object wrapper instead of the int primitive.
I don't use Java, but I use C# extensively which shares some of the problems. I don't have this issue in C# because I have never needed to USE the Integer class. If java requires that, then that sucks for you.
@CodeSimian said:
the behaviour should be "obvious"
Yes. I think any person of reasonable intelligence would see the Equal method and think "Hmmm I better find out WTF that is for!". If they don't then oh well. We will see their code on the frontpage later I guess.@CodeSimian said:
However, maybe it would've been better not to add a language feature (autoboxing) that could serve to confuse newcomers.
I agree. We should also remove pointers from C. Too much confusion there as well.
-
@bstorer said:
Behavior is also stupid and counter-intuitive.
But it's well-documented! By the same token, once you write documentation for SSDS.NET, anyone should be able to use it! Only noobs complain about things they don't understand....
-
@MasterPlanSoftware said:
@CodeSimian said:
to use Integer in all cases doesn not mean that the language features should not act sanely when you decide to use Integer.
When you understand how the primitives work and how the wrappers work it WILL make sense.
Anyone who would use == on a wrapper like Integer doesn't know what they are doing. I agree it would be nice to have a noob warning, but everything is working as expected/documented.
[java] compiling test.java
[java] error line 15: RTFM N00|3!
In any case, is this thread about the OP not knowing how primitive wrappers work? If thats the case I suggest we close this thread.
-
@MasterPlanSoftware said:
For instance, this same thing *should* occur in C#.
<hints id="hah_hints"></hints>Given that "int" is just an alias for the Int32 class in C#, I'm inclined to disagree. Since there are no true "primitives", you'd have to use the stupid object.Equals method for every comparison, and if you actually believe that makes sense, then you truly have drunk the kool-aid.
In almost every instance where there is an equality comparer, the programmer is going to want to use that equality comparer and not perform a reference test. Testing for equality at the reference level is the exception, not the rule, which is why C# provides a special "ReferenceEquals" method for the very odd time when one might actually want to do such a silly thing. I don't think I've ever used it; unless you're interfacing with unmanaged/unsafe code, there's no point.
-
@MasterPlanSoftware said:
@CodeSimian said:
Strangely enough, Java doesn't implement pointers either. I wonder why. If the goal of Java is simplicity and ease of learning, autoboxing is a step in the wrong direction. If I want operator overloading and pointers, I'll use C++.However, maybe it would've been better not to add a language feature (autoboxing) that could serve to confuse newcomers.
I agree. We should also remove pointers from C. Too much confusion there as well.
-
@CodeSimian said:
If the goal of Java is simplicity and ease of learning,
This is most decidedly not the goal of Java.
-
@Aaron said:
Given that "int" is just an alias for the Int32 class in C#
In C# there is an Integer class.
Int32 is an alias, Integer is a wrapper.
-
@dlikhten said:
Did you read the thread? The thread is about autoboxing (implicit conversion between primitives and objects) and caching of Integer objects for values between -128 and 127.[java] compiling test.java
[java] error line 15: RTFM N00|3!
In any case, is this thread about the OP not knowing how primitive wrappers work? If thats the case I suggest we close this thread.
What version of the JDK are you compiling under? Autoboxing was added in Java 1.5.
-
@bstorer said:
@CodeSimian said:
Fair enough. But I believe the goal of deciding not to implement several C++ idioms from Java, such as pointers, operator overloading and multiple inheritance was simplicity - I think the goal was to make it harder to shoot yourself in the foot. I could be wrong (which is usually the case).If the goal of Java is simplicity and ease of learning,
This is most decidedly not the goal of Java.
-
@CodeSimian said:
So why add the confusing "autoboxing" feature, which makes implicit (object-to-primitive conversion) what used to be explicit?
This is actually a good point. One of the things I like about java is that you have to spell everything out.<completely_wild_speculation>
I guess Sun's seeing a backlash from other languages (Ruby) that developers are really starting to get into and which require a lot less code to do the same things as Java does, and they wanted to start reducing the amount of code Java developers have to write. They chose the wrong way to do it, though
</completely_wild_speculation>
-
-
@MasterPlanSoftware said:
Do you have a problem with what I wrote? I made a very poor choice of words - "implement" - but I think you know exactly what I meant.@CodeSimian said:
Java doesn't implement pointers either. I wonder why.
Wow. Just wow.
From a SEMANTIC point of view, a reference to an object is not the same as a C-style pointer to an object. The semantics of references are far more restrictive than pointers. You cannot do pointer arithmetic, you cannot point to arbitrary memory, etc.
Do you really not understand the SEMANTIC (not the underlying nuts-and-bolts implementation) difference between references and pointers.
Again, sorry I chose the wrong word ("implement").
<font color="#ff0000" size="7">2.2.9 No More Pointers</font>
Most studies agree that pointers are one of the primary features that enable programmers to inject bugs into their code. Given that structures are gone, and arrays and strings are objects, the need for pointers to these constructs goes away. Thus, Java has no pointer data types. Any task that would require arrays, structures, and pointers in C can be more easily and reliably performed by declaring objects and arrays of objects. Instead of complex pointer manipulation on array pointers, you access arrays by their arithmetic indices. The Java run-time system checks all array indexing to ensure indices are within the bounds of the array.
You no longer have dangling pointers and trashing of memory because of incorrect pointers, because there are no pointers in Java.
-
@CodeSimian said:
Fair enough. But I believe the goal of removing several C++ idioms from Java, such as pointers, operator overloading and multiple inheritance was simplicity - I think the goal was to make it harder to shoot yourself in the foot. I could be wrong (which is usually the case).
Java's funny, because it's really a programming language, a platform, and a brand. Figuring out what the hell anyone was really intending with the language is a matter of digging through a lot of marketing shit to find the (corn) kernels of truth.
With that in mind, I don't really think Java was intended to be a "simple" programming language, it was just marketed that way. I do believe that the designers used C++, as an extremely popular "object-oriented" language, and studied what they thought worked and didn't work. They recognized that some things were "bad" in C++ (e.g., operator overloading), and other things -- like pointers -- really just didn't fit their paradigm.
-
@CodeSimian said:
@dlikhten said:
Did you read the thread? The thread is about autoboxing (implicit conversion between primitives and objects) and caching of Integer objects for values between -128 and 127.[java] compiling test.java
[java] error line 15: RTFM N00|3!
In any case, is this thread about the OP not knowing how primitive wrappers work? If thats the case I suggest we close this thread.
What version of the JDK are you compiling under? Autoboxing was added in Java 1.5.
Well the caching is fine if they found that most people use those frequently... Usually for a few flags here and there, some minor arithmetics. Let java do it, why not.
The point of autoboxing is -- reduce USELESS code (already mentioned). Often you just wrap objects just to put them in a hashmap or arraylist, so let the language do it for us. Let java implement it however the hell it wants to. Its a 1.5 feature so anyone trying to compile it in 1.4 would fail miserably.
The other point is, Sun is capitolizing on Java, they don't want to abandon it for langs like python, RUBY, or erlang, but they noticed that developers really like ruby and python caz they don't have to do so much typing, and thus less potential for problems.As bstorer pointed out, Java just simplified pointers and made C++ a platform-independent language. Java is easier to read and maintain than C++ specially x-platform. If you want something completely different try Ruby. Ruby just does not have Sun to back them.
In any case, why does anyone care if java caches integer objects? I am just curious why we should care. Is it causing problems? Is 1 sometimes 3 but often 5?
Boxing (computer science) - Wikipedia
Oracle Java Technologies | Oracle
