Prakash Yamuna

Greenhorn
+ Follow
since Sep 30, 2001
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
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Prakash Yamuna

Upcast and downcast need to be allowed. For example consider a Vector..
Vector v = new Vector();
Button b = new Button();
String s = new Strign();
v.add(b);
v.add(s)
v.get(1)- returns me a an Object whose runtime type is String. I can always treat a java.lang.String object as a java.lang.Object object.
Object o = v.get(1);
String s = (String) o;
This goes through fine since at runtime the type of o is String.
Similar is the case in your example however:
o = v.get(o); //at run time returns a Button object
String str = (String) o; throws an exception since at runtime it is of type Button.
As to why it is allowed at compile time, it is got to do with support for dynamic binding, if dynamic binding is not supported then we couldn't have Vector which can hold any type of object. So in order to support dynamic binding the kind of example provided above is allowed, but since it may result in improper usage the ClassCastException is defined to flag such errors.
Hope this helps.
As far as my knowledge goes all Collection objects support the addition of a single null object.
--------------------------------------------------------------------------------
The anwsers are A,B for the following reason.
1. The string literal "john" is interned and a single instance is maintained so the expression
"john" == "john" both refer to the same object and hence it returns true.
2. I will skip this since it is obvious
3. The third statement won't compile. You can't assign a value to a String literal
4. In the fourth case you are comparing a String object with a Button object and hence will return false.
Actually the reason it returns false is the way the equals method is usually coded. (This is a recommended practice if you are provide your own equals method for a class)
Ex:
... class String {
public boolean equals(Object o) {
if ( o == null ) {
return false;
} else if ( !(o instanceof String)) {
return false;
} else {
// do the actual value comparison
}
}
Take a look at java.lang.String to get a better idea...

16 years ago
I agree with Nain Hwu. The "transient" keyword is applicable for serialization java serialization not if it is externizable. Since if a class implements the Serializable interface, the class doesn't have control over the actual serialization process, "transient" provides you a bit of control in how the java serialization algorithm works.
Basically as Nain mentioned, it boils down to the amount of control you want on the serialization process.
1. Use java serialization (thru implements Serializable) if you are ok with the default behavior.
2. Use transient variables if default serialization is good enough but there are things that just don't make sense serializing.
3. Provide your own hooks for serializing an object by implementing the Externalizable interface.
4. If java serialization is just too slow then use your own algorithm and define interfaces similar to Externizable ( this can get to be very tricky). One scenario is if you want to serialize objects in XML, or say you have proprietary formats,etc. Kind of acts as poor man's persistence layer. Note that performance gains occur usually because you don't need as generic a serialization algorithm as provided by java.
16 years ago
Its not clear as to what is meant by an object is ready to be GC'ed. Are you saying it is in one of the two states:
1. Unreachable and unfinalized
2. Unreachable and finalized
An object can be GC'ed only if it is unreachable. So when you say an object is ready to be GC'ed I assume you are saying it is unreachable.
If that is the case then the finalize() method will always be called unless the JVM crashes.
From my understanding an object that is unreachable will be GC'ed eventually. While there ia no guarantee on the time period, there is a guarantee of such a service by the JVM unless it crashes.

Prakash
16 years ago