8

I have a function:

draw(int[] a)
{
   //...
}

and I want to pass in the array {3,4,5}. Why can't I call:

draw({3,4,5});
Mike
  • 2,514
  • 2
  • 23
  • 37
  • Here is ref: http://stackoverflow.com/questions/1610757/pass-array-to-method-java and can help you http://www.jforeach.com/difference-between-object-and-reference-in-java/62 – Pankaj Kumar Feb 10 '12 at 05:36

9 Answers9

7

The type of {3,4,5} is ambiguous (could be int[], short[], long[], etc..). Try:

draw(new int[]{3,4,5});
calebds
  • 25,670
  • 9
  • 46
  • 74
2

{3,4,5} doesn't reflect what type is. You should call like this draw(new int[]{3,4,5});

kosa
  • 65,990
  • 13
  • 130
  • 167
2

Because Java is not matlab! You must create/register an array before you can pass it!

Mikhail
  • 7,749
  • 11
  • 62
  • 136
2

you need to call it as draw(new int[]{3,4,5})

{3,4,5} is a array initialization method, without the preceeding new int[] it makes no sense. You can view {3,4,5} as a parameter to a function called int[] which returns you a new array.

Navneeth G
  • 7,255
  • 1
  • 15
  • 18
1

Because {3,4,5} is not an array. (If it was, what would it be an array of?)

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
1

You can pass it this way: draw(new int[]{3,4,5}).

Abrixas2
  • 3,207
  • 1
  • 20
  • 22
1

See the other ansers, why you can't do it like you try.

But you could do something like this:

draw(int... a)
{
    //...
}

draw(3,4,5);
Matthias Bruns
  • 899
  • 8
  • 13
  • Yes, this is the preferred way for me too since you still can pass "normal" arrrays. – Axel Feb 10 '12 at 07:29
0

Arrays are passed-by-reference. Passing-by-reference means that when an array is passed as an argument, its memory address location is actually passed, referred to as its "reference".

  1. {3,4,5} doesn't reflect what type is are you going to use.
  2. If you want pass array you should call like this draw(new int[]{3,4,5}); so method can know you are going to use the array.
Suresh
  • 1,494
  • 3
  • 13
  • 14
0

I'd like to respond to some of the other answers here. It was a language design choice not to support that syntax for array creation. But probably not because this construct is always ambiguous. Just saying {3,4,5} is "ambiguous" or "doesn't reflect the type" is an oversimplification.

There's the potential for ambiguity with array initializer expressions as shorthand for array creation, but it doesn't come from the simple cases like {3,4,5}. You could define a rule for unambiguously determining a type for an array initializer like {x,y,z} in the same way that the type of an arithmetic expression like x+y+z is determined, using type promotion rules. So would {3,4,5} be in int[] or a short[] in this hypothetical case? It would be an int[], because 3, 4, and 5 are ints.

Even with objects without interfaces, you could say that the type of a {x,y,z,...} is the most specific common superclass to which all the array element expressions are assignable. The lowest common denominator, if you will.

But with interfaces, you effectively have multiple inheritance, so you might have multiple supertypes to which all elements of an array are assignable, but neither of those supertypes are assignable to each other, so you have a true ambiguity.

And the zero-element case, {}, now that's ambiguous.

The language designers could have provided a rule that says "an array initializer expression on its own is treated like a new T[]{...} for the type of the initializer". Even with interfaces, they could have provided it and tacked on "... in the case where the type is unambiguous, otherwise it's a compile error". But they didn't. Maybe because they didn't want to allow the ambiguity. Maybe because the type determination rules would be to complicated for the compiler or for developers. Maybe because they didn't want to make it too easy to allocate a bunch of little arrays on the heap. But not because {3,4,5} is fundamentally impossible to interpret.

Andrew Janke
  • 23,508
  • 5
  • 56
  • 85