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 / April 2006

Tip: Looking for answers? Try searching our database.

clones, generics and unchecked cast warnings

Thread view: 
rwfields@yahoo.com - 23 Apr 2006 06:49 GMT
Hello,

Here is the code:

import java.util.Stack;

public class Clone implements Cloneable {

  Stack<Object> stack = new Stack<Object>();

  public Clone() {
  }

  public Object clone() throws CloneNotSupportedException {
     Clone rv = (Clone) super.clone();
     rv.stack = (Stack<Object>) stack.clone();
     return rv;
  }

  public static void main (String[] args) throws
CloneNotSupportedException {
     System.out.println("hello world!");
     Clone a = new Clone();
     Clone b = (Clone) a.clone();
  }
}

It seems like the explicit cast should prevent the warning, but it does
not.  Without the explicit cast, the code generates a compile error.  I
can live with warnings, but it sure seems like what I am trying to do
is valid.  Did the language designers (1.5) miss this on accident, or
is there something simple that I am missing?  Does anybody have any
thoughts?

Thanks,
Randall
hiwa - 23 Apr 2006 07:31 GMT
Since Java generics is based on the 'erasure' mechanism,
this cast and getting a warning is always unavoidable.

Sun gives us a small solace called SuppressWarnings
annotation.

For your (Clone) casting for clone() return value, I personally
think Java cloning has failed to keep step with generics and
it is a major bug.
Piotr Kobzda - 23 Apr 2006 07:57 GMT
> It seems like the explicit cast should prevent the warning, but it does
> not.  Without the explicit cast, the code generates a compile error.  I
> can live with warnings, but it sure seems like what I am trying to do
> is valid.  Did the language designers (1.5) miss this on accident, or
> is there something simple that I am missing?  Does anybody have any
> thoughts?

Covariant return types introduced in Java 5 allows you to write a method
whose return type is a subclass of the type returned by the method with
the same signature in the superclass.

Thus your clone() method would be declared as:

   public Clone clone() { ...

Which allows for usage like:

   Clone a = new Clone();
   Clone b = a.clone();

BTW -- Declaring CloneNotSupportedException with a custom clone() method
when a class implements Cloneable is impractical /will never happen for
such a class/, and should be handled in that method.

Regards,
piotr
hiwa - 23 Apr 2006 09:23 GMT
> Covariant return types introduced in Java 5 allows you to write a method
> whose return type is a subclass of the type returned by the method with
[quoted text clipped - 8 lines]
>     Clone a = new Clone();
>     Clone b = a.clone();
It works. Thanks. But I can't find any article(s) on
covariant return type in the JDK 1.5 standard
documentation set. I've found this article on
bugdatabase:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349937


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.