There are only two boolean values: true and false. These can be compared for equality or inequality just like anything else. So, for example, two boolean values are equal if both are true or both are false. We use logical operators to do the comparison. Of course, the boolean values we are comparing may come from evaluating relational expressions, logical expressions or boolean variables.
"=" is the assignment operator, while "==" is used to compare the value of two variables or expressions.
Well, I hope you've figured this out for yourself now that you've done "TheSame" activity in lab 4!
"==" compares the values of (references in) the String variables, not the CONTENTS of the String objects themselves. To do the latter, we must use the String class's equals method. For example (See code/StringEquality.java> if we have declared five String objects, such as
String string1 = new String( "Hello there!" );then
String string2 = "Hello there!";
String string3 = string2;
String string4 = "Hello!";
String string5 = "Hello!";
string1 == string2;would be evaluated as false as the variables refer to two DIFFERENT String objects that just both happen to "say": "Hello there!". But,
string2 == string3;would be evaluated as true as the variables refer to the same String object. And,
string2.equals(string1);would both be evaluated as true as the CONTENTS of each String objects referenced is the same. However,
string2.equals(string3);
string2.equals(string4);would be evaluated as false as the CONTENTS of the two String objects referenced is different.
NOTE: Here's a kind of special case:
string4 == string5;would be evaluated as true as the variables refer to the same String object. Why? Because in this case the compiler sets up ONE String object (a String literal) that is used each in both of the instantiations.
The only way to request information from an existing object is to use its methods! Typically, an object will have a set of accessor methods that will be used to access information about its state. For example, a String object has an accessor method called length() that returns information about the length of the String object which is part of its state!
Check the javadoc pages for the class! If the method requires any parameters, the javadoc pages will show that and will also tell you what type each parameter needs to be and in what order the parameters need to be provided. AND, if the person who wrote the class was careful, by clicking on the method name in the Method Summary, you are likely to find out more useful information about the parameters as well as about the method itself!
Yes, we can compare Strings containing characters such as "@#$" lexicographically to any other String. Comparing in this sense means looking at the ordering of the individual characters that make up the String with the corresponding individual characters in the other String, much like we sort words alphabetically. But lexicographically means that rather than sorting alphabetically, we're sorting according to the character order within the unicode character set, which is much more extensive than the simple alphabet. Furthermore, all (ascii) capital letters in unicode are less than (ascii) lower case letters. For example, "Hat" is less than "cat" lexicographically (but "cat" is less than "Hat" alphabetically)!
Well, it depends on the character. If the character is '\t', you get a "Tab"; a '\n' you get a new line, and so on. (Sometimes though for non-ascii characters, what you get is dependent upon the device you are using.)
Sorry - your question is muddy to me! :-) I really don't understand what you are asking. If your "question" refers to the difference between the String and StringBuffer classes and when the contents an object of these types might have be changed in the invoking method upon returning from another method, then a contributing factor in the answer is that a String object in Java is immutable and its contents cannot be changed. So, if a method (apparantly) changes the contents of the String object that its formal parameter refers to, the parameter itself always gets a NEW reference to a NEW object within the method. (Remember parameters only have memory allocated to it as long as the method is executing.) Thus, when the method is finished executing, the variable (actual parameter) in the invoking method still refers to the original String and is unchanged.
However, in the case of our StringBuffer example, the method StringBuffere method reverse() changed the contents of the StringBuffer object itself (i.e., the reference, in the parameter itself, doesn't get changed). This means that we see the "side-effect" of this change in the invoking program. The CONTENTS of the object that the actual parameter referred to reflects the change.
Take a look at ObjectPassing.java and its output, for an example of this behavior. To see what happens if the parameters are primitives, see PrimitivePassing.java and its output. (If you'd like to download and run them, hold the shift key down while you left click!)
User bob;Given the following declarations and instantiations above I was wondering if the following code would be valid:
Account bobChecking;
bob = new User();
bobChecking = new Account();
bob = bobCheckingI know it doesn't really make sense to do but I was just wondering if the reference would change or if wouldn't work since they are different types of objects. ie. one's a User and one is a Account object. I believe in class we have only changed objects of the same class.
Good question - oh, for more time in class! The assignment would be invalid unless "Account" was a subclass of "User" (or, when you become a more sophisticated Java programmer, to variables of an interface type that the object implements).
How do you write a boolean expression and save it in a variable?
You know that boolean is one of the primitive types, so you can simply declare a variable to be of that type. For example,
boolean test;
A boolean variable then can be assigned the results of any expression that evaluates to be true or false. So, it could be as simple as
test = true;
or complicated
test = a > b || c < d && q == r;
I've written a little piece of code code/Bitwise.java to show you. Download it, compile it and execute it.
& and | are bitwise operators. They take integral arguments (eg., ints), which include booleans. & does a bit by bit "and" of the the does a bit by bit "and" of the two operands. The result has 1's in the positions where BOTH operands have ones and 0's elsewhere. (This is somewhat like &&,whose result is true if and only if both of its boolean operands are true).
| does a bit by bit comparison as well, but the result has a 1 where EITHER operand has a 1 and is 0 where both operands have a 0. (This is somewhat like ||, whose result is true if either of its boolean operands us true.)
And, if you write and expression such as true & false, Java would still do a bitwise operation and evaluate it to false.
A BIG difference between "&&" and "&" ( and "||" and "|") is that "&&" and "||" are short circuited operations whereas "&" and "|" are not. This means that not all of the expression involved may need to be evaluated. Thus, if the left operand of the "&&" is known to be false, Java knows the evaluation of the right operand is NOT necessary as the expression cannot possible be true. And, if the left operand the "||" is known to be true, Java knows the evaluation of the right operand is NOT necessary as the expression will always be true. For "|" and '&" no such short cut is possible as the resulting information isn't always boolean.
The '^' operator is the "exclusive or" operator. The way it works depends on the type of its operands. If operands P and Q are boolean, P ^ Q will be true if and only if EITHER P or Q is true. This means if both are true, P ^ Q is false!
If, however, P and Q are integers, than a bitwise comparison is done between the contents of P and Q. This means that a bit in the results of the operation is 1 if and only if there is a 1 in only ONE of the two bits being compared, and 0 otherwise. For example, if P is 8 (000...1000) and Q is 10 (000...1010)
int result = P ^ Qthe contents of result would be 2 (000...0010).
Well, I don't see a question here, but let me say this. You'll find it a lot less frustrating once you learn how to read the javadoc documentation. Besides providing a list of methods, it provides links to DETAILS about those methods. It kind of sounds like this is what you didn't remember/find. Try clicking on the substring method's link. You'd be surprised at how much helpful info is awaiting you!
Yes, I do see your comments. The only thing that ignores it is the Java compiler/interpreter. When it sees comments, it doesn't even try to translate them into byte code that can be executing.
The comments are put in for human readers like you and me to clarify for us what's supposed to be going on in the code. So, if you've used // only to make code inactive, it is LIKELY to be a good idea to remove it BEFORE you "try" it.
public int indexOf( int ch )When I tried to use this method, the int in the parenthesis was a problem. I created an int and used the method like this:
int space1 = name.indexOf( int ' ');But, I got an error. But when I actually use parenthesis around the int inside the parenthesis like this:
int space1 = name.indexOf( (int) ' ');It worked. Why?
Remember that the javadoc tells you HOW to use a method. It indicates the TYPE of arguments that are needed by the method for the method to do its work.
The int ch in the javadoc tells you that this version of the indexOf method expects an int argument to be passed to it. It means you should pass it an argument that is an int, or one that will be automatically promoted to an int (char, byte, short). It does NOT mean, for example, to pass it by saying int ' '.
If you called it by saying int space1 = name.indexOf( ' ' ), you woule have passed it ' ' which would have promoted automatically to an int. Then the method would have executed just fine.
Passing the indexOf method (int) ' ' on the otherhand tells Java that you want the ' ' to be interpreted as an int not a char.This works fine, but is not strickly necessary!
Yes, you are right it will get easier as you go along, i.e., gain experience. It is tricky to find the right balance of comments, not too many, not too few. Our culture does dictate some sets of comments that you must use. Beyond that comments should be used to clarify and enhance (people) readability of the code.
It is REALLY important that you get used to fitting into the culture where ever it is that you are working. You'll find that each organization will have its own culture (things like coding standards) that must be followed, and the sooner you buy into and learn to look out for what that culture is, the easier it will be.
For most of the coding that will be turned in for lab, there will already be one or more @author filled in, you will simply add another for yourself for those pieces of code that you have modified.