I understand the purpose of making the clone and finalize method as protected, I wanted to understand why hashcode() and equals method are not declared as protected
Because you want to call hashcode and equals methods from the outside of that given class.
protected allows access only from the same package and extending classes.
You "understand the purpose of making the clone and finalize method as protected". But what is the purpose actually?
Calling Object.clone will throw an exception if the method isn't overridden and if Cloneable isn't implemented. Thus this method isn't ready to use.
Object.finalize is according to JavaDoc "called by the garbage collector". Thus it is for internal usage only.
In contrast to these both methods are Object.equals and Object.hashCode ready to use and not for internal usage.
The JavaDoc of Object.hashCode says:
This method is supported for the benefit of hash tables such as those
provided by HashMap.
Thus it is intended to be used by other objects. If hashCode wouldn't be declared public this functionality would be limited usable.
Object.equals is a symmetric method. If Object.equals wouldn't be declared public, suppose we have a local variable b of a type from another package and whose equals method isn't visible to this. We want to ckeck if b and this are equal. We couldn't call b != null && b.equals(this) but we could still call this.equals(b). Does it makes sense to limit a symmetric method to be callable by one of both objects only?
See also Comparable.
Related
I would like to know the name of the class to which finalize() belong. To add a finalizer to a class, we will have to define the finalize() method. The JVM calls that that method whenever it is about to recycle an object of that class & should be protected always.
finalize method belongs Object class.
The (no-op) finalize() method is declared in Object.
However, if you want a finalizer to actually do something, you have to override Object.finalize() method in the class that needs finalization.
Hence the real finalize() method (i.e. the one than does something) belongs to the class that needs to be finalized.
Strictly speaking, your classes finalize() method does not have to be protected. It could be public. However, that would be a crazy thing to do, since it makes the finalize() method part of the public API, and invites unrelated code to call it. That's something that you shouldn't need to happen.
I'm reading J. Bloch's effective Java and now I'm at the clone method. He mentioned that no constructors were called. But I didn't find it in the javadoc. The second thing is that:
The provision that
“no constructors are called” is too strong. A well-behaved clone
method can call constructors to create objects internal to the clone
under construction. If the class is final, clone can even return an
object created by a constructor.
It seems a little contradictory to me. While he was mentioning that no constructors are called, he said that well-behaved clone can call constructors.
Couldn't you explain what he meant?
There are two different things:
Your own implementation of clone() method in your own class which should follow some rules.
An implementation of existing Object.clone() method.
I believe, when J. Bloch speaks about "no constructors were called", he assumes the behavior of existing Object.clone() method. But the quotation you cite is about your own implementation of clone() method which in some cases can construct new objects using constructor or even return such object.
Classes implementing Cloneable interface can call clone() method from Object class without having CloneNotSupportedException. The signature of the clone() in Object class tells why constructors are not called if you call the inherited clone. It is native code, not pure Java.
protected native Object clone() throws CloneNotSupportedException;
And note that, this is just a shallow copy implementation.
I know this question has been asked so many times.
First of all Object.clone() method in java is native method i.e. it is implemented in JVM and user doesn't need to know about it's implementation.
My question is whether this method is abstract too. If not why it has to be overridden in the class that we want to clone.
And one more question .
It is overridden as follows
public Object clone() {
MyClass obj;
try {
obj = (MyClass)super.clone();
} catch(CloneNotSupportedException e) {
Statements
}
return obj;
}
In the 4th line of this code we called , super.clone() method , which clone() method are we calling in this line and if Object.clone() method why did we override it , we can simply cast it wherever we want to clone the Object like
MyClass obj2 = (MyClass)obj1.clone();
and is their any way to know the coding of Object.clone() method?
A method cannot be native and abstract at the same time because native is a statement about a specific implementation of a method;
clone must be overridden at least because Object#clone is protected to prevent access to clients in the case the object does not support cloning;
in many cases clone needs to do more than Object#clone, which just makes a binary copy of the original, which amounts to a shallow clone, with all the referenced objects staying the same;
there's no point in catching CloneNotSupportedException in the subclass: you should already know whether the superclass does or doesn't support cloning (it is not something which can change at runtime).
Object.clone() is not abstract. Overriding it when implementing Clonable is just a convention. (Clonable is a marker interface - like Serializable etc.)
Overriding methods (should) always call Object.clone() directly or indirectly.
I think, casting it is not necessary because Object.clone() preserves the exact class. If you catch the CloneNotSupportedException you could even return MyClass.
As Object.clone() is implemented natively you would have to look at the sources of some JVM implementation like OpenJDK.
My question is whether it's abstract too
No it isn't, and the Javadoc already tells you that, as does the fact that Object itself isn't abstract, and it 'doesn't have to be overridden in the class we want to clone' unless you want to change the access permission, which has nothing to do with 'abstract': and you couldn't call 'super.clone()' in such an override unless it wasn't abstract.
In short, your question doesn't make much sense.
Why was the equals() method in java.util.Comparator made abstract, if it is already implemented in the Object class?
First of all, it's worth noting that the method is not "made abstract". If you implement Comparator<T> without implementing equals(), your code will compile. Your class will simply use the implementation provided by Object.
As to why re-declare the method, this is done because the contract on Comparator<T>.equals() is more stringent than the contract on Object.equals(). This is explained in the documentation:
Additionally, this method can return true only if the specified object is also a comparator and it imposes the same ordering as this comparator. Thus, comp1.equals(comp2) implies that sgn(comp1.compare(o1, o2))==sgn(comp2.compare(o1, o2)) for every object reference o1 and o2.
If Comparator did not override equals(), there would be no good way to specify that its contract on equals() is different from Object's.
Please refer to the Java code below:
class Base{
Base(){
System.out.println("Base Constructor");
method();
}
void method(){}
}
class Derived extends Base{
int var = 2;
Derived(){
System.out.println("Derived Constructor");
}
#Override
void method(){
System.out.println("var = "+var);
}
}
class Test2{
public static void main(String[] args) {
Derived b = new Derived();
}
}
The output seen is:
Base Constructor
var = 0
Derived Constructor
I think var = 0 occurs because Derived object is half initialized; similar to what Jon Skeet says here
My questions are:
Why does the overridden method get called if the Derived class object isn't created yet?
At what point in time is var assigned value 0?
Are there any use cases where such behavior is desired?
The Derived object has been created - it's just that the constructor hasn't been run yet. The type of an object never changes in Java after the instant it is created, which happens before all constructors run.
var is assigned the default value of 0 as part of the process of creating an object, before constructors are run. Basically, the type reference gets set and the rest of the memory representing the object gets wiped to zero (conceptually, anyway - it may already have been wiped to zero before, as part of garbage collection)
This behaviour at least leads to consistency, but it can be a pain. In terms of consistency, suppose you had a read-only subclass of a mutable base class. The base class may have an isMutable() property which was effectively defaulted to true - but the subclass overrode it to always return false. It would be odd for the object to be mutable before the subclass constructor ran, but immutable afterwards. On the other hand, it's definitely strange in situations where you end up running code in a class before the constructor for that class has run :(
A few guidelines:
Try not to do much work in a constructor. One way of avoiding this is to do work in a static method, and then make the final part of the static method a constructor call which simply sets fields. Of course, this means you won't get the benefits of polymorphism while you're doing the work - but doing so in a constructor call would be dangerous anyway.
Try very hard to avoid calls to non-final methods during a constructor - it's very likely to cause confusion. Document any method calls you really have to make very clearly, so that anyone overriding them knows that they will be called before initialization has finished.
If you have to call a method during construction, it's usually not then appropriate to call it afterwards. If that's the case, document it and attempt to indicate it in the name.
Try not to overuse inheritance in the first place - this is only going to become an issue when you've got a subclass deriving from a superclass other than Object :) Designing for inheritance is tricky.
Why does the overridden method get
called if the Derived class object
isn't created yet?
Derived class constructor implicitly calls the Base class constructor as the first statement. Base class constructor calls method() which invokes the overridden implemention in the Derived class because that is the class whose object is being created. method() in Derived class sees var as 0 at that point.
At what point in time is var assigned
value 0?
var is assigned the default value for int type i.e. 0 before the contructor of Derived class is invoked. It gets assigned the value of 2 after the implicit superclass contructor call has finished and before the statements in Derived class's constructor start executing.
Are there any use cases where such
behavior is desired?
It is generally a bad idea to use non-final non-private methods in the constructors/initializers of a non-final class. The reasons are evident in your code. If the object that is being created is a subclass instance, the methods may give unexpected results.
Note that this is different from C++, where the type does change while the object is being constructed, so that calling a virtual method from the base class constructors doesn't call the derived class's override. The same thing happens in reverse during destruction. So this can be a small trap for C++ programmers coming to Java.
There are some properties of the Java language specification that should be noted in order to explain this behavior:
A superclass' constructor is always implicitely/explicitely called before a subclass' constructor.
A method call from a constructor is just like any other method call; if the method is a non-final, then the call is a virtual call, meaning that the method implementation to invoke is the one associated with the runtime type of the object.
Prior to a constructor execution, all data members are automatically initialized with default values (0 for numeric primitives, null for objects, false for boolean).
The sequence of events is as follows:
An instance of the subclass is created
All data members are initialized with default values
The constructor being invoked immediately delegates control to the relevant superclass' constructor.
The super constructor initializes some/all of its own data members, and then calls a virtual method.
The method is overriden by the subclass, so the subclass implementation is invoked.
The method tries to use the subclass' data members, assuming they are already initialized, but this is not the case - the call stack hasn't returned to the subclass' constructor yet.
In short, whenever a constructor of a superclass invokes a non-final method, we have the potential risk of entering into this trap, therefore doing it is not recommended.
Note that there is no elegant solution if you insist on this pattern. Here are 2 complex and creative ones, both requiring thread synchronization(!):
http://www.javaspecialists.eu/archive/Issue086.html
http://www.javaspecialists.eu/archive/Issue086b.html