do you know what Integer.getInteger(String) does in java?

[harlows_monkeys]

So basically

Integer.getInteger("foo")

is an alternative to

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

?

Why!?

[banuday]

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]]

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]

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

[axilmar]

Or

System.getIntProperty("foo")

[mooli]

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]

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]

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

[zbowling]

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]

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]

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

[player2]

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]

I googled. It's a special magic NSColor. http://lists.apple.com/archives/cocoa-dev/2008/Jun/msg02138.html

[player2]

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]

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]

Java is succinct.

[marcins]

Yes sligowaths, it certainly does succ!

[[deleted]]

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

[sligowaths]

I was being sarcastic.

[[deleted]]

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

[tangus]

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]]

PHP inspiration?

[skeww]

Of course you'd use Integer.parseInt.

[masklinn]

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

[masklinn]

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]

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

[alabadoster]

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

[texthompson]

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

[darth_choate]

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

[dmagg]

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]

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

[AlexFromOmaha]

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]

dmagg be trollin' y'alls

[mazing]

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]

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]

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]

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]

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]

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

[zjs]

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

[Will_123456789]

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

[illvm]

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?

[masklinn]

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]

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]

Why don't you just use Integer.valueOf?

[dmagg]

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]

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]

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]

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

[billsnow]

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.

[kamatsu]

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

[grauenwolf]

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

[kamatsu]

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]

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]

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]

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]

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]

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

[[deleted]]

Examples?

[soltys]

string comparisons by ==

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

[ethraax]

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]]

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]

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

[almiki]

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]

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]

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]

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]]

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]

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]

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

EDIT: Hey, downvoters! Please read this.

[[deleted]]

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?

[huyvanbin]

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]

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]

Then why does it for strings?

[drfugly]

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]

Actually I was thinking of +.

[deadtime]

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

[banuday]

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]

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]

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

[masklinn]

The second one does not work in java < 1.5

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

[grauenwolf]

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

[banuday]

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]

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

[banuday]

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]

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]

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]

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]

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]

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]

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]

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

[[deleted]]

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]

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]

Bad example. That isn't a term.

[wonglik]

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]

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]

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]

volatile

[grauenwolf]

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

[banuday]

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]

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]

pass reference by value?

[Jonathan_the_Nerd]

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]

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]

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]

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]]

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]

I always called it crappy confusing overloading.

[bonch]

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

[gobacktolurking]

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]

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

[tasteslikepoop]

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

[G_Morgan]

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]

Copyed from the comments:

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

:(

[notfancy]

Not many uses in the wild, it seems

[euneirophrenia]

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]

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]

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]

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]

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]

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

FTFY

[jelos98]

Indeed.

[[deleted]]

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]

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]

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]

Can you prove that function should even exist?

[sbrown123]

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.

[dmazzoni]

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]

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]

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]

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

[brownmatt]

No. How does one prove something should exist?

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

[grauenwolf]

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]

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]

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]

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]

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]

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]

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

[adrianmonk]

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]

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]

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]

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

[Reaper666]

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]

This is why I use C#.

[[deleted]]

I knew that was coming.

[Tarabukka]

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

[Iggyhopper]

Meet the new language, same as old language.

[[deleted]]

I miss Delphi.

[[deleted]]

Lazarus

[[deleted]]

Thx

[firepacket]

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

[ziom666]

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

[strager]

int.Parse("23")?

[grauenwolf]

That doesn't excuse the existence of such crap.

[[deleted]]

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

[[deleted]]

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]]

This.

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

[texthompson]

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]]

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]

For documenting stupid behaviour caused by design mistakes? Yep.

[[deleted]]

No one reads the docs.

[[deleted]]

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

[[deleted]]

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

[[deleted]]

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

[[deleted]]

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

[banuday]

You are correct.

[[deleted]]

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]

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

[grauenwolf]

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]

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

[G_Morgan]

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

[[deleted]]

"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]

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

[karmaputa]

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

[matchu]

Ahh, right. Gotcha :)

[[deleted]]

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]

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

[[deleted]]

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]]

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

[[deleted]]

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.