if (!"success".equals(statusCheck))
Videos
I’m writing code for a rock, paper, scissors game and I need to check the users input to make sure they input Rock, Paper, or Scissors. I know that you can use “!=“ to compare two strings and “.equals” in an if-else statement. For the most part I have the entries, as well as the comparing the two entries to see who wins, however, I’m having trouble checking to make sure their input is correct to proceed on, I’ve tried “!=“ but it automatically will default to “Wrong Choice!” (as I have that as what will output if their entry isn’t either of the options) and I can’t seem to figure it out. Any ideas on how I would do that?
Here is the code I have for it so far,
import java.util.Scanner;
public class Assignment2 { public static void main (String[]args) { String player1; String player2;
Scanner keyboard = new Scanner(System.in);
System.out.println("*****Hello! Welcome to the Rock, Paper, Scissors Program*****");
System.out.println("Rules: This is a two player game, both players must take turns entering their choice");
System.out.println("\tRemember, rock beats scissors, scissors beats paper, and paper beats rock!");
System.out.println("Player 1: Choose rock, paper, or scissors: ");
player1= keyboard.nextLine();
if ((player1 != "Rock") || (player1 != "Paper") || (player1 != "Scissors" ))
{
System.out.println("Wrong Choice!");
player1 = keyboard.nextLine();
}
else
{
player2 = keyboard.nextLine();
}
System.out.println("Player 2: Choose rock, paper, or scissors: ");
player2=keyboard.nextLine();
if (player1.equalsIgnoreCase("Rock") && player2.equalsIgnoreCase("Scissors"))
{
System.out.println("Player 1 wins!");
}
else if (player1.equalsIgnoreCase("Scissors")&&player2.equalsIgnoreCase("Paper"))
{
System.out.println("Player 1 wins!");
}
else if (player1.equalsIgnoreCase("Paper")&&player2.equalsIgnoreCase("Rock"))
{
System.out.println("Player 1 wins!");
}
else if (player1.equalsIgnoreCase(player2))
{
System.out.println("It's a tie!");
}
else
{
System.out.println("Player 2 wins!");
}
keyboard.close();
}}
I guess it's just consistency, or "principle of least astonishment". String is an object, so it would be surprising if was treated differently than other objects.
At the time when Java came out (~1995), merely having something like String was total luxury to most programmers who were accustomed to representing strings as null-terminated arrays. String's behavior is now what it was back then, and that's good; subtly changing the behavior later on could have surprising, undesired effects in working programs.
As a side note, you could use String.intern() to get a canonical (interned) representation of the string, after which comparisons could be made with ==. Interning takes some time, but after that, comparisons will be really fast.
Addition: unlike some answers suggest, it's not about supporting operator overloading. The + operator (concatenation) works on Strings even though Java doesn't support operator overloading; it's simply handled as a special case in the compiler, resolving to StringBuilder.append(). Similarly, == could have been handled as a special case.
Then why astonish with special case + but not with ==? Because, + simply doesn't compile when applied to non-String objects so that's quickly apparent. The different behavior of == would be much less apparent and thus much more astonishing when it hits you.
James Gosling, the creator of Java, explained it this way back in July 2000:
I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++. I've spent a lot of time in the past five to six years surveying people about operator overloading and it's really fascinating, because you get the community broken into three pieces: Probably about 20 to 30 percent of the population think of operator overloading as the spawn of the devil; somebody has done something with operator overloading that has just really ticked them off, because they've used like + for list insertion and it makes life really, really confusing. A lot of that problem stems from the fact that there are only about half a dozen operators you can sensibly overload, and yet there are thousands or millions of operators that people would like to define -- so you have to pick, and often the choices conflict with your sense of intuition.