Danny02's code is clever in that it works almost entirely on the integer used to represent a move. The move names are stored in a table that can be quickly consulted by the move's numeric code. The winner is determined by some tricksy manipulation of the numeric representation.

My main criticism of such an approach is that it invests a lot into the "magic numbers" being used. For a known game like Rock, Paper, Scissor this is fine, but if you were writing a bigger game this approach is brittle, any changes to the number of moves can result in the code breaking in subtle ways without any compilation errors.

I would also comment on your code OP, you are comparing objects using "==". This is not a good idea as this compares the objects "identity" rather than their value. Strings are objects, you should use equals() method, like: computerMove.equals("Rock")

I think the program is best written using an enumeration representing all available moves:

public class RockPaperScissor {

public enum Move {
Rock, Paper, Scissor
}

private static final Move [] Moves = Move.values();

public static Move getPlayerMove() {
int index;
do {
TextIO.putln("What's your move?");
TextIO.putln();
for(int i = 0 ; i < Moves.length ; ++i) {
TextIO.putln(i + " " + Moves);
}
index = TextIO.getlnInt();
}
while(index < 0 || index > Moves.length);

return Moves[index];
}

private static Move getComputerMove() {
int index = (int)(Moves.length * Math.random());
return Moves[index];
}

private static boolean beats(Move player, Move computer) {
switch(player) {
case Rock: return computer == Move.Scissor;
case Paper: return computer == Move.Rock;
case Scissor: return computer == Move.Paper;
}

// Hush little compiler, don't you cry
throw new IllegalArgumentException("Unknown player move: " + player);
}

public static void main(String[] args) {
Move player = getPlayerMove();
Move computer = getComputerMove();

TextIO.putln("Computer chose: " + computer.toString());
if(player == computer) {
TextIO.putln("Tie!");
} else {
boolean win = beats(player, computer);
if(win) {
TextIO.putln(player + " beats " + computer);
TextIO.putln("You win!");
} else {
TextIO.putln(computer + " beats " + player);
TextIO.putln("Sorry. You lose.");
}
}
}
}

If you wanted to add an additional moves, to make rock-paper-scissor-bazooka or whatever, there would be a lot less work to do. Also, I believe the code is much clearer than the clever but hard to decipher solution presented earlier. I also like when a program is split up into lots of small, east to understand functions.

For a first attempt your original code is quite good. The main weakness was the aforementioned equality bug. Other, minor points to consider are delaying variable declarations to where they are first initialised/used, and reducing the repetition of code for handling win/loss inside each "case" block.

Another thing is to have a clean, consistent code style. In particular the brace placement and indentation of your switch statement is inconsistent.

There are two common styles:

control statement {
// Statments indented one "logical unit" here
}

// and

control statement
{
// Statments indented one "logical unit" here
}

Pick one you like the look of and go with it.

Some code styles allow for single line control blocks to omit the braces. However, most people believe this is a poor idea as you can all too easily add a second line without remembering to put the braces in. I would recommend adopting a style that always using braces around any control block.

some thoughts, I thought about using an enum but for this small program there weren't really a benefit for it(also I tried to write it as small as possible :-) ). Also I didn't wanted to confuse Adderly cause enums are a bit complicated to understand especially in Java.
[/quote]
I don't think enums are particularly confusing. They have a few unusual properties, but they are mostly intuitive. I think they are less confusing than magic numbers.

why do u throw an exception^^
[/quote]
No particular reason, but I don't think it makes sense to continue processing in the case where the Move is not catered for. For example, if such a function was used by AI logic it could end up in an infinite loop (i.e. a general "is move A better than move B").

I think in Java it is also a good habit to only have 1 return in a method

boolean wins = false;

switch(player) {
case Rock: wins = computer == Move.Scissor;
case Paper: wins = computer == Move.Rock;
case Scissor: wins = computer == Move.Paper;
}
return wins;

[/quote]
I think this is limiting. I think early returns are a great way of getting edge cases out of the way quickly. Your code now contains a bug: there are no break statements between the cases, resulting in fall though.

(the compiler can optimize better, but who cares :-) )
[/quote]
I don't believe this is the case. Do you have any evidence for this assertion?