Anil Hulikal

Greenhorn
+ Follow
since Apr 02, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Anil Hulikal

Sandya,

Experience is NOT required to TAKE the exam. You don't have to provide any experience letter or anything, if that is where you are going with this...

Regards,
Anil
Saritha,

Please go through this article. It discusses in detail about string comparison.

WHEN ARE TWO STRINGS EQUAL?

Regards,
Anil
Include the loop in {}

Corey,

How about the good ol' immutability of Strings? :-) This topic seems to draw too much attention in the forum. When we are at it, why not try and make some fundamentals simpler?

In my humble opinion, the explanation about "strings" (a.k.a string literals) and "String" (objects) can be further simplified in most books if we could make a comparison at a very coarse level with primitives and wrapper classes. There are key concepts that we, the readers (the truth seekers), somehow miss out while trying to understand strings, String and the heap (and the "hazy" stack).

1. A string literal is simply a "string" of characters. In other words it is just a 'character string': Not an object. It has no state or behavior. No methods are available to manipulate a string of characters directly. Having said that, it also has to be made clear that JVM/platform accepts any string of characters when it requires a String Object. That is when a "string" gets converted into a "String" thereby facilitating the use of methods (for example, concatenation) available in the String class.
2. A String is an Object. It has a state and behavior

Now, if we ignore the storage mechanism, for a moment or forever, doesn't String class just look like a wrapper class for "string literals"? Can something on these lines be explained. I do not intend to make a vis-a-vis comparison with other primitives and their corresponding wrapper classes. But, why not call java.lang.String as a "special" type of wrapper class for "a string of characters"?

Thanks and regards,
Anil
1 byte = 8 bits

The relationship between the number of bits and how many binary values can be had using them is

87654321

2^82^72^62^52^42^32^22^1

What this means is, using 1 bit you can have 2^1 = 2 values. In other words, if there was only one bit to represent your data, you can only have one of the two values: Either a one, or a zero. If you had two bits, you would have 2^2 = 4 possible combinations to represent the data, and those would be: 00, 01, 10, 11 (0,1,2 and 3 in decimal). Likewise, using 8 bits you would have 2 ^ 8 possible combinations 00000000 through 11111111 (0 through 255 decimal). Now, if you were to represent negative numbers also using the same number of bits how would you do it? It's easy. Use the MSB (most significant bit, or the left most bit) as a sign bit. If we did that, we are left with 2^7 (128) possible combinations, and that includes a zero. So, now, based on the value of MSB, you identify whether it is a positive number or a negative one

MSB Lower bitsDecimal
0 0000000 0
01111111127
10000000-128
11111111-1

In general, we can say that with "n" number of bits, the integer values range from [-2^(n-1)] to [(2^(n-1)) - 1]
[ June 28, 2004: Message edited by: Anil Hulikal ]
I think your return statement in the finally block is playing a role here. Please try replacing that with a print statement (System.out.println ("peace")). Khalid and Rasmussen's book has the following explanation on the use of transfer statements in finally block:

***
If the finally block executes a control transfer statement such as, a return or a labeled break, then this control transfer statement determines how the execution will proceed�regardless of how the try block or any catch block were executed. In particular, a value returned by a return statement in the finally block will supersede any value returned by a return statement in the try block or a catch block.
***

I wonder if this example is set to demonstrate this point.

Nevertheless, got stumped
JLS 15.20.2 Type Comparison Operator instanceof

The type of a RelationalExpression operand of the instanceof operator must be a reference type or the null type; otherwise, a compile-time error occurs. The ReferenceType mentioned after the instanceof operator must denote a reference type; otherwise, a compile-time error occurs.
At run time, the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast (�15.16) to the ReferenceType without raising a ClassCastException. Otherwise the result is false.

If a cast of the RelationalExpression to the ReferenceType would be rejected as a compile-time error, then the instanceof relational expression likewise produces a compile-time error. In such a situation, the result of the instanceof expression could never be true.

Consider the example program:



This example results in two compile-time errors. The cast (Point)e is incorrect because no instance of Element or any of its possible subclasses (none are shown here) could possibly be an instance of any subclass of Point. The instanceof expression is incorrect for exactly the same reason. If, on the other hand, the class Point were a subclass of Element (an admittedly strange notion in this example):

class Point extends Element { int x, y; }

then the cast would be possible, though it would require a run-time check, and the instanceof expression would then be sensible and valid. The cast (Point)e would never raise an exception because it would not be executed if the value of e could not correctly be cast to type Point.
I received this in the latest newsletter from SUN. Thought it might interest some of you....

URL => http://java.sun.com/developer/JDCTechTips/2004/tt0504.html#2


WHEN ARE TWO STRINGS EQUAL?
Strings are treated differently by Java developers than other first class objects. You can initialize a new String using new:

String string = new String("hello"); //not recommended

You can also use the following syntax to accomplish almost the same thing:

String string = "hello";

This tip addresses the question "when are two Strings equal?" Because they are objects, you can always compare the values of two Strings using the equals() method. If s1 and s2 are two Strings with the same value, then s1.equals(s2) is true. The tricky part comes when you try to use == to compare s1 and s2. In this tip you will see when s1 == s2 should return true.

To start with, create two objects of type Double, two primitives of type double, and two objects of type String. Use the s1 = "hello" syntax for initializing the Strings.



When your run Equals, you get the following results:

For Double objects both 7.2
object1 == object2 is false
object1.equals(object2) is true
For double primitives both 7.2
prim1 == prim2 is true
For Strings both 7.2
string1 == string2 is true
string1.equals(string2) is true

As you would expect, object1.equals(object2) is true because they have the same value but object1 == object2 is false because they are different objects. Also, prim1 == prim2 is true because they have the same value (note that you cannot use equals() to compare two primitives). For the objects string1 and string 2, string1.equals(string2) is true because their values are the same. Perhaps it is a surprise that string1 == string2 is true. The Java Language Specification explains that "Literal strings within the same class in the same package represent references to the same String object."

The Language Specification explains that "String literals - or, more generally, strings that are the values of constant expressions - are 'interned' so as to share unique instances using the method String.intern."

On the surface, the next example seems to highlight the differences between initializing a String as you would initialize an object, and initializing a String as you would initialize a primitive. It actually demonstrates the difference between obtaining a String by using a String literal directly, and by calling a String constructor.



Run NewEquals, and you will see these results:

For new Strings s1 and s2
s1 == s2 is false
s1.equals(s2) is true
For Strings s1 and s3
s1 == s3 is false
s1.equals(s3) is true

All three Strings are created with the same value, so equals() returns true for both comparisons. However, s1 and s2 are different objects. Despite being constructed with the same value, they are as different as the two Double objects were in the first example. This is why s1 == s2 is false. Similarly, s1 == s3 is also false.

You probably wouldn't be surprised by this result if it were not for the first example (Equals) where the two Strings returned true when compared with the == operator. It seems that these objects have the behavior expected of objects. The Equals example showed you that there is a pool for Strings. Multiple String variables can refer to the same String object. If they are set to equal string literals, they are guaranteed to do so.

The Language Specification guarantees that calling new will create a new object. That object has never been passed to String.intern. However, the value of a String literal is a String that has been passed String.intern, so it is different. The Language Specification does say that you can force a String into the common String pool using the intern() method, as shown in the following example:



Here are the results of running NewInternString:

For new Strings s1 and s2
s1 == s2 is false
s1.equals(s2) is true
For Strings s1 and s3
s1 == s3 is true
s1.equals(s3) is true

You can see that again the values are being reported as equal. That's because the equals() method returns true in both cases. After you force s1 into the constants pool you find that s1 == s3 is true. However, s2 is still not in the constants pool, so s1 == s2 is false.

In this tip you saw that the only safe way to test that Strings have the same value is with the equals() method. If you work with Strings that have the same value, then it might be worth interning them into the constants pool. That way you can make a quicker check using the == operator. In any case, you can see that you have to be careful before deciding to use == to check equivalence.

For more information on String comparisons see section 9.2 "String Comparisons" in The Java Programming Language Third Edition by Arnold, Gosling, and Holmes.

Well, as I emphasized, they are true from compilation perspective: In other words, they don't give compilation errors. This does not mean that run time results would be boolean "true".

Please try compiling and running the following code as-is, and then try again with "//" removed for the print statements one at a time.


The following specs from the sections 15.21.3 and 5.5 of JLS may be pertinent here


|
A compile-time error occurs if it is impossible to convert the type of either operand to the type of the other by a casting conversion (�5.5).
|




|
The detailed rules for compile-time correctness checking of a casting conversion of a value of compile-time reference type S (source) to a compile-time reference type T (target) are as follows:
If S is a class type:
If T is a class type, then S and T must be related classes-that is, S and T must be the same class, or S a subclass of T, or T a subclass of S; otherwise a compile-time error occurs.
|




Regards,
Anil
I think within the context of this question, a thread of execution has not begun; only a Thread object has been created. This object may very well have a field value of priority = 5. However, the wording of the given option is �The thread myThread has priority is 5�. Probably by �thread�, they are referring to a thread of execution. So, since the �thread of execution� has not begun yet, without a call to the start method, it would be inappropriate to say that it has a priority of 5.

Regards,
Anil
From the compilation point of view, first three are "incomparable", and the last equals call has int as the parameter when it requires an (Object obj).

So, options 4 and 5 are true, from the compilation perspective.

Regards,
Anil
I do not think it is a good idea to snub anyone, however simple and trivial the question, that the person is asking, might appear on the surface. Perhaps, this is the reason why we have more programmers than software engineers today!. I encourage you to read this interview.

http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html
This should print 10020.

1. In "amethod" first a method local variable i is set to 99
2. A new ValHold object v is created with a field value for i = 10. This field value is changed to 30 in the next statement.
3. You then call the "another" method, by passing a reference to the v object and the value of i (99). Note that v.i at this time will still be 30.
4. In "another" method you set the method local i = 0, and v.i = 20.
5. Then create a new ValHold object vh with vh.i = 10
6. Change the object reference v to point to vh (locally). So, before the last two print statements, both v and vh will be referring (locally) to the new object you just created above with a field value of i being 10. However, the original object v that was created in "amethod" still out there in the call stack.
7. When you print v.i, as expected, prints 10
8. When you print i, prints the value of local i, i.e., 0
9. Next, the execution resumes in "amethod" (with the print statement).
10. Since you had modified the field value of v.i in another method, it prints 20.

From Khalid and Rolf's book


3.18 Passing Primitive Data Values
When the actual parameter is a variable of a primitive data type, the value of the variable is copied to the formal parameter at method invocation. Since formal parameters are local to the method, any changes made to the formal parameter will not be reflected in the actual parameter after the call completes.
|
3.19 Passing Object Reference Values
If an actual parameter is a reference to an object, then the reference value is passed. This means that both the actual parameter and the formal parameter are aliases to the object denoted by this reference value during the invocation of the method. In particular, this implies that changes made to the object via the formal parameter will be apparent after the call returns. The actual parameter expression must evaluate to an object reference before the reference value can be passed.
|



Regards,
Anil
Khalid Mughal and Rolf Rasmussen's book has this explanation in section 9.5. (It would be much easier to follow with the state diagram they have given in the book).


Ready-to-run state
A thread starts life in the Ready-to-run state (see p. 369).
Running state
If a thread is in the Running state, it means that the thread is currently executing (see p. 369).
Dead state
Once in this state, the thread cannot ever run again (see p. 380).
Non-runnable states
A running thread can transit to one of the non-runnable states, depending on the circumstances. A thread remains in a non-runnable state until a special transition occurs. A thread does not go directly to the Running state from a non-runnable state, but transits first to the Ready-to-run state.
The non-runnable states can be characterized as follows:
1. Sleeping: The thread sleeps for a specified amount of time (see p. 370).
2. Blocked for I/O: The thread waits for a blocking operation to complete (see p. 380).
3. Blocked for join completion: The thread awaits completion of another thread (see p. 377).
4. Waiting for notification: The thread awaits notification from another thread (see p. 370).
5. Blocked for lock acquisition: The thread waits to acquire the lock of an object (see p. 359)



Basically, once a thread (of execution) is started with start(), it won't start "running" immediately, instead it enters into "ready to run state" to be picked up by the scheduler.

Regards,
Anil
I think Richard is right. Please try this snippet. Notice where the cursor moves at the end of execution. If you can execute it step-by-step in an IDE, you can actually see the cursor move backwards :-)

System.out.print("ABC");
System.out.print("\u0008");