Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2006

Tip: Looking for answers? Try searching our database.

Cloneable type parameter?

Thread view: 
Stefan Schmiedl - 13 Aug 2006 20:41 GMT
Greetings.

I'd like to define a wrapper class, whose instances keep read-only
copies of the original object passed in. I tried using generics for this:

public class RestorableObject<T> {

 private T original;
 private T workingCopy;

 public RestorableObject(T obj) {
   original = obj;
   workingCopy = obj.clone();  // clone() is protected in Object
 }

}

After RTFM on how generics actually work, the error message is explainable:
T is unbounded, so the compiler sees me calling a protected method outside
of its class.

So here is my next attempt:

public class RestorableObject<T extends Cloneable> {

 private T original;
 private T workingCopy;

 public RestorableObject(T obj) {
   original = obj;
   workingCopy = obj.clone();  // clone() not found in Cloneable
 }

}

I should have seen this coming, since Cloneable is an empty interface,
and the docs state that

* By _convention_, classes that implement this interface should override
* Object.clone (which is protected) with a public method.

I guess nobody told javac about this _convention_ ... must be human thing.

I would like to make the compiler ensure that RestorableObject is
only wrapped around objects providing a clone() method. I can do
this by introducing an interface

public interface ReallyCloneable<T> {
 public T clone();
}

and finally arriving at

public class RestorableObject<T extends ReallyCloneable<T>> {
 
 private T original;
 private T current;
 
 public RestorableObject(T obj) {
   original = obj;
   current = obj.clone();
 }
 
}

Is there a more elegant way of doing this?

Regards,
Stefan
Daniel Dyer - 13 Aug 2006 21:22 GMT
> I should have seen this coming, since Cloneable is an empty interface,
> and the docs state that
[quoted text clipped - 8 lines]
> only wrapped around objects providing a clone() method. I can do
> this by introducing an interface

Cloning in Java was not very well thought-out.  You could use reflection  
to invoke the clone method.

Dan.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Mike Schilling - 14 Aug 2006 01:07 GMT
>> I should have seen this coming, since Cloneable is an empty interface,
>> and the docs state that
[quoted text clipped - 11 lines]
> Cloning in Java was not very well thought-out.  You could use reflection
> to invoke the clone method.

Note, though, that clone() (by default, at least) is a shallow clone, so
changes made to objects that are fields of your working copy may not be
undone by reverting to your original.   What might work better for you
(depending on your requirements, which are unstated) is to save the object
by writing it to a DataOutputStream, and restoring it by reading it back
from that stream.  This will do the equivalent of a deep clone, and works
for many objects that do not implement Clonable.
Stefan Schmiedl - 14 Aug 2006 06:49 GMT
> Note, though, that clone() (by default, at least) is a shallow clone, so
> changes made to objects that are fields of your working copy may not be
[quoted text clipped - 3 lines]
> from that stream.  This will do the equivalent of a deep clone, and works
> for many objects that do not implement Clonable.

That's a nice idea, actually. Especially since I could tweak my
program so that I would need to do this only once per session.

Thanks,
s.
Thomas Weidenfeller - 14 Aug 2006 10:10 GMT
> Greetings.
>
[quoted text clipped - 12 lines]
>
> }

You need to use reflection to verify if T has an accessible clone()
method and invoke the method if you can get hold of one. The
serialization trick will not help much. You have to check if the object
is serializable. Anyhow using serialization is likely a great waste of
CPU cycles.

In both cases you are faced with another problem: What if T does not
provide clone() (or serialization)? Error message? Gamble and use the
original reference? Throw an exception? You decide.

In short, generics and cloning don't work well together. Yet another
reason why IMHO generics are am ugly, not well thought-out hack. clone()
was always a strange hack, and with generics two hacks collide.

/Thomas
Mike Schilling - 14 Aug 2006 16:17 GMT
> In both cases you are faced with another problem: What if T does not
> provide clone() (or serialization)? Error message? Gamble and use the
[quoted text clipped - 3 lines]
> reason why IMHO generics are am ugly, not well thought-out hack. clone()
> was always a strange hack, and with generics two hacks collide.

Not to defend generics, but if Clonable sensibly provided a public clone()
method, the generics approach would work as expected.
Stefan Schmiedl - 14 Aug 2006 17:48 GMT
>> In short, generics and cloning don't work well together. Yet another
>> reason why IMHO generics are am ugly, not well thought-out hack. clone()
>> was always a strange hack, and with generics two hacks collide.
>
> Not to defend generics, but if Clonable sensibly provided a public clone()
> method, the generics approach would work as expected.

Some of these thoughts have occurred to me, too.
But you know, when in Rome, don't complain about linguam latinam :-)

s.
Thomas Weidenfeller - 15 Aug 2006 08:29 GMT
> Not to defend generics, but if Clonable sensibly provided a public clone()
> method, the generics approach would work as expected.

You would still have to have the first problem, an unchecked cast and
you either have to suppress or ignore the warning:

class CloneMe<T> implements Cloneable {
    public CloneMe<T> clone() {
        CloneMe<T> c = (CloneMe<T>) super.clone(); // BANG!

        :
        .
    }
}

The problem is the call to super.clone(). And you would still need
another unchecked cast for every instance you want to deep-clone.

/Thomas
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.