4 ms·

While one problem the blog post describes is valid, I think the authors comes to the wrong conclusion. The problem is that the method is implemented in such a w

While one problem the blog post describes is valid, I think the authors comes to the wrong conclusion. The problem is that the method is implemented in such a way that it uses Integer objects which are different from the native integer types. Objects have very clear semantics concerning the == operator. It checks whether the object identity is the same (alas it is the same object). There is nothing special about it, thats also the reason why you can't compare two strings with == and this is s.th. I think every Java developer learns within the first days/weeks (often by first doing it wrong, I don't claim that this is intuitive). So in this light the correct solution, which the author even does not mention anymore in the end, would be for the method to use the a.equals(b). Everything would work. The point of the author that a team should agree on using either one or the other is nonesene, because in some situations there is no choice (e.g. HashMaps only work with objects). Also there is no real problem, because whoever implemented the method know what he gets and should have implemented it using the equals method. So in reality this should not be fixed with creating seperate Integer instances but with fixing the method itself. As a last comment, there is one pitfall to watch out for with autoboxing. When you use the "int" type in your code and call a method which returns an "Integer" and you compare with == you can get wrong results. I think of this as a real problem, because often you know that a method will return a number but you don't expect it to be returned as Integer. Or even worse between versions of the api the method is changed from returning int to Integer and you don't even notice because it compiles. But I think this happens very rarely and personally I always return numbers as native types. PS: But I can understand that it is sometimes confusing that the code is working in some cases and not working in others, when it should never work! If you want to get a really good understanding of the semantics of the Java language I would advise to read ( http://java.sun.com/docs/books/effective/ http://java.sun.com/docs/books/effective/ )

powatom 15y ago
The author ( me :P ) mentions that using a.equals(b) is the correct solution right at the beginning of the post. Unfortunately this problem will continue to occur as long as autoboxing exists, so I think it's a valid idea to simply enforce a rule across your team that says 'Here's how we're going to avoid autoboxing problems'. I intended this post to be more of an illustration of what autoboxing does. With regards to your comment that the solution is not to create separate integer instances - I was attempting to show that this is a possible solution to autoboxing headaches rather than 'the correct' solution for testing integer equality, because the objects are not cached. Sometimes you want to use == for valid reasons, the problem I had was because I wasn't vigilant enough in checking my own code and used == when I shouldn't have used it in the first place. Perhaps this post could have been written more clearly - but as it happens, you're spot on. The examples at the end of the post were intended to be potential solutions to autoboxing headaches in general, rather than a solution for my specific problem :)
- mkaufmann 15y ago
  Ok, in that regard I think your post was very informative. Raising awareness of this language detail is very important, because it can lead to bugs which are very hard to detect. The two most valuable advices from your post is directly the first line (but I have to admit that I overread it the first time I looked at the post). And second to use some tooling like the Eclipse code checker or findbugs (which was mentioned in another comment) to make implicit conversions visible to the programmer. The only point I still disagree, though this is only a minor point, is that even with your explanation the possible solution of creating seperate instances is really no help. My point beeing that either you know that autoboxing occurs at a point and one can handle it correctly, or one doesn't know and in that case you also can't create seperate integer instances. This is from the point of view of someone who worked most of his career with Java and that line just makes my eyes bleed. But I can also understand if this looks like nitpicking to others ;)

powatom 15y ago

The author ( me :P ) mentions that using a.equals(b) is the correct solution right at the beginning of the post. Unfortunately this problem will continue to occur as long as autoboxing exists, so I think it's a valid idea to simply enforce a rule across your team that says 'Here's how we're going to avoid autoboxing problems'. I intended this post to be more of an illustration of what autoboxing does. With regards to your comment that the solution is not to create separate integer instances - I was attempting to show that this is a possible solution to autoboxing headaches rather than 'the correct' solution for testing integer equality, because the objects are not cached. Sometimes you want to use == for valid reasons, the problem I had was because I wasn't vigilant enough in checking my own code and used == when I shouldn't have used it in the first place. Perhaps this post could have been written more clearly - but as it happens, you're spot on. The examples at the end of the post were intended to be potential solutions to autoboxing headaches in general, rather than a solution for my specific problem :)

mkaufmann 15y ago
Ok, in that regard I think your post was very informative. Raising awareness of this language detail is very important, because it can lead to bugs which are very hard to detect. The two most valuable advices from your post is directly the first line (but I have to admit that I overread it the first time I looked at the post). And second to use some tooling like the Eclipse code checker or findbugs (which was mentioned in another comment) to make implicit conversions visible to the programmer. The only point I still disagree, though this is only a minor point, is that even with your explanation the possible solution of creating seperate instances is really no help. My point beeing that either you know that autoboxing occurs at a point and one can handle it correctly, or one doesn't know and in that case you also can't create seperate integer instances. This is from the point of view of someone who worked most of his career with Java and that line just makes my eyes bleed. But I can also understand if this looks like nitpicking to others ;)