[
https://issues.apache.org/jira/browse/LANG-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970087#action_12970087
]
Griffin DeJohn edited comment on LANG-307 at 12/10/10 1:20 AM:
---------------------------------------------------------------
BufferedImage can't be cloned this way, it simply fails. No danger there. Its
constructors either can't be successfully invoked because they have abstract
parameters, or they're picky and throw an exception when passed the default
values for primitives. If an instance of that class is present in the object
graph, my method would try to find a way around it. Failing that, it'll just
throw an exception. Could you give a working example and explain the problem?
Socket can't be cloned this way, either. But as for File, which does work, and
classes in general that manage system resources, that's a problem no matter
what. If you check out the examples page at the site you linked to, it
specifically warns, "Cloning objects that contain references to system
resources might be dangerous." So, using that library doesn't solve anything.
Actually, looking at the source code in the Cloner class, they're doing the
same thing I'm doing, but not as well (for example, they're just calling
Class.newInstance to initialize the clone, which will fail for anything lacking
a nullary constructor). It's the exact same recursive algorithm, though, so
it's not any faster, or more specialized, whatever that means.
was (Author: gdejohn):
BufferedImage can't be cloned this way, it simply fails. No danger there.
Its constructors either can't be successfully invoked because they have
abstract parameters, or they're picky and throw an exception when passed the
default values for primitives. If an instance of that class is present in the
object graph, my method would try to find a way around it. Failing that, it'll
just throw an exception. Could you give a working example and explain the
problem?
Socket can't be cloned this way, either. But as for File, which does work, and
classes in general that manage system resources, that's a problem no matter
what. If you check out the examples page at the site you linked to, it
specifically warns, "Cloning objects that contain references to system
resources might be dangerous." So, using that library doesn't solve anything.
Actually, looking at the source code in the Cloner class, they're doing the
same thing I'm doing, but not as well (for example, they're just calling
Class.newInstance to create the clone, which will fail for anything lacking a
nullary constructor). It's the exact same recursive algorithm, though, so it's
not any faster, or more specialized, whatever that means.
> CloneUtils - utility class to enable cloning via various different mechanisms
> -----------------------------------------------------------------------------
>
> Key: LANG-307
> URL: https://issues.apache.org/jira/browse/LANG-307
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
> Reporter: Henri Yandell
> Fix For: 3.1
>
> Attachments: AutoClone.java, lang-307.patch
>
>
> Taken from the tasks.html. No idea if we want to do it or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
