String array refuses to accept passed element through a method

[Emus]

i have a method:

public void updateUsers(String[] connectedUsers)

which takes a string array as the parameter. What i'm trying to do is through another class i'm trying to access the method client.updateUsers(client.name); name is a string variable i'm trying to pass that through the updateUsers method so that it updates the list whenever a new client is created with the clients name (string).

I keep getting a compilation error saying that updateUsers(java.lang.String[]) in Client cannot be applied to (java.lang.String).

Here's the exact line i tried:

client.updateUsers(client.name);



Also in the class that i'm trying to access the method (server) which is in client i tried
String[] sa = new String[15];
sa[0] = "test";

and it works?



I don't understand why it's not accepting a string. I tried client.updateUsers() i get a compilation error saying that it can't be applied to ()

[sjalle]

The method name updateConnectedUsers is plural and it does not accept
a String,hmmmm to me it seems like you should use a String [] (array) here

[Emus]

Slight mistake there the method's name was updateUsers nonetheless it does the same thing. Did you mean i should pass the element through the updateUsers i tried passing it client. updateUsers(connectedUsers[0] = client.name) and it still gives me the same compilation error as above seens like it doesn't want a string:/

[meisl]

I don't understand why it's not accepting a string.

A string is not an array of strings. That's why.

Hmm, not quite a meisl-like answer... So here comes one:

Even an array of strings with only one element is still of type String[] whereas a single string is of type String. However, you CAN pass a single string to your method by "wrapping" it in an array with only one element. I guess that's what you've tried via

client.updateUsers(connectedUsers[0] = client.name)

Problem here: the type of your (actual) argument is still String, not String[]: Apriori, connectedUsers[0]=client.name is an assignment, where you assign the string client.name to the element connectedUsers[0] (also of type String). Then, an assignment is also an expression, the type of which is that of the left hand side. Therefore you can use it as an argument to a method, as you did.
But still you pass an argument of the wrong type String instead of String[].

To fix this, you could write

String[] dummy = new String[1];
dummy[0] = "Theodore Test";
updateUsers(dummy); //<<-- pass the ARRAY, not an element!

which is lengthy and requires the name dummy that you wouldn't use anywhere else. You can shorten this by using an array literal:

updateUsers( new String[] {"Theodore Test"} );

See, both dummy[0] and "Theodore Test" are strings but only the latter is a string literal. Similarly, both dummy and new String[1] are arrays but only the latter is an array literal (actually of an array filled with null). The part in curly braces of the literal expression new String[] {"Theodore Test"} is called an array initializer, where you literally state what the elements should be.
However, you need NOT necessarily use literal expressions within the initializer like I did here. Any expression of the correct (element) type is allowed, eg. client.name.

--------------

If you still don't understand, I really can't help. Now for the actual reason for this posting
In java 1.5, there has been introduced a (syntactical) means to get things like this even shorter. The feature is called varargs and demonstrated in the code below, as well as another new feature: the enhanced for-loop. After compilation try

javap AnotherTigerTest

on the command line to see that varargs is entirely syntactical. Disassemble with

javap -c AnotherTigerTest

to see that enhanced for-loop is also only syntactical (requires some knowledge of the VM-language; traversing the array with enhanced for-loop is even more efficient it seems).

/**
  @author meisl
  */
public class AnotherTigerTest {

  static void updateUsers(String[] users) {
    System.out.println( "old style: updateUsers(String[])");
    for (int i=0; i<users.length; i++) {
      System.out.println( users[i] );
    }
    System.out.println();
  }

  static void updateUsers1_5(String... users) {  // varargs
    System.out.println( "using varargs: updateUsers(String...)");
    for (String user: users) {  // enhanced for-loop
      System.out.println( user );
    }
    System.out.println();
  }

  public static void main(String[] args) {
    updateUsers( new String[] {"Fanny Foo"} );  // single string must be wrapped in array
    updateUsers( new String[] {"Fanny Foo", "Barney Bar"} );  // for this, an array literal is used

    updateUsers1_5( "Fanny Foo" );  // Tiger allows for simpler syntax
    updateUsers1_5( "Fanny Foo", "Barney Bar" );  // although, internally it's the same
    updateUsers1_5( new String[] {"Fanny Foo", "Barney Bar"} );  // so this still works as well
  }

}

[sjalle]

Well, the reason for this being so is...

String [] sa;

is a 'packed' array in memory, e.g. it consists of contiguous 4-bytes
all serving the same purpose: storing addresses to other places in memory.
These places are where the

String sa [index]

reside with their little local
memory domains where (among other things) their String value is.

So, in other words, the stringarray is not a nicely packed block of ram
with text in it, the strings are scattered all over the place in memory, but
you don't have to worry about that, the beaty of virtual address languages....

String [] sa;

to the compiler, is just the starting address of that array. If you
want the compiler to hand you some text then you must specify which
element, counting from zero, from that start address that you would like.

So when a parameter is like AClass [], then the compiler sets up code
to handle an address to the start of an array. On the other hand,
when you write aClass[5] the compiler sets up code that acts upon the class/element.
----------------
As for the varargs, really neat, and about time considering how long this
feature has been around in other languages. It may seem like some of
the hardcode OO gurus at sun have had to give in a little...