1

I don't understand the difference between

String[] arrayName = {/*some data here*/};

and

String arrayName[] = {/*some data here*/};

Is there any difference between placing square brackets after the type (String[]) and after the array name (String arrayName[])?
If so, what?

Mureinik
  • 297,002
  • 52
  • 306
  • 350
python_is_good_cpp_is_best
  • 77
  • 1
  • 7

2 Answers2

4

Both declarations will have the same result. The difference is only stylistic. Having said that, most Java style guides would recommend having the square brackets on the type name, not the variable name, i.e.:

String[] arrayName = {/*some data here*/};
Mureinik
  • 297,002
  • 52
  • 306
  • 350
0

They are almost same, with a little semantical catch.

By:

String[] array;
  1. You declare the variable named array which is of the type of String[] (String array);
  2. In this code, you can declare other variables in-line, with the same String[] type (String[] array1, array2;);

By:

String array[];
  1. You declare a variable which will be referring to the array object, elements of which, must be type of java.lang.String;
  2. You can have something like String array[], name, surname; which is not really a decent code to write, but Java semantics do not block this.
Giorgi Tsiklauri
  • 9,715
  • 8
  • 45
  • 66
  • 2
    No, this explanation is simply incorrect — both declare exactly the same object having the exact same type. The second point you’re making is correct, but that doesn’t change the fact that the first point is wrong. – Konrad Rudolph Sep 25 '20 at 12:31
  • Which *first point* are you referring to? in the daily usage, yes, there are no many occasions you encounter, but these two are not the same. See the example I have provided. – Giorgi Tsiklauri Sep 25 '20 at 12:32
  • 1
    The “first point” is the point (1) you enumerate. I’m not talking about “daily usage” or anything like that. I’m saying that the distinction you are making plain *does not exist*. And, contrary to what you are saying in your comment below the question, the accepted answer on the duplicate question is correct. – Konrad Rudolph Sep 25 '20 at 12:34
  • @KonradRudolph I'm not sure I understand your point. Objects, at runtime, will be same, and even at the compile time they declare the objects *almost* in a same way. But what you can do with the fact that you can write `String arr[], name;`, which you can't have in other way? I don't think this is **simply incorrect**, as even the bytecode differs. Have a look on it yourself. Besides, I headline this answer as they are almost same. – Giorgi Tsiklauri Sep 25 '20 at 12:37
  • 1
    “at the compile time they declare the objects *almost* in a same way” — No, not “almost”. *Exactly* the same. Both `array` declarations have the exact same static and dynamic type (namely, `[Ljava.lang.String`). And no, the byte code doesn’t differ either, it’s exactly the same in both cases. — You’re right that, when you declare multiple variables in a single statement, different things happen. But this is completely unrelated to the fact that `T[] obj` and `T obj[]` are identical. – Konrad Rudolph Sep 25 '20 at 12:42
  • Does your point lead to another point that `T` does not play a role here (whether it's `T[]` or `T` in the declaration part)? then, first of all, how would you answer on my argument above? why does type inference not work? secondly: what will happen if I inject an array from the outside world? can I expect `int variable` (like `methodName(int var){..}` or `int someField`) and receive/assign an array as an argument/field? what if I use IoC? will the compiler infer `T` as `T[]` at compile time? no, it will not. I will look more into this later. – Giorgi Tsiklauri Sep 25 '20 at 12:56
  • I don’t understand that comment. I use `T` because it’s the conventional placeholder for an arbitrary type. What do you mean by “inject an array from the outside world”, and what does IoC have to do with any of that? I also don’t understand your point about type inference, since `T` ≠ `T[]`, obviously; but the compiler *will* infer the correct type when used in a generic context, and Java ≥10 will correctly infer the array type in a local variable declaration using `var`. – Konrad Rudolph Sep 25 '20 at 13:01
  • I know what is `T`, and what is ``, `N` or `S,U,V`... *What do you mean by “inject an array from the outside world”, and what does IoC have to do with any of that?* - I mean what I said. What if I want to inject the object from the container? or what if I want to consistently pass an array in the method/field? why it is not resolved as an array type if "T[] obj and T obj[] are identical"? will the `method(arrayReference);` work considering signature I have above? it will not. I have *never ever* said that IoC is key here, it is an example.. doesn't matter if it's IoC or method or field.. – Giorgi Tsiklauri Sep 25 '20 at 13:05
  • 1
    Sorry but that comment didn’t reduce the confusion. — “What if I want to inject the object from the container?” — Just do it. Whether the object was declared with one syntax versus the other is irrelevant. — “why it is not resolved as an array type in case of int variableName then?” — Because you’re, uh, not declaring an array here. I’m not claiming that `T obj` is the same as `T[] obj`. I’m stating that `T[] obj` and `T obj[]` are identical. By contrast, `T obj` is different. But that’s not what the question is about, and I don’t understand why you’re bringing it up. – Konrad Rudolph Sep 25 '20 at 13:12
  • "*But this is completely unrelated to the fact that T[] obj and T obj[] are identical*" - your comment. OK, we may continue (probably chat is better for this) about this later if you wish too.. but I have to run now (unfortunately). – Giorgi Tsiklauri Sep 25 '20 at 13:13
  • We all know that `String[] array;` and `String array[];` are the same. Albeit perhaps poorly explained I think that Giorgi Tsiklauri has got a point in that the latter form allows you to mix single strings and string arrays in the same declaration (making that declaration about unreadable) while the same is not true for the former. – Ole V.V. Sep 25 '20 at 16:00