6 Replies Latest reply on Mar 13, 2002 8:29 AM by adrian.brock

    CloneNoteSupportedException and *Info classes

    squirest

      Checking the javadoc I don't think *Info classes should be declaring they throw CloneNotSupportedException.

      It would appear that the ModelMBean*Info classes should be throwing RuntimeOperationsExceptions if problems occur in clone(). I think they assume that the clone operations will use copy constructors - at least for descriptors.

      So, should I remove the CNSException from the signatures?

      Trev

        • 1. Re: CloneNoteSupportedException and *Info classes

          yeah you can remove CNSE but don't use the copy constructor (or other constructors) in clone implementations.

          -- Juha

          • 2. Re: CloneNoteSupportedException and *Info classes
            squirest

            > yeah you can remove CNSE but don't use the copy
            > constructor (or other constructors) in clone
            > implementations.
            >
            > -- Juha

            I spent some time with in the spec and javadoc. To be honest I'm baffled as to why people define copy constructors and use them in their clone() methods. The project we've inherited at work does this too. I wonder if I'm missing something...

            Anyhow, because of the call to super.clone() I figure we should try/catch CNSE around the entire body of the *Info clone methods that aren't supposed to throw CNSE, do a *real* clone of thyself, and throw an Error in the catch block.

            I'm away for the rest of the weekend so won't be looking at a computer till Sunday night.

            Trevor

            • 3. Re: CloneNoteSupportedException and *Info classes

              > To be honest I'm baffled as to why people define copy
              > constructors and use them in their clone() methods.
              > The project we've inherited at work does this too.
              > I wonder if I'm missing something...

              I think it is people with C++ background coming to Java. In C++ you defined copy constructors all over cause there was no clone, in Java you don't need a copy constructor cause you can implement Cloneable. Now we have a spec that mandates both clone and copy constructor. Ugh!. It is just plain ugly.

              Besides, I think using a constructor in clone() implementation is against the contract defined in Object.clone()

              Other thing that irks me is the way they declare runtime exceptions as part of the API signature all over the place. What an utterly pointless thing to do.

              > Anyhow, because of the call to super.clone() I figure
              > we should try/catch CNSE around the entire body of
              > the *Info clone methods that aren't supposed to throw
              > CNSE, do a *real* clone of thyself, and throw an
              > Error in the catch block.

              Yes that is correct.

              -- Juha

              • 4. Re: CloneNoteSupportedException and *Info classes

                As a programmer with a C++ background.

                What is the problem with using a copy constructor
                to override Object.clone() ?

                I can see a problem if implements Cloneable is specified,
                since that requires a field by field copy.

                Regards,
                Adrian

                • 5. Re: CloneNoteSupportedException and *Info classes

                  The issues are described here:
                  http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object_p.html

                  two main reasons are it is against the contract specified in java.lang.Object.clone() and it makes implementing clone for subclasses more inconvenient.

                  -- Juha

                  • 6. Re: CloneNoteSupportedException and *Info classes

                    I got it straightway as soon as you mentioned
                    subclass ;-)

                    The use of a constructor to copy an attribute is
                    a bit more subtle.

                    I'd better check my code...

                    Regards,
                    Adrian