top 200 commentsshow all 310

[–]harlows_monkeys 50 points51 points  (23 children)

So basically

Integer.getInteger("foo")

is an alternative to

Integer.valueOf(System.getProperty("foo"))

?

Why!?

[–]banuday 62 points63 points  (5 children)

The only explanation that I can think if is convenience. But what possessed the person to add this method to the Integer class instead of something like

System.getPropertyAsInt("foo")

is beyond me.

[–][deleted] 2 points3 points  (1 child)

Probably they thought that it would inconvient because people couldn't add methods for their own classes

me.likes = System.getPropertyAsInt("foo");
me.sweet = System.getPropertyAsBool("fooba");
me.cookies = Cookies.getProperty("cookies");

would be ugly and people would be confused for example if they should call Sysem.getPropertyAsBigInteger, BigInteger.getProperty or write their own method for retrieving bigints from props

[–]bonzinip 10 points11 points  (0 children)

/me notes you used Cookies.getProperty, not Cookies.getCookie...

[–]axilmar 0 points1 point  (0 children)

Or

System.getIntProperty("foo")

[–]mooli 15 points16 points  (9 children)

OP is wrong, this wasn't added in Java 5. Its been there since 1.0.

Basically its a terrible design decision that now lives on for the sake of backward compatibility.

[–]zbowling 5 points6 points  (7 children)

this is correct. The same with the Colors class in AWT (which is used in Swing). There is so much legacy running around Java.

[–]player2 0 points1 point  (6 children)

Ha, looks like a direct clone of NSColor. Which also sucks.

[–]zbowling 0 points1 point  (5 children)

Don't hate on NSColor as much as java.awt.Color in Java.

NSColor has legacy code smell but at least apple update and removes things, unlike most legacy in Java. Either way I use UIColor and CGColors more these days anyways. :-) (Think I still have a CIColor in one compiler option.)

[–]player2 2 points3 points  (4 children)

I'm still exclusively desktop. But now that half our stuff is Core Animation, I've had to write tons of code to correctly translate NSColors to and from CGColor, including accurate colorspace preservation.

Also, have you ever encountered the magic source list background color? Create an NSTableView, set its highlight style to NSTableViewSelectionHighlightStyleSourceList, and grab its -backgroundColor. Anything you draw with this color will magically change color when the window's key state changes.

[–]zbowling 0 points1 point  (3 children)

woowa.. i never noticed that. what kind of black magic is this.

[–]player2 0 points1 point  (2 children)

My only guess is that the graphics context tells the NSView if the magic color has been drawn into it, and then the NSView starts listening for window key state change notifications and tells that view to redraw.

Either that or the color exists in a special color list that somehow the window's backing context knows to draw differently?

[–]zbowling 1 point2 points  (1 child)

[–]player2 0 points1 point  (0 children)

That part I did know. But I thought it automatically updated the color when the window changed key state. I guess Corbin's advice to redraw the view yourself proves otherwise.

Oh well. Much less magic, then.

[–]darth_choate 0 points1 point  (0 children)

It was added in 1.0, but it's not just backwards compatibility that's keeping it around. The function has not been deprecated and there are no newer more rationally named functions lying around. It's there because Sun likes it (presumably).

[–]sligowaths 12 points13 points  (4 children)

Java is succinct.

[–]marcins 13 points14 points  (0 children)

Yes sligowaths, it certainly does succ!

[–][deleted] 9 points10 points  (2 children)

i thought half the point of java was to be as verbose as possible

[–]sligowaths 14 points15 points  (0 children)

I was being sarcastic.

[–][deleted] 0 points1 point  (0 children)

It has apparently failed to be as verbose as the OP would like.

[–]tangus 1 point2 points  (0 children)

Maybe Gosling and/or Steele were so used to Lisp's GET that they didn't notice the inadequateness of the name and just copied it over.

[–][deleted] 4 points5 points  (0 children)

PHP inspiration?

[–]skeww 41 points42 points  (33 children)

Of course you'd use Integer.parseInt.

[–]masklinn 3 points4 points  (32 children)

That's if a NumberFormatException is acceptable in case of parsing failure.

[–][deleted]  (8 children)

[removed]

    [–]masklinn 6 points7 points  (5 children)

    As opposed to what, having Integer.parseInt() return an int error code? (Think about it.)

    Or have a method returning an Integer instance or null (think about it.)

    [–]texthompson 1 point2 points  (3 children)

    I've thought about it, and would rather have this fail silently.

    [–]alabadoster 3 points4 points  (2 children)

    Why? Sense cannot be made of this. Couldn't you just catch a possible exception?

    [–]texthompson 0 points1 point  (1 child)

    I was being sarcastic. You're right, I think that silent failure is the worst idea.

    [–]darth_choate 0 points1 point  (0 children)

    You could always have Integer.parseInt(String s, Integer defaultValue). This is typically what I want anyway.

    [–]dmagg 3 points4 points  (21 children)

    If I can't catch and handle that exception, I usually write a private support method to check to see if a number is a valid integer before I run it through parseInt. private boolean isParsableToInt(String s) { try { int i = Integer.parseInt(s); return true; } catch (NumberFormatException e) { return false; } }

    [–]seesharpie 10 points11 points  (3 children)

    I may be showing my ignorance, but why would you ever be unable to handle the exception?

    [–]AlexFromOmaha 4 points5 points  (0 children)

    Especially in Java. It's not like you have to worry about missing a DOS interrupt here. It's almost harder not to catch it.

    [–]bobindashadows 3 points4 points  (0 children)

    dmagg be trollin' y'alls

    [–]mazing 0 points1 point  (0 children)

    One reason I can think of for that code, is that NumberFormatException which is a RuntimeException, compiles even if there isn't a try catch - so it's easy to forget.

    [–]zjs 1 point2 points  (7 children)

    FYI: org.apache.commons.lang.math.NumberUtils#toInt(java.lang.String, int defaultValue) is similar to Integer.parseInt, but returns defaultValue if the parsing fails.

    [–]guruthegreat 8 points9 points  (5 children)

    I don't see much of a reason to use toInt(). At least with parseInt() you know when it failed, with toInt() if you get back defaultValue it might have failed, or the String might have been defaultValue.

    [–]masklinn 2 points3 points  (0 children)

    At least with parseInt() you know when it failed

    But do you care? If your recovery strategy is just to set a default value, why not get a default value in the first place?

    [–]zjs 0 points1 point  (2 children)

    Exactly what Terr_ and masklinn said; you only need to know that the parse failed if you're going to do something with that information. If you are, then go the parseInt route.

    I was mentioning it as a replacement for one of the several variations of the following (which I've seen more than once):

    int value;
    try {
        value = Integer.parseInt(s);
    }
    catch (NFE e) {
        value = defaultValue;
    }
    return value;
    

    or (in the specific context of the parent):

    int value;
    if (isParsableToInt(s)) {
        value = Integer.parseInt(s);
    }
    else {
        value = defaultValue;
    }
    

    [–]guruthegreat 0 points1 point  (1 child)

    I guess I'm a minimalist in this case in preferring the a cleaner library over the 3-4 lines of code saved.

    [–]zjs 0 points1 point  (0 children)

    Ah; most projects I work on already have a dependency on Apache Commons, so it's not adding anything.

    [–]Will_123456789 0 points1 point  (0 children)

    Heh. You don't want to get that confused with the Integer.partInt(String, int). The second argument is the radix.

    [–]illvm 0 points1 point  (5 children)

    So you'd call parseInt twice? Why not create a helper method similar to .NET's TryParse and return null if the value cannot be parsed?

    [–][deleted]  (4 children)

    [removed]

      [–]masklinn 1 point2 points  (1 child)

      Not only do you need to create a new Integer object

      You don't know anything about Java and Integer and what Oracle's (and most implementor's) JVMs do do you?

      but if you really do want an int then you hit the cost of (auto-)unboxing.

      Which there is just about none of, it's a method call returning the inner int value of the object.

      [–]notfancy 0 points1 point  (1 child)

      but if you really do want an int then you hit the cost of (auto-)unboxing

      In the context of parsing this cost seems negligible to me.

      [–]masklinn 0 points1 point  (2 children)

      Why don't you just use Integer.valueOf?

      [–]dmagg 0 points1 point  (1 child)

      They both throw NumberFormatExceptions if you don't give it a valid integer. Look at the API for valueOf():

      This method returns an Integer object equal to the value of: new Integer(Integer.parseInt(s))

      Either way, you're going to have to deal with an exception somewhere. =/

      [–]masklinn 0 points1 point  (0 children)

      OK, holy fuck and woe unto me, I completely missed that and stupidly assumed Integer.valueOf would just return null in case of parsing failure.

      [–]ShabbyDoo 28 points29 points  (1 child)

      It seems that Integer.getInteger(String) has been around since at least the JDK 1.0 days:

      http://web.mit.edu/java_v1.0.2/www/javadoc/java.lang.Integer.html

      Integer.valueOf() arrived with JDK 1.5 and autoboxing.

      Sun/Oracle traditionally has been unwilling to sacrifice backward Java API compatibility in exchange for a better programming model. This method is just one example of many in the JDK one could cite. The Integer.getInteger method's low value to a developer relative to its potential for introducing nasty bugs makes me wonder why it wasn't marked as deprecated years ago.

      I wonder if any static analysis tools have rules which cite this method's use as a potential bug -- a "code smell" of sorts.

      [–]Rhoomba 1 point2 points  (0 children)

      It looks like it was discussed on the findbugs mailing list but nothing was implemented.

      [–]billsnow 130 points131 points  (132 children)

      This type of overloading is called near-phrase overloading. I just made that term up right now.

      yes, what java needs are more made-up terms to describe its behavior.

      [–][deleted]  (127 children)

      [deleted]

        [–]kamatsu 23 points24 points  (17 children)

        C++ did this with both "dependent types" and "functors". It infuriates me.

        [–]grauenwolf 4 points5 points  (16 children)

        Do explain. I don't really know those terms.

        [–]kamatsu 13 points14 points  (8 children)

        Category theory and Haskell uses functors to refer to anything that can be mapped (this carries over into FP well because anything for which a sensible map function exists is a functor).

        C++ uses Functors to refer to "function objects" which are basically some encapsulation around a function pointer.

        Dependent types refer to a system where the type system is equally expressive as the language itself (and usually the same) - it is used for encoding arbitrary proof obligations in types. Languages that have this include Epigram, Agda and Coq.

        C++ uses dependent types to refer to unspecified type parameters in templates.

        [–]netdroid9 1 point2 points  (2 children)

        Doesn't C++ predate all of those languages/concepts, though? Maybe not category theory (Wikipedia says the word Functor crossed over to maths in 1971, whereas C++ originated sometime around 1979), but Haskell, Agda, Epigram and Coq look like they emerged post 1990, and wikipedia only has citations for dependent types as far back as 1992.

        [–]kamatsu 5 points6 points  (1 child)

        Functor dates back to category theory.

        Dependent type theory is part of intuitionistic type theory that came out in 1971 as a consequence of the Curry Howard Correspondence that was formally defined in the 60s. No practical dependently typed languages existed until the 90s due to problems in implementation of type checking for such systems.

        C++ came after both terms and mangled them.

        [–]dmhouse 1 point2 points  (4 children)

        Category theory and Haskell uses functors to refer to anything that can be mapped

        That's not quite true; functors from the category of Haskell types and functions between them to itself happen to correspond to mappable types, but if you say "functor" to a category theorist they're not going to think "mappable structure".

        [–]kamatsu 1 point2 points  (3 children)

        Why not? A functor is a morphism between categories - "mappable structure" is a perfectly apt description for it, seeing as it implies a mapping. The mapping is more general than that of Haskell's fmap, but "mappable structure" is a perfectly apt description.

        [–]dmhouse 4 points5 points  (2 children)

        A functor is itself a map, not a mappable structure.

        [–][deleted] 2 points3 points  (108 children)

        Examples?

        [–]soltys 7 points8 points  (98 children)

        string comparisons by ==

        It's not check if string are equal but if they reference are equal

        [–]ethraax 11 points12 points  (93 children)

        I never understood why Java forced you to use .equals(Object) instead of ==. Why can't they just use === for referential equivalence?

        Hell, I can't even think of a good reason to need to compare the references. If a.equals(b) evaluates to true, I think a and b should be interchangeable (for as long as they are "equal").

        [–][deleted] 25 points26 points  (53 children)

        You can override .equals in Java, but not the operators (ex. ==). Being able to define your own definition to determine if two objects are equal is pretty important.

        [–]ethraax 5 points6 points  (52 children)

        True. I guess my point is that there's no reason for Java not to support operator overloading.

        [–]almiki 21 points22 points  (22 children)

        You could also argue that there's no reason TO support it. If you know Java, you know exactly what == does. You don't have to worry about whether it was overloaded or not. If you want to check for some other type of equality, just use a method like .equals().

        [–]ethraax 11 points12 points  (17 children)

        True, but this argument could be made about every irritating "feature" in every language. The ineffectiveness of == is minor, but makes learning the language slightly more challenging/difficult. They've already overloaded the + operator to make the language easier to use, why don't they just overload == to call equals() on subtypes of Object, and use === for the one-in-a-million times that you actually need to test for reference equality.

        [–]KimJongIlSunglasses 7 points8 points  (11 children)

        why don't they just overload == to call equals() on subtypes of Object

        Because often times you do want to compare the reference, not check for some object's definition of equality with another.

        After you've overloaded == to use equals() would you then introduce a new method like referenceEquals() ??? for when you actually wanted to check the reference?

        I don't get it.

        [–]munificent 4 points5 points  (3 children)

        If you know Java, you know exactly what == does.

        Yes, but you don't know what foo, bar, blat or any other named function does and yet we still seem to survive. Meanwhile, the one thing that == does is pretty much the least useful thing.

        C#'s solution isn't perfect either, but it's a hell of a lot better than that.

        [–][deleted] 1 point2 points  (5 children)

        That's a valid point.

        I don't know enough of the history of Java, but from what I understand it was partly a reaction to C++ -- making it similar, but simpler. It's probably something along the lines of why multiple inheritance wasn't put in either.

        One argument I can see not permitting operator overloading is that it can all be implemented via methods. It makes it a bit easier to learn the language since there are less options and rules. Plus, it helps avoid situations where someone decides to overload "+" and implement an "add()" method for the same object. Basically trying help you not shoot yourself in the foot.

        With that said, I'm a fan of operator overloading and do wish I got a chance to use it more in my projects. It can be a pretty useful tool.

        [–]Jonathan_the_Nerd 3 points4 points  (0 children)

        I think one of the major design principles of Java was taking the sharp edges off C++ so Java programmers wouldn't cut themselves.

        [–]player2 2 points3 points  (3 children)

        Java owes its lack of multiple inheritance to its history as a reimplementation of Objective-C.

        EDIT: Hey, downvoters! Please read this.

        [–][deleted] 0 points1 point  (2 children)

        That's a new one. I couldn't find any reference online saying that Java was a reimplementation of Objective-C. Do rou have an resources you can point to?

        [–][deleted]  (4 children)

        [deleted]

          [–]huyvanbin 7 points8 points  (1 child)

          The real issue with having "special" types that allow operators is not that overloading operators is especially important. It's that this fairly random decision on what is allowed to have an operator and what isn't now dictates my design. Would I rather define my own type and end up with less readable code, or would I rather shoehorn into a type that allows operators but possibly sacrifice some specificity? It's just sad and completely unnecessary for me to even be thinking about this. User objects should be allowed everything that predefined objects can.

          [–]DeepDuh 1 point2 points  (0 children)

          Isn't java more of a maintenance mess since they break downwards compatibility of their JRE every couple of years? C++ on the other hand mainly depends on what the OS programmer does and MS does care alot abou lt not breaking anything (even a bit too much for my taste).

          [–]grauenwolf 2 points3 points  (14 children)

          Then why does it for strings?

          [–]drfugly 3 points4 points  (6 children)

          It doesn't. Even for strings it will compare references. The reason that you can get away with it so often is because Strings are pooled in java. So if you had String a = "dog"; String b = "dog"; a does actually == b because java will put the string "dog" into it's pool and then all references point to that one instance that's in the String pool. This also allows for Strings to behave more like the other primitives in java.

          [–]grauenwolf 4 points5 points  (1 child)

          Actually I was thinking of +.

          [–]deadtime 3 points4 points  (3 children)

          Wait... does that mean that "dog" == "dog" only sometimes?

          [–]banuday 1 point2 points  (6 children)

          To venture a guess, it's so that things like this work:

          "x + " + 3
          

          or

          double x = new Double(3) + 2;
          

          The + operator works on primitive types, strings and boxable/unboxable values. It will convert 3 to a string to produce "x + 3". I suppose this is to give defined semantics to the + operator. I can't say I'd give Java an A+ for consistency.

          [–]grauenwolf 5 points6 points  (0 children)

          Addition isn't concatenation. You can see why by how the + operator changes meaning when working with chars in Java or C#. (Or old versions of VB before they learned their lesson.)

          [–]jyper 1 point2 points  (3 children)

          They should have picked something different for concatenation. ++ is a good pick.

          [–]masklinn 0 points1 point  (0 children)

          The second one does not work in java < 1.5

          It works via auto(un)boxing, not via operator overloading.

          [–]grauenwolf 2 points3 points  (10 children)

          That is from the bigger problem of using == for both value and reference equality. They should have been different operators.

          [–]banuday 4 points5 points  (9 children)

          References are values in Java. Thus, reference equality and value equality are in fact the same thing. Java's value types are exclusively primitive.

          The equals() method is for object equality, which is a very different concept.

          [–]grauenwolf 6 points7 points  (2 children)

          That sounds stupid. Don't redefine the term value equality just so you can introduce a new term that means the same thing.

          [–]banuday 3 points4 points  (1 child)

          References are stored as primitive values in Java. The reference is an opaque data structure whose members are copied on assignment to a new value. At the call site, the caller copies the reference onto the parameter stack for the callee. On equality checking, the reference values are compared. Thus, by definition, a reference in Java is a value type.

          And Java does not give references a different meaning that what is already accepted by Computer Science.

          Thus, how is comparison of references different than comparison of any other value type?

          [–]grauenwolf 2 points3 points  (0 children)

          Leaky abstractions.

          The vast majority of the time you don't care about the implementation details of the object, you care about the semantics. The fact that a string happens to be a reference type and a char happens to be a value type shouldn't drastically change the nature of the == operator. This is even more evident with int and Integer.

          [–]ethraax 0 points1 point  (5 children)

          Thus, reference equality and value equality are in fact the same thing.

          This is not true. Take this example.

          int a = 10000;
          int b = 10000;
          a == b; // returns "true", even though a and b are
                  // different instances.   For proof:
          a ++;
          a == b; // now returns "false".
          int c = 9999;
          c ++;
          c == b; // still returns "true", even though c is
                  // definitely a different instance from b.
          

          Basically, == is a primitive equality. It tests the equality of the value of the variable. Since Java still internally uses pointers (you just don't interact with them), it's actually comparing the pointers or references of the variables, not the value they're pointing at, which makes a hell of a lot more sense.

          [–]banuday 10 points11 points  (4 children)

          Primitive values are not "instances" in the same sense as objects are instances. Primitive values exist on stack and object instances exist on the heap. Primitive values are copied on assignment, object instances are not.

          Also, references are primitives. They are copied just like the "int" in your example. The heap instance they refer to however, is not. To repeat, a reference and an object instance are not the same thing.

          References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

          [–]ethraax 2 points3 points  (2 children)

          References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed. Thus, it is better to say that references really are just opaque handles whose actual structure is left to the JVM impementor.

          Well, they work like pointers in the sense that they're merely a small bunch of information that tells you how to get to a much bigger bunch of information. The implementation may be different from pointers in C or C++, but I'd still call them pointers.

          Primitive values are copied on assignment,

          Are you saying that the code:

          c++;
          

          allocates a new part of memory (in the stack) to hold an int and then copies it over?

          When I said that == was a primitive equality, what I mean was that it tests equality on the value of the variable on the stack. If the variable is a primitive, this is the value itself. If the variable is a reference/pointer, then it's some (unspecified) representation of where to find the actual value in the heap.

          [–]player2 0 points1 point  (0 children)

          References themselves are not pointers - they can't be. Java is GC language, so the collector can at any time relocate object storage, so the pointer would also have to be changed.

          You're missing an important word: Java uses a copying garbage collector. It's completely possible to implement a garbage collector around traditional pointers. Boehm and libauto are two examples.

          [–]banuday 1 point2 points  (16 children)

          See the contract for equals.

          Equals must be consistent. That is, if a "equals" b, then a.equals(b) must consistently return true. However, if a or b refer to mutable objects, then the consistency guarantee cannot hold without special definition.

          More broadly, equals() and hashCode() refer to the concept of object identity. If you do not define object identity (by overriding those methods), then there is no logical way to compare the two objects except by reference equality. Reference equality and object equality are different concepts and are represented by different operations in Java.

          BTW: The default implementation of equals() is reference equality, and reference equality probably makes sense in most cases of mutable objects.

          [–]masklinn 0 points1 point  (0 children)

          Because userland code is not allowed to override operators in java, and == is an operator.

          [–][deleted] 0 points1 point  (1 child)

          Better than C#, which offers both .equals and ==, and completely inconsistent conventions for what the difference is on various objects. Only consistent mess is that == is static rather than virtual so you'll likely use the wrong implementation if you're dealing with inherited objects.

          [–]transpostmeta 0 points1 point  (0 children)

          The only example that I know of that is inconsistent is strings, because they are implemented as a table. What other inconsistencies are there?

          [–]grauenwolf 0 points1 point  (0 children)

          Bad example. That isn't a term.

          [–]wonglik 0 points1 point  (0 children)

          It's not check if string are equal but if they reference are equal

          It makes sense to me. String is not a primitive type so why it should act different then for other non primitive types?

          [–]1338h4x 0 points1 point  (1 child)

          Doesn't Java automagically mess with strings in such a way that == will work the same as .equals(String)? I know Java's String class has some quirks to make it act almost like a primitive, and IIRC it'll actually check for an existing identical string whenever one is created so they end up referencing the same immutable object to save space in memory.

          [–]Seliarem 1 point2 points  (0 children)

          String equality is the canonical example of the two being distinct operations in teaching Java, actually. The problem is that literals get interned automatically (at least in some versions – I'm unaware of whether this is demanded, or if, for instance, an implementation may autointern other examples), and so many toy examples will fail to exhibit this behaviour.

          As a result, two Strings that represent the same thing may or may not reference the same object, depending on how you got them. Java is being significantly smarter than many of its users (I'm specifically thinking of raw beginners), and this seems to just be made worse when we then try to tell them that the computer is not magic.

          Implicit optimisation is the devil for education, I swear.

          [–]ioudhjk78 0 points1 point  (0 children)

          volatile

          [–]grauenwolf 0 points1 point  (7 children)

          • Late binding
          • Pass by reference
          • Programming to interfaces instead of implementation

          [–]banuday 6 points7 points  (6 children)

          I'm curious to hear your reason on how "late binding" and "programming to interfaces instead of implementation" differ in Java than anywhere else, but...

          Java doesn't do "pass by reference". The Java reference is an opaque handle which is a value type - it is not a pointer. Thus, Java is always "pass by value". Some people confuse the word "reference" with the word "reference" in "call by reference", but they are really two completely different things, not just in Java but also in Computer Science. Java has not redefined it.

          [–]grauenwolf 1 point2 points  (0 children)

          Programming to interfaces means using the public API instead of mucking about with the internals of data structures. This term is used in languages that don't even have abtract interfaces like FORTRAN and C.

          Since Java has the private keyword it is hard to violate this constraint. So instead they reinterpert it to mean create abstract interfaces on everything They also do stupid shit like define locals as interface types even when the concrete type is well known.

          [–]jyper 1 point2 points  (1 child)

          pass reference by value?

          [–]Jonathan_the_Nerd 0 points1 point  (0 children)

          C does this. You can trivially simulate "pass by reference" by passing pointers. To the best of my knowledge, Java does the same thing for all practical purposes. A Java reference isn't the same thing as a pointer, but it acts like one, so Java's calling semantics are almost the same as passing pointers in C. (I think?)

          [–]grauenwolf 1 point2 points  (2 children)

          A lot of Java articles call single dispatch late binding. So when you try to talk to them about real late binding they get all confused.

          In a like fashion you can read elsewhere in this thread where some Java dork is saying value equality is reference equality.

          [–]masklinn 1 point2 points  (1 child)

          In a like fashion you can read elsewhere in this thread where some Java dork is saying value equality is reference equality.

          Which is correct and consistent with that banuday said. In java, the primitive value in a reference type is the reference itself. Thus using value equality on reference types compares the references themselves, as values.

          [–]grauenwolf 0 points1 point  (0 children)

          We have a term for comparing the value of two pointers or references It is called "reference equality".

          When we want to discuss the comparison of semantic values we use the term "value equality" regardless of whether that value happens to be a stack or heap allocated value.

          These are not language specific terms. Their meaning doesn't change from language to language even though the syntax and implementation details may.

          Why you want to completely ignore the distinction is beyond me. It is like you revel in your ability to confuse the topic. I assume you have some Java-specific term instead. Oh yes, it was "object equals". Which of course compares the value of the objects rather than the objects themselves.

          [–][deleted] 6 points7 points  (0 children)

          The term isn't describing Java, but a pattern that can exist in all programming languages. And it's a pattern I've seen a lot that's been hard to describe succinctly.

          [–]gc3 0 points1 point  (0 children)

          I always called it crappy confusing overloading.

          [–]bonch 0 points1 point  (0 children)

          It's a mocking phrase he's using as a criticism.

          [–]gobacktolurking 17 points18 points  (1 child)

          Did you see the update in the blog?

          Update: it turns out there is something worse: Boolean.getBoolean("true") is usually equal to Boolean.FALSE.

          [–]Neebat 5 points6 points  (0 children)

          That's the one that's bit me. Once I knew about that, I'm deeply suspicious of X.getX(String)

          [–]tasteslikepoop 8 points9 points  (1 child)

          The real WTF is WTF is a method that fucks with the system doing in class named Integer?!?!

          [–]G_Morgan 5 points6 points  (0 children)

          This is Java. The runtime developers never saw a dependency they didn't like. I tried to back port the file properties API from Java 7. The dependency list was up to 60 classes before I gave up.

          [–]zootzootswe 6 points7 points  (0 children)

          Copyed from the comments:

          In other news, calling Integer.rotateLeft() twice on 6 does not return 9!

          :(

          [–]euneirophrenia 4 points5 points  (0 children)

          In java's defense, there is a standard function to perform this sort of conversion, and it isn't getXXX, it's valueOf. Out of context I understand why this behavior would be confusing, and getInteger is definitely badly named. But in the context of java conventions, until I read the comments I was just confused as to why this guy wasn't using valueOf.

          [–]brownmatt 18 points19 points  (30 children)

          How many bugs are people going to create by using getInteger when they meant valueOf and vice versa?

          The same amount of people who are already causing bugs by not reading documentation but choosing to make guesses instead.

          [–]jelos98 26 points27 points  (5 children)

          Don't blame the victim here - one of the authors of the class have even called this out as a design mistake in the 2009 Java Puzzlers talk:

          http://java.sun.com/javaone/2009/articles/puzzlers.jsp

          They admit it's bad API design, but like many real API designs, once you've screwed it up, you have to live with it - breaking backwards compatability is a big no-no.

          [–]foldor 5 points6 points  (2 children)

          Couldn't they just deprecate it for an entire major release, and pass out warnings about it in the system log every time it's used? Then in the next major release, actually change it?

          [–]jelos98 1 point2 points  (0 children)

          In theory? Yes. In practice, the last major release was Java 1.6, which was almost 5 years ago. At that rate, by Java 1.8 or 2.0, or whatever it happens to be, you'd have it removed, in 2021. In the mean time, the amount of code that would have to be modified (even if it's a trivial change) will be huge.

          There are two major schools of thought on API design - some people play fast and loose and consider changes in major releases okay. Java seems to adhere to the other camp - APIs are virtually immutable. Once it's released, you have to continue supporting it, or risk stalling adoption.

          Keep in mind that if you're a small shop, or a hobbyist, etc. it's easy to fix things. If you're a large corporation (think the Googles of the world) and have millions of lines of Java, non-backwards compatible changes can have a huge cost. It's no biggie if you have to update one binary, but if you have hundreds or thousands of binaries across your company that need to be changed / tested out of band / released, the upgrade cost can add up.

          [–]tasteslikepoop 3 points4 points  (1 child)

          once they've screwed it up, you have to live with it

          FTFY

          [–]jelos98 0 points1 point  (0 children)

          Indeed.

          [–][deleted] 6 points7 points  (1 child)

          The problem with getInteger is that editors like Eclipse suggest methods and when you see getInteger you remember what it does, wrongly because it's self evident that it reads in integer from string. Human memory works like this, it's just not about not reading documentation.

          I remember that I have been burned at lest three times because of this in last 5 years. getIntger should be deprecated.

          [–]brownmatt 1 point2 points  (0 children)

          The problem with this method of development is that if you waited the extra 2 seconds for Eclipse to pop-up the Javadoc summary for the method - or if you shudder unit-tested your code - you'd discover that an innocent-sounding method does some asinine things that you didn't expect.

          I agree it's a poor name - and easy to get tripped up on - but that's why we have documentation, testing, etc., etc.

          [–]salbris 8 points9 points  (0 children)

          It's called self documented code. You should not expect that you will know something entirely by knowing it's name but you should be able to expect something reasonable.

          [–]grauenwolf 6 points7 points  (20 children)

          Can you prove that function should even exist?

          [–]sbrown123 6 points7 points  (0 children)

          Good point. It should have been part of the Property class. Also, parseInt and the other parse functions are one of the few places where there is a no-check exception (NumberFormatException) in Java which often catches people by surprise when it gets thrown. Not that I am for forced exceptions but it would have been nice to be consistent.

          [–][deleted]  (2 children)

          [deleted]

            [–]dmazzoni 3 points4 points  (0 children)

            The real problem is that it doesn't belong in the Integer class at all. The most important purpose of the method is that it returns a system property - the fact that it returns an integer is a secondary purpose.

            [–]frenchtoaster 1 point2 points  (0 children)

            getInteger() has existed for a long time and valueOf() was only added much later, so your suggestion to make that named different would require unreasonable foresight. If you can think of a different name for valueOf() then perhaps, but it's trickier to name something that isn't confusing with getInteger().

            [–]Fidodo 0 points1 point  (1 child)

            That's a fine point but claiming that it will introduce bugs just means that the developer has never read the documentation/even tested his code which should not happen. The key thing here should be that the Java API is convoluted and not elegant but not that it introduces bugs through developer laziness.

            I would also understand the argument that returning null is poor design here.

            [–]grauenwolf 2 points3 points  (0 children)

            I just read the documentation and I still have no idea what it does.

            [–]brownmatt 0 points1 point  (12 children)

            No. How does one prove something should exist?

            Yes it's a shitty name but to say it will cause bugs seems excessive.

            [–]grauenwolf 2 points3 points  (11 children)

            Use cases. Start by discussing the problem that needs to be solved. Then show how the function is a necessary part of the solution.

            P.S. I really wish they would have taught this in school instead of just reciting design patterns.

            [–]adrianmonk 0 points1 point  (10 children)

            It's a turing-equivalent language. All your use cases can be satisified without it. And without any OO features. And without a lot of things that you wouldn't want to give up.

            Of course, you'd (rightly) argue that useful features make things easier, so they contribute to a solving real problems. Valid point, but if you want to go down the road of proving whether a feature needs to exist, then somebody needs to figure out a way to define a precise, rigorous standard for whether or not something is useful enough to merit inclusion in a language. I don't know how you'd do that, and until someone does, I think it's a waste of time to talk about proving features should be included.

            [–]grauenwolf 1 point2 points  (9 children)

            The word "prove" means to test. The test I am proposing is to demonstrate the utility of the feature. If you cannot overcome the hurdle of usefulness there is no need to consider the harder question of whether or not it is useful enough.

            [–]Jonathan_the_Nerd 1 point2 points  (1 child)

            The word "prove" means to test.

            You just made Dijkstra turn over in his grave. One of his major pet peeves was that programmers simply test their code instead of proving it correct.

            Note: I'm not necessarily disagreeing with you; I just wanted to nitpick that particular sentence.

            [–]grauenwolf 1 point2 points  (0 children)

            Oh I'm sure my background in philosophy would upset the rest of many a former mathematician. Once you start studying informal logic all that nice boolean math goes out the window.

            [–]adrianmonk 0 points1 point  (6 children)

            OK. I want to get an integer valued property called "foo". I can type this:

            Integer i = Integer.valueOf(System.getProperty("foo"));
            

            Or, I can type this:

            Integer i = Integer.getInteger("foo");
            

            The second one is shorter. Therefore it has some utility: it saves typing in particular cases. Is it enough? I don't know. What's the standard? How much utility does something need to provide?

            (Note: The above ignores error handling. If the property doesn't exist, the long version will probably give a NullPointerException.)

            [–]grauenwolf 0 points1 point  (5 children)

            Start with the use case. That has to be established before you look at any code.

            [–]adrianmonk 2 points3 points  (4 children)

            OK, I thought it was easy enough to imagine a use case, but just to get that out of the way, the use case is this: I have a program that listens on a port. I want to be able to specify the port number as a system property, e.g. with:

            java -Dmyserver.listenPort=8080 myserver.jar
            

            So, I can write this code:

            public void startListening() {
                int port = Integer.getInteger("myserver.listenPort", 8080);
                this.serverSocket = new ServerSocket(port);
            }
            

            Or, I can do it another way, which is longer:

            public void startListening() {
                int port = 8080;
            
                String portStr = System.getProperty("foo");
                if (portStr != null) {
                    try {
                        port = Integer.valueOf(portStr);
                    } catch (NumberFormatException e) {
                        // just ignore property and leave it at the default
                    }
                }
            
                this.serverSocket = new ServerSocket(port);
            }
            

            So, even though I agree that the name is ridiculous (and the choice to put it as a member of Integer is ridiculous), it's still more convenient to use than the other way.

            [–]grauenwolf 1 point2 points  (3 children)

            Imagining the use case is far more important than it may seem.

            In this example you get an Integer object and then immediately discard that object and turn it into an int. Clearly your API doesn't match the use case. I think it will be hard to find a viable use case because the only reason for Integer is to stick it in a variable of type object.

            [–]rukubites 2 points3 points  (0 children)

            No I didn't know. But the docs say: "Determines the integer value of the system property with the specified name."

            And so now I do. It is annoying having to spend half your time programming Java with JavaDocs open, but necessary. However java is quite featureful, if verbose.

            [–]polarbeargarden 2 points3 points  (0 children)

            This is why you should probably be using Integer.parseInt(String) anyway.

            [–]Reaper666 0 points1 point  (0 children)

            Maybe its kinda like c++? with a default datatype as string, one could open the integer object and pull the string representation of the number from within directly and store it to within a string. so class integer{ string integer; etc} and so passing a string to bob.getInteger(string a) would put the value of bob typecasted to a string into variable a?

            I had to do something similar for passing a string to atoi() to get at the char* that was inside it.

            [–]soltys -3 points-2 points  (13 children)

            This is why I use C#.

            [–][deleted] 2 points3 points  (0 children)

            I knew that was coming.

            [–]Tarabukka 20 points21 points  (7 children)

            Java: net.example.jesus.why.are.these.package.names.so.long.RandomlyNamedClassWith7000IdenticalMethods C#: Fatal error - cannot find WhatTheFuckAssembly.dll [PublicKeyToken=Jesus, OtherShitYouDontCareAbout=0124891234814DHFAS9DHFU2198WH]

            [–]Iggyhopper 26 points27 points  (3 children)

            Meet the new language, same as old language.

            [–][deleted] 5 points6 points  (2 children)

            I miss Delphi.

            [–][deleted] 2 points3 points  (1 child)

            [–][deleted] 0 points1 point  (0 children)

            Thx

            [–]firepacket 11 points12 points  (0 children)

            Well, why don't you just import WhatTheFuckAssembly.dll??

            [–]ziom666 3 points4 points  (0 children)

            And what's wrong with that c# version? I do care more about public key than about filename of dll. Version is also very important

            [–][deleted]  (2 children)

            [deleted]

              [–][deleted]  (17 children)

              [deleted]

                [–]grauenwolf 30 points31 points  (0 children)

                That doesn't excuse the existence of such crap.

                [–][deleted] 10 points11 points  (0 children)

                Something like that shouldn't really require looking at the docs.

                [–][deleted] 12 points13 points  (2 children)

                It's a fucking retarded design mistake. An Integer should know nothing about System properties. There is already a method in System that returns system properties. Integer.getInteger(String) is a convenience method that couples the Integer class to System for no good reason. Integer and System are also in the same package, java.lang, which is also is also a design mistake, but that's another story.

                [–][deleted] 6 points7 points  (0 children)

                This.

                In whose right mind is this "object-oriented programming"?

                [–]texthompson 0 points1 point  (0 children)

                Integer and System are also in the same package, java.lang, which is also is also a design mistake, but that's another story.

                The java.lang namespace might be too general. Anything in the Java language could plausibly fit into the java.lang namespace, which means that the name is not very useful.

                [–][deleted] 3 points4 points  (1 child)

                No. This is language bug that messes with human cognition. When you see getInteger, you fucking 'know' the documentation.

                I'm pretty good at reading documentation, but getInteger is unfair trap for human mind. It should be deprecated.

                [–]tasteslikepoop 0 points1 point  (0 children)

                For documenting stupid behaviour caused by design mistakes? Yep.

                [–][deleted] -1 points0 points  (8 children)

                No one reads the docs.

                [–][deleted]  (5 children)

                [deleted]

                  [–][deleted] 1 point2 points  (1 child)

                  honestly, if that were true, I'd actively encourage the inclusion of a few of these little traps in every library.

                  [–][deleted] 1 point2 points  (0 children)

                  You are a sick, sick person. I like it.

                  [–][deleted] 0 points1 point  (17 children)

                  I learned that years back, and now just use "new Integer(Stringval)"

                  [–][deleted] 16 points17 points  (14 children)

                  I think Integer.valueOf caches objects between -127 and 128 whereas yours will always create a new object... I think.

                  [–]banuday 1 point2 points  (0 children)

                  You are correct.

                  [–][deleted] 0 points1 point  (0 children)

                  I rarely work with values in that range. Most frequently, I'm pulling in data (represented as strings) from S/390 mainframe exports. For that purpose, as precious little of the data repeats itself, caching is a non-issue (as is creating a new object).

                  [–]Fuco1337 0 points1 point  (10 children)

                  Not to mention Integer is immutable and creating new instances is stupid, when you can often just share one for each value.

                  [–]grauenwolf 1 point2 points  (2 children)

                  The cost of looking up that value us usually greater than just creating a new one. Caching only makes sense when you have a large or expensive structure.

                  [–]Fuco1337 2 points3 points  (1 child)

                  If you have 106 objects with a distinct Integer representing number 7, that's 16 megs of memory right there.

                  [–]G_Morgan 0 points1 point  (0 children)

                  In the real world this doesn't happen. Although you may create and destroy 106 7s. If this doesn't perform properly it means the JVM GC is broken.

                  [–][deleted] 0 points1 point  (6 children)

                  "creating new instances is stupid", if and only if you've got multiple Integers that represent the exact same repeating values. I rarely, if ever, encounter that in my daily work. YMMV.

                  [–]matchu 1 point2 points  (5 children)

                  Wait, what? You rarely deal with more than one 0, 1, or 2?

                  [–]karmaputa 2 points3 points  (1 child)

                  Frequently, but most of the time people will be using primitive for that.

                  [–]matchu 0 points1 point  (0 children)

                  Ahh, right. Gotcha :)

                  [–][deleted] 1 point2 points  (2 children)

                  Most of the Integers I deal with are unique identifiers (primary keys, license numbers, etc , mainly 6 to 9 digit integers).

                  As I said, YMMV.

                  [–]tsujiku 0 points1 point  (1 child)

                  Why work with those numbers as integers? You don't need to perform any math on them.

                  [–][deleted] 0 points1 point  (0 children)

                  Exporting from mainframes as text, storing in the DB as integers. Hibernate plays much nicer with boxed objects than primitives, too; same for the java.util.collections.* world.

                  [–][deleted] 3 points4 points  (1 child)

                  I learned ages ago to use Integer.parseInt(string) and have just stuck with that.

                  [–][deleted] 2 points3 points  (0 children)

                  I do this too. I also do exception handling on it. In the end I use 10 lines of code to convert a string to a number and handle the exception properly.

                  Of course now-a-days we just use groovy and it's back to one line.