Reprise du message précédent :

oue voila c'est en gros ce que j'ai voulu dire

JDO c'est une norme, Hibernate une bibliotheque (qui implemente entre autre JPA/EJB3).  
 
Apres c'est clair que l'implentation JDO de reference, JPOX, est pas forcement super performante de base. Mais y'a moyen de tweaker un pneu.
 
Cepandant si on suit une norme tel que JDO on peut changer d'implementation, alors que si on suit pas de norme on ne peu pas. C'est bien la le pbs des truc comme Castor / Hibernate (si on se cantonne pas a JPA/EJB3)...
 

quel intérêt de changer d'implémentation sur un gros projet qui marche ?

En principe si le compilateur etant intelligent, (String) ne serait qu'une syntaxe qui evite d'ecrire le .toString() explicitement et ça donnerais la meme chose.
 
Ceci dit (String) strictement ça ne devrait pas passer à la compilation car on n'est pas censé pourvoir caster un objet et type de base. (meme si string est un peu entre les deux certes, c'est pas top jolie)

Gagner en perfs si l'implementation choisi au debut n'etait finallement pas adapté à la charge qui à evolué pour une raison X ou Y.

quand je vois ce qu'on fait bouffer à hibernate ... j'ai du mal à voir ce qu'on pourrais gagner comme perf .. c'est plus le serveur de données qui est à genoux avant ...
m'enfin peut-être que ca a son importance dans certains applications, je veux bien croire ...

n'importe quoi.

N'importe quoi de qualité: (String), c'est un typecast, donc ça dit simplement "considère cet objet comme un String". Et dans la mesure où java est à peu près type-safe, si on tent d'upcaster et que c'est pas bon on a droit à une TypeCastException.

toString(), par contre, c'est une méthode dispo à partir de la racine de l'arbre (Object) ayant pour but d'obtenir une représentation chaîne de n'importe quel objet java.

1. Il n'est pas indiqué dans le contrat de toString que cette représentation doit être équivalente à l'objet même, cette méthode est faite uniquement pour que les gens (et on parle bien des humains là, pas des machines) aient une représentation lisible de l'objet
2. Donc toString() n'est en aucun cas une conversion
3. Et dans tous les cas, un cast Java n'effectue pas de conversion automatique. Jamais. On est pas en C, et c'est d'ailleurs l'un des gros avantages du truc.

En d'autres termes, les rôles et sémantiques de (String) et toString n'ont absolument aucun rapport, ils donnent juste le même résultat quand utilisés sur un objet de type String.

Mais qu'est-ce que tu racontes comme salades?

oui, je suis d'accord, mais disons que je me posais la question...

et puis quand on écrit un cast, faut parentéser tout ça, et ça alourdi pas mal la lecture du code. Donc si il n'y a pas de grosse différence niveau perf, j'ai pas de scrupule à faire un toString(). Puisque je sais que mon object est une String.

String string = monObjetX.toString();

String string = (String)monObjectX;

 
bah le deuxieme à moint que tonObjectX soit un string ça marchera jamais

 
 
ha ouai ?  

Ouh là, dans quel cadre tu voulais l'appliquer exactement

 
 
il fallait voir une certaine ironie dans le dernier post.
 
Je récupère les noms des paramètres d'initialisation d'une servlet, ils sont dans une Enumeration, donc je dois looper dessus, et nextElement() renvoie des Object, qu'il faut donc caster ou leur appliquer toString().

Bon, ça passe alors
 
 

un String pardon

on aurait aussi pu voir du troll dans le premier

lequel serait le plus rapide ?

Proprement, si on sais que c'est deja un String faut caster.

@MEI c'est quoi cet efface de post à l'arrache ?
 

 
si (String)s est égal en valeur à s.toString() c'est juste un cas particulier, une coincidence, un hasard, il n'y a pas de cas général
 
au final ça ne donnerai pas la même chose car  
 
String a = (String)s;  
String b = s.toString();
 
a.equals(b)  ---> true
a==s ---> true
b==s ---> false (enfin j'ai pas testé mais il y a 99,99% de chances)
 

 
String n'est pas un type de base.
C'est juste qu'il est final, et on peut pas hériter de String.

 
tu aurais du.
 
http://java.sun.com/j2se/1.4.2/doc [...] toString()

ça dépend ce qu'on veut faire avec

nottament si tu veux ou pas que le string original soit modifié

ouaw j'ai tapé le 0,0001 il faudrait que je joue au loto

@MEI, donc j'ai rien dit

Je me permet de dire que AMHA c'est très stupide de leur part d'avoir faire ça  (j'ai bien dit amha)

mon argument serait que ça introduit un cas particulier qu'il faudrait traiter dans le cas ou on voudrait faire des modifs sur les chaines obtenues par toString() et qu'on ne souhaite pas modifier l'objet sur lequel est appliqué le .toString()

Ce qui signifie que si on à une variable de type Object et qu'on décide de faire un .toString() pour récupérer la forme en String d'objets de types variés, on va être obligé de dupliquer tous les String obtenus pour être sûrs qu'on va pas modifier un objet déjà existant, ou alors faire un test systématique sur chaque objet pour savoir si on doit le cloner plutot que de faire un toString.

Donc comme le dit Masklinn il n'y pas de contrat dessus mais ça parait un peu bizarre ...

dis, tu sais que les chaines sont immuables ?
non ? ben va te documenter avant de raconter des âneries, merci
 
c'est un topic d'élite ici, monsieur.

Sauf qu'on peut pas, les String java sont immutables, donc renvoyer directement le string est la chose la plus simple qui puisse être faite, c'est la plus efficace, et dans la mesure où il est impossible de modifier un String java en java (on peut le faire en tapant direct dans la memoire de la JVM mais... ), où toutes les opérations sur des string créent de nouveaux strings idépendants, il n'y a aucun risque

Ya des langages (y compris de haut niveau, Ruby par exemple) qui ont des strings modifiables. C'est pas un problème d'hérésie, c'est juste que c'est pas la sémantique des strings java.

Je l'ai su
mais manifestement ce n'est plu le cas

c'est surtout que fonctionnelement ça n'a limite rien a voir: dans le 1er cas, on assume que monObjetX n'est pas null mais on a pas idée de son type, dans le 2e, on ne sait pas monObjetX est null ou pas mais on assume qu'il est de type String ...

String string = monObjetX.toString();

String string = (String)monObjectX;

Les 2 sont aussi rapides, c'est le même code qui est exécuté dans l'immense majorité des cas.
 
 
edit: à part la vérification de null, qui peut être déplacée dans le premier cas.

Oui mais là j'assumais que c'était le cas, et apparement l'auteur de la question aussi

 
Oui voilà oui

bah mets un toString() ça te fera du jaune en moins dans l'IDE.

voilà, c'est ce que je fais du coup.
 
mais ça me mettait pas de jaune...  

un cast ça te met pas de jaune ?
change les réglages de ton IDE si tu es en java 5 (en 1.4 c'est pas possible, tu aurais du jaune partout)

Sous IJ ça m'en met pas nécessairement, ça dépend d'où sort la donnée et ce que j'en fais derrière

je suis en java 1.4 (merci WAS 6).
 
le jour où on passe à java 5 ou 6, je vais prendre cher...

ouais, j'y crois, passe une collection en argument d'une méthode pour voir ...

 
lolilol
 
tu peut m'expliquer concretement, avec un vrai cas, l'utilisation du <? super Toto> ?

C'est l'identité secrète de Super Toto naturellement.
 
Par exemple, <? super Man> ça correspond à ClarkKent

bien mérité

Cargo + Tomcat 5 =   (mais bon, super lent, la faute a Tomcat je supose)
Cargo + Jetty (pour voir si ça speed plus qu'avec Tomcat) =  
ClassNotFound sur javax.servlet.Filter avec la version 5 de Jetty je crois. (alors que la webapp démarre tranquilou sur avec le plugins jetty de maven) Et une autre erreur (qui doit peut être lié avec les namespaces du web.xml) avec la version 6. Bon, comme j'y connais pour l'instant que dalle dans les applications servers mais je crois que ca va pas être pour demain les tests de recettes avec Cargo  
(et Cargo + Selenium c'est sympa, mais pareil, niveau version, faut trouver les bonnes qui marches ensemble j'ai l'impression...)

tu le demarres et configure ou/comment ton cargo ?

(j'avais trouvé la config par maven pour le moins douloureuse, et finalement j'y vois pas grand interet, donc y'a ptet d'autres points d'entrées)

configuration: pom.xml, démarrage : dans la phase test-integration (maven2).

Bon, je me suis pas pris la tête, hein, je suis parti d'un truc existant :
http://binil.wordpress.com/2006/12 [...] and-maven/ (sauf que l'exemple se base sur des SNAPSHOTS, qui n'existent plus, du coup...donc y'a des modifs a faire dans les pom.xml)