can't do == with char
New to Java yesterday and on page 100 on The Complete Java Reference J2SE5 Edition.
I read about incompatiblities between variable types and as I flip through the pages of the book, all the if (var == #) was comparing numbers. There hasn't been an example on how to compare a char variable.
What I aim to do is this.
char eyes;
eyes = (char) System.in.read();
if (eyes == "red")
{
System.out.println("You are right!
}
else
{
System.out.println("Wrong! ");
}
And, of course, it keeps dying on ==. Can someone explain what I have to do to get this to work?
Thanks!
A char is a 16-bit primitive that represents a single Unicode character. You can't compare it to an object reference (a String literal in this case).
char eyes = //...
if (eyes == 'r') { }
// or...
String eyes = //...
if ("red".equals(eyes)) { }
[url= http://java.sun.com/docs/books/tutorial/java/index.html]The Java?Tutorial - Trail: Learning the Java Language[/url]
A char represents one character, so how could a char ever equals "eyes" - a String literal ?
If its true, as your name implies, that you have a perl background, you will get killed with various operator issues at first.
Biggest killer is == operator.
Unless you are dealing with primitives (char,int,boolean,etc) or want to compare object references for equality (not equivalence), then use the equals method.
public class Eyes {
public static void main(String[] args) throws Exception {
java.util.Scanner s = new java.util.Scanner(System.in);
String line = s.nextLine();
if (line.equals("eyes")) {
System.out.println("you are right");
} else {
System.out.println("you are wrong");
}
}
}
Yes, I'm quite famalir with Perl and actually teach classes on it.
Java is quite a bit different so far :)
Sorry guys, I forgot char was just 1 character. I thought it was that var type that allowed tons of stuff in it (can't think of the name now). I'll use line.equals for now and see how that works.
I'm actually quite interested in playing around with regexes in later chapters.
Thanks for your help!
Okay, after doing some test compiles I'm not getting it to work. Your code (the headers) I have't seen in the book yet so I didn't add them, and now I am having troubles getting my string eyes to read from System.in.read.
As you can see, I tried a variety of things. Any pointers?
class ThisIsATest
{
public static void main(String args[])
throws java.io.IOException
{
String dollar;
String eyes;
System.out.println("Hello");
System.out.println("Pick a dollar amount (without $)");
dollar = (String) System.in.read();
System.out.println("\n\nI would pay" + dollar);
System.out.println("\nWhat color are your eyes?");
eyes = s.nextLine();
if (eyes.equals("red"))
{
System.out.println("You are right!");
}
else
{
System.out.println("Wrong!");
}
}
}
You cannot cast a char to a String as you try here:dollar = (String) System.in.read();Thats why I used the Scanner class. System.in is a raw InputStream (bytes). http://java.sun.com/docs/books/tutorial/essential/io/index.html
In all sincerity, I'd recommend learning the distinction between basic data types before jumping into IO.~
Thanks for yor help everyone. For now, I think I'll put this little snippet on hold while I read more of this book.
One thing I thought about while typing in all the lengthy System.out.println lines is attempting to create a print() subroutine or equiv. later on so I wouldn't have to type all it out.
Not sure if it's possible yet or what issues could arrise in complex printing, but it'll be a fun experiment when it's time :)
> Not sure if it's possible yet...Trivial, even. :o)void print(String msg) { System.out.println(msg); }
Just wait until you get to the fun of setting the output dynamically at runtime... :o)
Darn you, now I gotta think of something else to experiment with later. LOL. Maybe something a little more complicated, eh? Maybe allowing comma separaters in for ( int x = 0, x < 10, x++ )
instead of using semicolons.
Yeah, this bugs me a bit to not use commas there :)
Instead of the print() routine, I would focus on Yawmark's suggestion for now. Your print() is 'pseudo-encapsulation'. You should not create new classes, methods, whatever, just to save on typing. You will type less, but your program will be less maintainable. The reader who knows perfectly well what System.out.println does, will have to dig, your code's complexity increases. And, on top of it, you re-invent the wheel. I think you can save the "System." portion using static imports offered by the language itself (not a topic I would worry about right now).
> Darn you, now I gotta think of something else to
> experiment with later. LOL. Maybe something a little
> more complicated, eh? Maybe allowing comma
> separaters in for ( int x = 0, x < 10, x++
> )
instead of using semicolons.
>
> Yeah, this bugs me a bit to not use commas there :)
Unless you create a compiler that is not to spec you're stuck with it. Commas have a completely different use.
for (int i = 0, n = list.size(); i < n; i++) {
}
As a simple example.
and then there's the little problem of using == to compare object references when you're trying to compare the contents of the actual objects.
tryimport static java.lang.System.out;at the very top of your program, andout.println("hi!");to print something
> try
>
> > import static java.lang.System.out;
>
at the very top of your program, and
>
>
>
> > out.println("hi!");
>
to print something
:yuck: Please don't.
mlka at 2007-7-21 0:04:13 >
> and then there's the little problem of using == to
> compare object references when you're trying to
> compare the contents of the actual objects.
Maybe they can 'fix' that seeing as their goal here seems to be more about changing the syntax of Java than it is programming in Java. At least we got past the whole "comparing a char to a String" thing, I hope.
I don't really want to change the syntax of Java or anything, it's just interesting to see what kind of hacks could be used to get around certain things.
On another note not related to the topic at hand- after running a few endless loops, I couldn't believe how much faster Java was than Perl. I always thought Perl was blazing fast, but Java just blew my mind away as it iterated over hundreds of thousands of print statements.
> On another note not related to the topic at hand- after running a few
> endless loops, I couldn't believe how much faster Java was than
> Perl. I always thought Perl was blazing fast, but Java just blew my
> mind away as it iterated over hundreds of thousands of print statements.
You ain't seen nothing yet. Wait 'till you see the HotSpot system at work
and its worker the JIT compiler; after a bit of latency at start-up you'll get
raw bare metal machine speed.
kind regards,
Jos
> try> > > import static java.lang.System.out;> at the very top of your program, IMAO, static imports are as evil as autoboxing.
> IMAO, static imports are as evil as autoboxing.
They're not just evil, they're the Beelzebug (no typo) of Java programming.
Java should've had no notion of 'primitves' from the ground up to make
this stuff works. It hadn't so there's no need to hide those primitives.
We all remember Peter's ABFH (Auto Boxing From Hell) example ... ;-)
kind regards,
Jos
> We all remember Peter's ABFH (Auto Boxing From Hell)> example ... ;-)1 != 1, or 1 == 0 or somesuch?
> 1 != 1, or 1 == 0 or somesuch?That was my Rubber Chicken.
why exactly don't you guys like static import?
> why exactly don't you guys like static import?They smell of bugs.Plus I'm sure even Sun recomend you don't use static imports the way shown above.But then I do not see a time when you would use them.
mlka at 2007-7-21 0:04:13 >
> But then I do not see a time when you would use them.
They have their uses. I mostly use them with enumerations in annotations. For example:
@Basic(fetch=EAGER)
public String getNote() {
return note;
}
I prefer that use of the annotation to this:
@Basic(fetch=FetchType.EAGER)
For much the same reason that I don't use this:
@javax.persistence.Basic(fetch=javax.persistence.FetchType.EAGER)
(edit) I think the other canonical use of them is to import static math functions. It makes the code considerably easier to read. It's syntactic sugar of course, but so are ordinary imports - and I think it's justifiable in both cases.
