Serdar Ozturk

I've just passed it today.
Thanks very much to everybody here sharing their knowledge and experience; also
special thanks to people making effort on mock exams; Dan, Marcus, Valentine, Jiris.com...
Dan's topic exams are really useful, you should go over all of them.
As a suggestion, following topics should be known deeply
- threads,object locking
- assert usage
- wrapper classes
- garbage collection
I think, since awt and io topics have been removed, they've gone deeper on other topics. Thanks everybody..
Serdar

Provate methods are not visible to the subclass, so it cannot override them. If you define any private method of the superclass with the same signature then it becomes a completely new method (not overridden)
To prove this, you can try illegal implementation of overriding.
Eg;
class C{
int getIt(){ return 0;}
}
class D extends C{
void getIt(){} // COMPILER ERROR (different method signature)
}

but the following code compiles fine
class C{
private int getIt(){ return 0;}
}
class D extends C{
void getIt(){} //OK
}
Serdar

Originally posted by Nidhi:
Hi folks!!preparing for SCJP...i am unclear about the case when private methods are overridden in the subclass then which method is called that of the base class or the derived class....read somewhere that private methods are statically bound i.e. no matter the derived class defines the method with same signature as private method in base class the method will call the private method in the class where it is defined..... My answers don't tally with this rule.

well, long is 64-bit wide and there is no loss of precision when you convert it to float first and then to double... on line 1
On line 2, we convert 32-bit integer to float and then to double and we loss some precision.
Why dont we loss any precision on 64-bit long variable but on 32-bit integer?
Serdar

The following code prints:
true
false
9.223372036854776E18 9.223372036854776E18
2.147483647E9 2.147483648E9
System.out.println( (double) Long.MAX_VALUE == (float) Long.MAX_VALUE ); // 1
System.out.println( (double) Integer.MAX_VALUE == (float) Integer.MAX_VALUE); // 2

System.out.println( (double) Long.MAX_VALUE +" " + (double)(float) Long.MAX_VALUE );
System.out.println( (double) Integer.MAX_VALUE +" "+ (double)(float) Integer.MAX_VALUE);

What's happening on line 2?
SerdaR

re-write the line as
i = (++k) + (k++) + (+k);
evaluation left to right:
i = 2 + (k++) + (+k) (k is incremented and assigned the value 2)
i = 2 + 2 + (+k) ( k's current value used, but with a side effect of incrementing k)
i = 2 + 2 + 3
i = 7;

Serdar

Originally posted by Saniya Ansari:
ok there is this question in Mughal's book.. i'm kinda confused although it seems easy..
public static void main(String args[]){
int k= 1;
int i= ++K + k++ + + k
System. out. prinln(i);
}
The answer is 7.. i'm not sure how.. HELP!

Well, I think it should be clear for everyone now,but the following may be another short-hand way of thinking.
Byte.MIN = 80
Byte.MAX = 7F
Short.MIN = 8000
Short.MAX = 7FFF
While converting those numbers (in fact, we can use this rule for any number )to a wider integral type(int or long),
for negative numbers: Add F's to the left
for positive numbers: Add 0's to the left
So,
byte -128: 80 --> FFFFFF80
short -32768: 8000 --> FFFF8000
7F --> 0000007F
7FFFF --> 00007FFF

PS: For negative numbers, remember that >> operator inserts "1" into the leftmost digit to keep the number negative and to allow division and multiplication by 2.
Serdar

Sorry, I've made a small mistake there,
Short.MIN = -2^15
and it's 1000 0000 0000 0000 = 0x7000
should be corrected as = 0x8000
Serdar

When you write System.out.print(Integer.toHexString(Short.MIN_VALUE), short value is first converted to int
Short.MIN = -2^15
and it's 1000 0000 0000 0000 = 0x7000
, be careful that when you convert this negative short value to int it's gonna be a different bit sequence
2's compliment calculation of -2^15
+2^15 = 0000 0000 0000 0000 1000 0000 0000 0000
take inverse of each bit
1111 1111 1111 1111 0111 1111 1111 1111
Add 1
1111 1111 1111 1111 1000 0000 0000 0000
0xFFFF8000

For maximum values there is no problem
Short.MAX_VALUE = 0111 1111 1111 1111
= 0x7FFF
when you convert it to int
0000 0000 0000 0000 0111 1111 1111 1111
0x00007FFFF
but the methos toHexString does not print the first four zeros, so the result is 7FFF
Serdar

Here is a list of some common Runtime exceptions
ArithmeticException
ClassCastException
IllegalArgumentException IllegalMonitorStateException IllegalStateException
IndexOutOfBoundsException NegativeArraySizeException
NoSuchElementException
NullPointerException
SecurityException
UnsupportedOperationException
For a complete listing, check the API.
Serdar

I dont know is there a short way of doing it, but this is the way I do generally.
Write the number in binary format, write each 4 binary digit as a separate group.
MIN : 1000 0000 0000 0000 0000 0000 0000 0000
Now count decimal values for each group
8 0 0 0 0 0 0 0
Convert decimals to HEX
80000000
MAX : 0111 1111 1111 1111 1111 1111 1111 1111
7 15 15 15 15 15 15 15
7FFFFFFF
Serdar

Thanks Dan, first I took a copy of the exam on my harddisk and then I worked on it, that's way I posted the message after you corrected without knowing it had been corrected...
Serdar

Hi
I was just looking at Dan's new beta version Thread topic exam and the 14th question is about yield() and Dan says
"The Thread.yield method might allow a lower priority thread to run." is not TRUE.
Isnt it a matter of the operating system to decide which thread to run? I have Simon Roberts' latest book and it mentions with a single sentence "Note that most schedulers do not stop the yielding thread from running in favor of a thread of lower priority." (page 230) He is not saying "All schedulers" but "most of them".
So, the above statement, should it be TRUE or FALSE?
Serdar
PS: Dan, you are really doing great job, thanks very much for your topic exams, they are really useful.

InnerInner is an inner class inside Outer, so it can reach all fields of Outer; since it's a subclass of Inner, it can reach all non-private fields of Inner. So, I think there is no priority of being an inner class or subclass.
Well, in my opinion it's a tough question for Java compiler designers as well, this is the best way of doing it I think, just give an error and leave the decision to the programmer.
Serdar

Q2: GC can possibly move objects around in memory from time to time. Would that not make map id unreliable?
Barkat
----------------
Hi
I think most of the JVM implementations use double reference scheme to refer an object in memory. So there is one more hidden reference between our object reference and the object itself, and JVM can freely move the object in the memory and update the hidden reference; this way it keeps our object reference unchanged..
Serdar