If my IDE is so smart, why do I need to cast "clone()"?

Question

My IDE (NetBeans) type checks my Collections while I am typing code. But then, why do I have to cast the returned object of Object.clone()? Which is fine. No harm no foul. But still, I don't understand.

Is type checking, without casting, the returned object of Object.clone() not possible? The generics framework makes me think the IDE could check the type of object references on the right-side of the "=" mark without casting while I am typing? I don't get it.

addendum
My usage case was just that I had a private Calendar field, pubdate. I was going to write:

Calendar getPubdate() {
    return pubdate;
}

but there is a risk that the invoker could modify my pubdate, so I returned a copy:

Calendar getPubdate() {
    return (Calendar) pubdate.clone();
}

Then, I wondered why I needed to cast pubdate.clone(). The method signature has the type right there. NetBeans should be able to figure that one out. And NetBeans seemed to be doing something similar with regard to Collections.

Answer 1

why do I have to cast the returned object of Object.clone()?

Because it returns Object.

The generics framework makes me think the IDE could check the type of object references on the right-side of the "=" mark without casting while I am typing? I don't get it.

Object.clone is not generic.

If generics had existed when clone was designed, it probably would have looked like this (using F-Bounded Polymorphism):

interface Cloneable<T extends Cloneable<T>> {
  T clone();
}

If Java had a MyType feature, it would maybe look like this:

interface Cloneable {
  this clone();
}

But Generics didn't exist when Object.clone was designed, and Java doesn't have MyTypes, so the type-unsafe version of Object.clone is what we have to work with.

Answer 2

This is not a feature of any IDE, but of the language definition.

An IDE helps you use a programming language more efficiently, it doesn't change the semantics of that language. That means that an editor helper might automatically insert a cast when it's obvious which one you want, but it can't simply break the rules of the language and pretend that code that doesn't compile is valid.

Edit It's true that an IDE can bundle its own compiler, and in fact many do exactly that, e.g. for better error reporting with more inside information into the partial parse tree. However, it would be a very bad idea to let this internal compiler implement different language semantics than the official SDK, since that would mean that code that works in development can mysteriously start failing when installed in production - producing problems that are by definition un-debuggable!

Answer 3

It is due to the type signature of the Object.clone method. The type signature states that the method will return an object of type Object.

protected Object clone() throws CloneNotSupportedException

The collections will use so called generic types to substitute the type of casting automatically.

So if you have this code:

List<Integer> ints = Arrays.asList(1,2,3);
int x = ints.get(0);`

the compiler will add the casts for you behind the scenes, so the code would actually be:

List ints = Arrays.asList(1,2,3);
int x = (Integer)ints.get(0);

Answer 4

For completeness, since Java 5, covariant return types are allowed. So you can write the following:

public MyObject implements Cloneable {
  @Override
  public MyObject clone() {
    try {
      return (MyObject)super.clone();
    } catch (CloneNotSupportedException e) {
      throw new AssertionError();
    }
  }
}

With this, the following code is legal:

MyObject original = new MyObject();
MyObject clone = original.clone();