Print int in a JLabel

[kkid]

I have a java file containing many methods which do calculations based on some variables and arrays in my program to give ints as a result. I now want to be able to show this data to my users by putting it in a JLabel. However, as the output is int instead of String, I don't know how to do this.


Example code:

Where I am trying to use it:

JLabel totalSeatsTheatreAnswerLabel = new JLabel(Statistics.totalSeatsTheatre());

The method returning an int:

public static int totalSeatsTheatre(){
        
        return  (BookingsSystem.A.length + BookingsSystem.B.length +
                 BookingsSystem.C.length + BookingsSystem.D.length +
                 BookingsSystem.E.length + BookingsSystem.F.length +
                 BookingsSystem.G.length + BookingsSystem.H.length +
                 BookingsSystem.J.length + BookingsSystem.K.length +
                 BookingsSystem.L.length);
    }

[KevinWorkman]

Check out the API for both the String and Integer class for useful functions.

[SurfMan]

JLabel expects a String as parameter. Method totalSeatsTheatrs returns an int, and constructor JLabel(int) does not exist. There are several options KevinWorkman is pointing to:

The official way: new JLabel(String.valueOf(totalSeatsTheatre()));
or: new JLabel(Integer.toString(totalSeatsTheatre()));
or The Quick But Ugly Way™: new JLabel("" + totalSeatsTheatre());

[KevinWorkman]

Note that String.valueOf(int) simply calls Integer.toString(int). The quick but ugly way you mention should not be used.

[kkid]

ah, those seem perfect, thanks.

I will probably use toString but why is the last method ugly?

[KevinWorkman]

The last method of using String concatenation to combine an empty String with your int is ugly because it's doing unnecessary work. Behind the scenes, the append operator is creating a StringBuilder (or StringBuffer) instance, then appending the two operands, then calling toString(). So if you do this in a loop, for example, it can kill performance in a way that isn't always obvious to track down. It's best not to get into the habit in the first place.

To put it another way, if you had an interview for a job and used "the ugly way" to turn an int into a String, you wouldn't get the job.

[SurfMan]

My preferred way is String.valueOf(...) since you can use that for all primitives, so if you decide your int needs to be a long, you don't have to change all the toString() calls. But that's a matter of preference.

Fun fact: Integer.toString() calls String.valueOf(int) which in turn calls Integer.toString(int, 10)... Somebody didn't read their own API :)

[kkid]

To put it another way, if you had an interview for a job and used "the ugly way" to turn an int into a String, you wouldn't get the job.

It's that serious?
Wow!

Thanks for all the help, both of you!

[KevinWorkman]

My preferred way is String.valueOf(...) since you can use that for all primitives, so if you decide your int needs to be a long, you don't have to change all the toString() calls. But that's a matter of preference.

That's fair. The potential downside of that is it'll be less obvious if you pass in a wrong type. That'll be a runtime error (or worse, a logic error that leads to strange behavior) instead of a compile-time error. Like you said, it's a matter of preference and context.

Fun fact: Integer.toString() calls String.valueOf(int) which in turn calls Integer.toString(int, 10)... Somebody didn't read their own API :)

Actually I looked directly at the code for Integer.toString(int), which does not call Integer.toString(int, 10) or String.valueOf(). The API mentions Integer.toString(int, 10) as an example of the value returned, but that doesn't mean it actually calls the method. Even if it does, I'm not sure how that negates me pointing out that String.valueOf() just calls the Integer.toString() method.

    public static String toString(int i) {
        if (i == Integer.MIN_VALUE)
            return "-2147483648";
        int size = (i < 0) ? stringSize(-i) + 1 : stringSize(i);
        char[] buf = new char[size];
        getChars(i, size, buf);
        return new String(buf, true);
    }

[KevinWorkman]

It's that serious?
Wow!

Thanks for all the help, both of you!

I don't know if I would call it serious, but it's one of those things that newbies do without really thinking about. Best not to get into bad habits from the start.

[SurfMan]

Actually I looked directly at the code for Integer.toString(int), which does not call Integer.toString(int, 10) or String.valueOf(). The API mentions Integer.toString(int, 10) as an example of the value returned, but that doesn't mean it actually calls the method. Even if it does, I'm not sure how that negates me pointing out that String.valueOf() just calls the Integer.toString() method.

I didn't negate any of your points. I am with you here. I am on your side. Just adding to the conversation. I merely looked into the source code to see how the different utility methods worked and ran into the little gem I mentioned earlier. Coming to that, that is actually JDK 6 source. I opened a random project I have in IntelliJ IDEA and examined the source and apparently it still ran on JDK 6. Didn't check. Your example is from JDK 7 so that makes it two valid points :) Nitpick: I pointed out something about Integer.toString() and not Integer.toString(int).

Anyway, I think the OP got the point :)

[Tolls]

Single point of change should they decide to change the default radix of toStringing() and int.
String contains all the standard toString() methods for primitives, so that was the obvious place to put that default.
Consequently the toString for the primitive wrappers uses those base methods.

I can see the logic, put it that way.