Question

String playerlist;

for(Player p : allplayers){
    playerlist += p.getDisplayName() + ", ";
}

sendMessage(playerlist);

How can I accomplish this? I need to have a variable inside my for-loop, and then access it outside of the loop.

Thanks, and sorry if this is a very nooby question. I just can’t figure it out.

Answer 1

You’re close. You need to change the first line to

String playerlist = "";

In Java it’s illegal to use a variable before it’s initialized, and the line

playerlist += p.getDisplayName() + ", ";

desugars(*) to

String temp = playerlist;
playerlist = temp + (p.getDisplayName() + ", ");

Once you initialize playerlist, you are able to read off its contents into the temporary variable, and then update playerlist.

There are two higher-level suggestions, though.

1. If you have a join method available, as some libraries provide (as do the the .NET and Python platforms), you can just use a join, which is easier to read.
2. However, if you don’t have a join method available (AFAIK, the Java standard library provides no such thing), you should use a StringBuilder, consistent with @anubhava’s suggestion. You’ll get better performance on large numbers of strings, and the code is easier to understand, which is a win-win.

---

EDIT: As @edalorzo rightly mentions in the comments, you will only get an error for not initializing a local variable, and both static and instance fields are automatically initialized. Specifically, numeric types (int, long, double, etc.) are initialized to 0, booleans are initialized to false, and reference types are initialized to null.

The spec explicitly describes the automatic initialization of fields, so you can rely on it, but it’s rarely what you want. Normally, you will want a non-default value of the field when you use it later, since null isn’t terribly useful (and many languages, particularly functional languages like Standard ML, go without null altogether). So I would recommend initializing all the fields of your objects in the constructor.

---

(*): The “desugaring” I show above is almost accurate: in truth, playerlist is evaluated only once, which doesn’t affect the behavior of this particular program.