Implementing clone() in a Generic Class with Cloneable Bound Leads to Unchecked Cast and Access Errors

I'm working on extending a generic Node class to create a GenericNode class for a data structure exercise. The GenericNode class is generic, bounded above by the Cloneable interface, and implements Cloneable. I aim to implement a clone() method that clones the GenericNode's value, which is also of a generic type that extends Cloneable. However, I'm encountering two specific issues when trying to clone the value attribute and casting the result of super.clone().

Here's my current implementation of the GenericNode class:

public class GenericNode<E extends Cloneable> implements Cloneable {
    private E value;
    private GenericNode<E> north, south, west, east;

    @Override
    public GenericNode<E> clone() throws CloneNotSupportedException {
        GenericNode<E> copiedNode = (GenericNode<E>) super.clone(); // Error 1 here
        copiedNode.value = this.value.clone(); // Error 2 here
        return copiedNode;
    }
}

1. Unchecked Cast Warning: I'm warned about the unchecked cast from Object to GenericNode after calling super.clone(). I understand this is due to type erasure with generics, but I'm seeking advice on how to handle or suppress this warning effectively in this scenario.

2. Protected clone() Access: Attempting to clone the value (which is of generic type E) results in an error due to 'clone()' has protected access in 'java.lang.Object'. Given that E extends Cloneable, I thought I would be able to clone it directly, yet the direct call seems prohibited.

This task requires the use of clone() as specified, and I'm restricted to using only the operations, classes, or interfaces already present in my project (hence, no external libraries or utilities).

Question: How can I correctly implement the clone() method for this generic class to solve the mentioned issues, especially considering the constraint on imports?

I appreciate any guidance or suggestions you might have. Thank you!

That's.. not how clone works. What you want is not possible:

implementing Cloneable is a flag interface (i.e. this is dubious API design; it's an implementation detail: A way to tell the built-in clone() method that it's acceptable to just copy every field, an entirely private affair between your code and the native clone() method of the JDK core libraries, but, you are forced to expose this info publicly as your implements list cannot be made private). It does not expose the clone method - it remains protected.

Reading is important. For example, if you read the docs on the Cloneable interface, you'll find:

Note that this interface does not contain the clone method. Therefore, it is not possible to clone an object merely by virtue of the fact that it implements this interface. Even if the clone method is invoked reflectively, there is no guarantee that it will succeed.

Which spells this out: Nope, this does not mean you can clone something just because it implemented the interface.

So, how do you clone an arbitrary object? You don't - there is no way in java to state 'any object is fine here, as long as it is cloneable'.

<E extends Cloneable> is not a good idea. Cloneable is an implementation detail and has no bearing on what a class actually exposes or can do - hence, you should never use it to describe relevant hierarchy. As you found, it does not accomplish your goal. There is no type in the core libraries that represents 'a type that can make copies of itself'. Your only real option is to make your own take on a Cloneable interface, which would probably look like:

public interface Copyable<S extends Copyable<S>> {
  S copy();
}

But, nothing will implement this (not even arrays), other than your own classes.

But.. other libraries do this!

Yeah, and they use reflection and thousands of lines of code to do it, so use one of those. Your requirements state you can't do that. Which gets us to: This job is impossible.

This is an assignment, it can't be impossible

Well, it could be a kobayashi maru exercise, but more likely the intent is to simply make a shallow clone. Do not (attempt) to clone the object your value field is pointing at. There is no need to make clones of immutables, but presumably your GenericNode implementation isn't immutable - your north, south, east, west fields are not final. Here are the 2 ways to tackle this:

@SuppressWarnings("unchecked")
@Override
public GenericNode<E> clone() {
  return (GenericNode<E>) super.clone();
}

or:

@Override
public GenericNode<E> clone() {
  GenericNode<E> copy = new GenericNode<E>();
  copy.north = north;
  copy.east = east;
  copy.west = west;
  copy.south = south;
  copy.value = value;
  return copy;
}

The effect is identical and they are identically fast. The only advantage to the first snippet is that it's less code that does not need to be updated if you add fields later. The disadvantage is that you need that ugly-cast and the warning (not an error as you wrote, that's a warning) needs to be suppressed with @SuppressWarnings). Note also that you should not add throws CloneNotSupportedException because you know that exception cannot possibly be thrown here.

But wait - deep clone is vastly more complicated than you seem to think it is

This entire concept of 'deep' vs 'shallow' is incredibly complicated here. If your node objects are themselves mutable, and you yourself decided it is wise to clone the value, then.. your code makes no sense! Why aren't you cloning north, south, west, and east?

Except.. presumably this.north.south is yourself again. So if you ask north to clone itself, and all clones are deep clones, it's an infinite loop - to clone north, north will clone it's south, which is yourself, which will.. clone north, and so on.

Hence, to properly fully deep-clone a grid, you need to maintain a cachemap that remembers which values have already been cloned. The operation more fundamentally simply isn't something you can ask a single node in the grid, it's really only a sensible operation on an entire grid.

This goes some ways into explaining why clone() only makes shallow copies (because 'just make a deep copy' sounds simple but is rarely useful and often just results in a stackoverflowerror because it's infinite), and why immutable data types are usually preferred for this sort of thing.

It this is an assignment and not one that is meant to take a few weeks / is meant to be impossible to solve, the intent is that you simply make a shallow clone. That sounds pretty useless, so, I doubt the educational quality of whatever class or tutorial you're following here.