Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
É uma forma criativa de "burlar" a falta de permissão para cópia de um objeto que não é clonável (não implementa a interface Cloneable), desde que ele seja serializável...
Outra utilidade seria não precisar implementar o método clone() de um objeto clonável para um "clone profundo". Vc. deixaria o mecanismo de serialização fazer isso por você.
Em questão de segurança, não há muito problema pois se vc. declara um objeto serializável, está declarando um objeto não-seguro. Não consigo pensar em "males" possíveis de se fazer com um objeto clonável além do que se conseguiria fazer com um serializável.
A questão de semântica fica interessante: penso que significa que a interface Serializable deveria implementar Cloneable tb, ou seja, todo objeto serializável seria tb. automaticamente clonável (algum estudioso do mecanismo de segurança da JVM tem alguma objeção?).
Em questão de produtividade, o "malabarismo" descrito pode ser trabalhoso d+, só pra evitar um deep clone, além de usar disco desnecessáriamente.
Resumo: Concordo, a idéia é muito interessante. Por outro lado, não acho que represente realmente um "hacking" da JVM ou um pattern que possa ser usado na prática.
Em questão de produtividade, o "malabarismo" descrito pode ser trabalhoso d+, só pra evitar um deep clone, além de usar disco desnecessáriamente.
Só tem um problema ai, ele nem usa o disco . Joga num array de bytes e volta do array de bytes _________________Vitor Pamplona
http://vitorpamplona.com @vitorpamplona
É porque, mesmo sem disco, vc. lida com mais de uma estrutura de dados diferente. E manipulações genéricas sobre objetos são custosas.
Quando vc. grava em disco, esta perda de performance nem é notável, pq ela é "maqueada" pelo custo de acesso ao dispositivo.
Assim, continuo pensando que é uma curiosidade interessante (e Serializable realmente deveria ser filha de Cloneable, o q vc. acha?), mas apenas uma curiosidade. Não seria hacking e nem uma técnica útil... _________________JavaFree.org
Desculpem ressuscitar esse tópico. Sobre o uso de bibliotecas para clone, equals, hasCode etc, queria saber se no Google Guava existe um clone/deepClone para fazer a clonagem dos objetos que nem fazemos com o clone de SerializationUtils do Apache Commons, que faz uma clonagem profunda por serialização?
Não encontrei nenhum método para clonagem no Guava, nem na classe do pacote 'com.google.common.base.Objects' (onde seria o óbvio estar). Obrigado. _________________[color=darkblue]>[/color]
-
Novo no fórum e quer postar o código fonte? De uma olhada: Tag CODE do fórum -
"Compartilhe seu conhecimento..."
Desculpem ressuscitar esse tópico. Sobre o uso de bibliotecas para clone, equals, hasCode etc, queria saber se no Google Guava existe um clone/deepClone para fazer a clonagem dos objetos que nem fazemos com o clone de SerializationUtils do Apache Commons, que faz uma clonagem profunda por serialização?
Não encontrei nenhum método para clonagem no Guava, nem na classe do pacote 'com.google.common.base.Objects' (onde seria o óbvio estar). Obrigado.
Dica abre outro chamado, especificando melhor problema.
abcs _________________att Davi Costa
Analista/Arquiteto Java
Especialista em Engenharia de Sistemas
ScrumMaster Certified
vfpampPosts:6098
Muito interessante
From: Javalobby
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
CopernicoPosts:558
É uma forma criativa de "burlar" a falta de permissão para cópia de um objeto que não é clonável (não implementa a interface Cloneable), desde que ele seja serializável...
Outra utilidade seria não precisar implementar o método clone() de um objeto clonável para um "clone profundo". Vc. deixaria o mecanismo de serialização fazer isso por você.
Em questão de segurança, não há muito problema pois se vc. declara um objeto serializável, está declarando um objeto não-seguro. Não consigo pensar em "males" possíveis de se fazer com um objeto clonável além do que se conseguiria fazer com um serializável.
A questão de semântica fica interessante: penso que significa que a interface Serializable deveria implementar Cloneable tb, ou seja, todo objeto serializável seria tb. automaticamente clonável (algum estudioso do mecanismo de segurança da JVM tem alguma objeção?).
Em questão de produtividade, o "malabarismo" descrito pode ser trabalhoso d+, só pra evitar um deep clone, além de usar disco desnecessáriamente.
Resumo: Concordo, a idéia é muito interessante. Por outro lado, não acho que represente realmente um "hacking" da JVM ou um pattern que possa ser usado na prática.
_________________JavaFree.org
vfpampPosts:6098