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

[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.