je suis entrain d'apprendre à bidouiller en Java, et je suis assez surpris, mais cela vient peut etre de mon expérience C++.
 
beaucoup de classes de l'API ne possède ni méthode clone ni constructeur par recopie: par contre, un constructeur admettant une string en param est la. bref pour recopier, c'est à la batarde new MonObjet(unObjet.toString())
 
je sais que les cas ou l'on a besoin de véritable copie ne sont pas forcément fréquents, mais je trouve que les mecs qui ont fait ça ont un peu fait les radins...

ben je fais part de mon étonnement

exemple ?

j'en ai pas sous la main, je parcours l'API et y en a plein

 
j'te parle même pas de certainnes classes de l'API java qui n'implémentent pas l'interface serializable, une honte mon bon monsieur
 
 
exemple les classes de java.awt.geom; par contre elles implémentent cloneable  

Bin et Object.clone() alors ?

En effet...
 

 
 
+1

 
*2  

 
Ben oui ! C'est normal. Qu'est ce qui choque là dedans ?

 
on aurait pu imaginer que la JVM soit capable de cloner une instance d'un objet dont il a la classe mais ca n'est pas si évident qu'il n'y parait c'est tout ...
 
Voir C++

Techniquement, la JVM pourrait faire cela, mais les concepteurs de Java ont choisi de permettre au programmeur d'interdire la fabrication d'un clone. Il y a des fois, où, en effet, cloner un objet n'a pas de sens : lorsqu'il s'agit d'une ressource critique du monde extérieur, ou que l'objet est un thread, par exemple.
 
++Taz> "new MonObjet(unObjet.toString())" ne clone pas un objet, car on n'a jamais la garantit que la représentation de l'objet que renvoie toString() décrit bien tout l'objet. "tostring()" est généralement utilisé pour afficher des traces de debug, ou une présentation possible de l'objet, lisible pour un humain. Ce qui signifie au passage que pour faire ce que tu dis (un constructeur qui attend en argument la représentation chaîne de l'objet), il faudrait développer un interpréteur pour cette représentation...  
Ce n'est pas un peu lourd pour si peu ?    
 
Autre remarque : exemples de classe qui a un constructeur qui attend un seul argument de type String :

Comme tu peux le constater, aucun de ces constructeurs ne clone d'objet... La plupart des classes de l'API n'ont d'ailleurs pas de tel constructeur.
Il y a bien quelques exceptions, comme le constructeur de java.util.Date, mais ce dernier a été déprécié il y a déjà plusieurs années au profit d'une méthode statique au nom plus évocateur (Date.parseString()).

 
Il ne critiquait pas le comportement de la JVM. Il disait que les concepteur de l'API Java auraient pu prévoir la copie de leurs classes (leur faire implémenter l'interface "Clonable" quoi).

 
beaucoup l'implémentent mais pas toutes, et parfois sans raison valables hormis la fénéantise des concepteurs; sur ce coup là l'API java c'est un peu la fête du slip

 
C'est plutôt à toi de cloner et pas à eux non ? donne des exemples, je vois pas ce que tu veux cloner. N'oublie pas que le GC te permet d'éviter le copie profonde dans beaucoup de cas si tu viens du C++. C'est pas à eux de dire que telle classe qui est dans une bibliothèque est cloneable ou pas, c'est à toi de savoir si tu l'utilises en flyweight, en singleton, en handler de ressource externe ou en truc cloneable.

évidemment j'ai un peux de mal à m'adapater, mais des fois j'ai besoin d'avoir des vrais copies profondes, et là si rien n'est prévu...

J'aimerais vraiment que tu files 1 ou 2 exemples, pour pouvoir me faire une idée, en gros, j'ai jamais eu le problème (mon problème en général, c'est plutôt de me démerder pour planquer les constructeurs afin que personne ne fasse de copie) mais je n'ai pas de cas en tête où c'est nécessaire et absent.
 
Concernant la copie profonde, c'est à toi de te démerder, à cause des cycles dans le graphe d'agrégation, ils auraient pu mettre un détecteur de cycles mais bon, le développeur sait mieux la tronche de son graphe que le concepteur du langage.
 
Quel type d'interface aurais-tu souhaité pour la copie ?

 
Si je me rappelle bien de mes lectures à propos du C++, le constructeur de copie est nécessaire pour pouvoir passer les paramètres par valeur aux différentes fonctions. Comme en Java, ces passages se font par référence, il n'est pas nécessaire que tous les objets implémentent la méthode clone(). Le choix est donc laissé au développeur d'implémenter ou non clonable avec une copie profonde ou non.