Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Nouveau Test de Compétences : Librairies Java (lang, util, io, net)
Bonjour,
j'avais déjà sollicité vos avis pour un test de compétence sur
le langage java...
je réédite avec un test de compétence sur les API de base
(lang, util, io, net)
Tous les commentaires sont bienvenue. En particulier si vous
trouvez des erreurs dans le test ou même des fautes
d'orthographe (ce n'est pas mon fort)
Merci
http://www.reseau-emploi.com/tests/t...iries-java.php
Salut,
10/12 (erreur sur les questions 5 et 11, mais je ne suis pas d'accord sur les réponses)
Je cache mes remarques pour ne pas gêner ceux qui voudrait passer le test :
a++(surligner le texte pour voir)
- Question 2 : J'aurais plutôt utiliser la méthode split()
- Question 5 : Je n'aime pas trop cette "affirmation" : "Il peut parfois être judicieux de demander directement le lancement du garbage collector"
Pour moi le GC ne devrait jamais être appellé...
Et la réponse est "fausse", ce n'est pas Runtime.gc() mais Runtime.getRuntime().gc().
De plus la réponse System.gc() est correcte puisqu'il s'agit d'un appel vers Runtime.getRuntime().gc()
- Question 8 : Je ne comprend pas ce que tu veux dire par "La classe Timer est protégée d'un point de vu multi-threading." ?
- Question 11 : La réponse peut varier selon l'implémentation.
Math.cos() peut varier selon l'implémentation et peut donc potentiellement renvoyer des valeurs légèrement différentes d'une JVM à l'autre. Par contre elle peut bénéficier de certaines optimisations de la machine hôte (comme des instructions du processeur).
StrictMath.cos() utilise quand à elle la librairie fdlibm qui garantit un résultat identique quelque soit la JVM ou la plateforme en dépit des performances...
Par contre il est vrai que sur la JVM 6.0 de Sun Math.cos() renvoit vers StrictMath.cos(), mais ce n'est pas une obligation pour toutes les JVM et ce ne sera pas forcément toujours le cas, et il existe une RFE qui demande que cela soit changer :
http://bugs.sun.com/bugdatabase/view...bug_id=5005861
D'abord, merci pour le test !
Voici mes remarques
Question 2 : D'accord avec abiGuda. Et meme j'eviterai la solution proposée, pas pratique à utiliser et gourmande en memoire et vitesse.
Question 5 : Pas d'accord avec la reponse proposée, qui est fausse (ou incomplète). D'autre part, la derniere phrase de la javadoc de la methode en question indique clairement qu'une autre reponse est valide et usuelle.
Question 8 : Je suis d'accord avec abiGuda, c'est pas tres clair.
Question 11 : La question est fausse. Il est impossible de repondre étant donné les specifications des classes et methodes proposées. Il est meme probable que la reponse sugérée soit fausse en fonction de l'implémentation de la vm.
Merci pour les premieres remarques...
je verrai comment ameliorer tout cela ce soir...
11/12, je me suis epate tout seul .. mais en gros je rejoins adiGuba sur la plupart des points ..
Je me suis plante sur l'histoire du cosinus mais j'avais repondu au pif pour celle la n'ayant aucune idee donc c'est normal.
Bulbo
Envoyé par bulbo
11/12, je me suis epate tout seul .. mais en gros je rejoins adiGuba sur la plupart des points ..
Je me suis plante sur l'histoire du cosinus mais j'avais repondu au pif pour celle la n'ayant aucune idee donc c'est normal.
Bulbo
il faut vraiment que je corrige cette histoire de cosinus... parce que la
reponse depend de la version de la JRE...
Tu peux donc estimer avoir tout fait juste...
Je vais remplacer ou modifier cette question...
Quand je reponds au pif je preferre considerer que j'ai faux au contraireje ne fais pas ca quand je developpe et heureusement
Bulbo
10/12:
Il m'a dit que System.gc() est faux alors qu'elle existe bien
(http://java.sun.com/j2se/1.4.2/docs/...ng/System.html)
12: J'ai mis s.replaceAll("\\", "back"), il me dit que la réponse est s.replaceAll("\\\\", "back"). ah bon??
Jai mis au hasard pour la question 11 car je ne connaissais pas cette classe StrictMath.
Oui, car le \ est un caractère spécial à la fois pour le compilateur et pour les regexp.
Pourquoi dois-je doubler/quadrupler le caractère anti-slash ('\') ?
a++
Ca tu l'apprends en aidant du newbie sur le forum. Java interprete la String une premiere fois donc si tu ecris "\\" dans la string que tu passes au Pattern c'est comme si il y avait seulement "\", comme dans le langage des regexp "\" est un escape caractere il faut lui meme l'escaper (et hop un neologisme) donc besoin d'un nouveau "\" dans la regexp, qui se traduit par "\\" dans la string d'ou l'ecriture "\\\\".
Quand je dis que c'est pourri on me dit meuh non c'est tout a fait normal
[Edit] grilled by adiGuba [/Edit]
Bulbo
Merci pour ces précisionspour les regexp
J'ai eu 15/16 pour l'autre test JAVA.
J'ai fait le tour des premieres remarques
Question 2 : J'aurais plutôt utiliser la méthode split()
> je ne suis pas persuade que ce soit une bonne idee...
A mon avis (sans avoir teste), c'est plus lent que la solution
proposée. Les regex, c'est un peu lourd pour faire une chose
si simple.
Question 5 : Je n'aime pas trop cette "affirmation" : "Il peut parfois être judicieux de demander directement le lancement du garbage collector"
Pour moi le GC ne devrait jamais être appellé...
> j'ai supprimé le mot judicieux source de la possible polémique.
Cependant, c'est réellement ce que je pense... D'ailleurs si
ce n'était jamais judicieux, pourquoi proposer cette fonction ???
Un exemple : appeler le gc à un moment ou on sait que son application
n'aura rien à faire pendant un certain temps et qu'il y a pas mal
de choses à nettoyer...
Et la réponse est "fausse", ce n'est pas Runtime.gc() mais Runtime.getRuntime().gc().
De plus la réponse System.gc() est correcte puisqu'il s'agit d'un appel vers Runtime.getRuntime().gc()
> j'ai corrigé la question. Merci
* Question 8 : Je ne comprend pas ce que tu veux dire par "La classe Timer est protégée d'un point de vu multi-threading." ?
> si tu connaissais bien la classe Timer, tu verrais ce que cela
veut dire... non ?
* Question 11 : La réponse peut varier selon l'implémentation.
Math.cos() peut varier selon l'implémentation et peut donc potentiellement renvoyer des valeurs légèrement différentes d'une JVM à l'autre....
> La question est effectivement incorrecte... je l'ai changé. Merci
15/16 à l'autre test, c'est vraiment un très bon score.Merci pour ces précisionspour les regexp
J'ai eu 15/16 pour l'autre test JAVA.
Tu t'es planté sur quoi ?
Arf, une erreur très bête: sur le nombre d'instantiations de la classe Point (j'avais mis 4 au lieu de 5) Je ne sais plus quel est le numéro de la question.
@+
En terme de nombre d'objets créés, StringTokenizer est de loin plus gourmand.
En terme de nombre de lignes de code, une solution avec split est plutot econome.
Si ca peut finir de te convaincre, voici un extrait de la javadoc de StringTokenizer
Justifier un appel au gc(), c'est compliqué et à tous les coups source de polémique.Question 5 : Je n'aime pas trop cette "affirmation" : "Il peut parfois être judicieux de demander directement le lancement du garbage collector"
Pour moi le GC ne devrait jamais être appellé...
> j'ai supprimé le mot judicieux source de la possible polémique.
Cependant, c'est réellement ce que je pense... D'ailleurs si
ce n'était jamais judicieux, pourquoi proposer cette fonction ???
Un exemple : appeler le gc à un moment ou on sait que son application
n'aura rien à faire pendant un certain temps et qu'il y a pas mal
de choses à nettoyer...
Dans l'exemple que tu donnes, tu supposes que le gc ne va pas être fait tout seul, qu'il faut aider la vm à le faire. Mais en fait, on en sait rien.
C'est sympa d'aider un peu le systeme, mais ecrire du code inutile, c'est aussi une source d'erreur.
En d'autre termes, la classe Timer est thread-safe.
Et dans plus de 90% des cas l'appel du GC sera mal placé... et là on a deux solutions :
- Soit l'appel du GC est ignoré par la JVM et ce n'est plus que du code inutile.
- Soit le GC effectue un Full GC couteux et pas forcément adéquat, ce qui peut poser des problème de performance si c'est utiliser de manière abusive.
Par exemple, voici un cas typique d'un programme dont les appels explicites au GC provoquait des performances minables : Difference de performances Unix/Windows d'un programme?
Pour moi les appels explicites au GC sont à bannir...
a++
a++
Je savais bien que cela allait faire polemique
Perso, j'ai ameliorer les performances d'une appli en faisant appel
au gc a un moment ou je savais que le serveur allait etre tranquille
un petit moment et qu'il y avait pas mal d'objets a nettoyer...
Un autre interet peut etre aussi de forcer un gc a un moment ou l'utilisateur
n'utilise pas une application... Cela permet d'ameliorer le ressenti de la
vitesse par l'utilisateur alors meme que l'application est en fait plus lente...
(On ralenti a un moment ou il ne s'en rend pas compte)
Bref, meme si de facon general, l'appel au gc est devenu avec les nouvelles
jvm une mauvaise idee...
Il est parfois interessant de l'utiliser et vous devriez etre moins tranche
sur vos avis.
C'est juste que dans la plupart des cas que j'ai rencontré l'appel au GC est contre-productif.
En général si on a vraiment besoin d'optimiser le GC il vaut mieux le tuner (lire : Le garbage collector par Gfx -- mais cela sort de mes compétences).
Comment as-tu vérifier les différences de perfs entre tes deux programmes ? As-tu utiliser -verbose:gc pour déterminer le moment du passage du GC ?
A noter que tu peux également utiliser -XX:+DisableExplicitGC pour désactiver tout les appels explicites au GC...
a++
Je bosse depuis quelques années sur un serveur de données avec derrière des bases de données qui peuvent monter à 60Go.
Alors on a toujours le soucis d'améliorer les performances et forcément
on s'est intéressé au GC et à ses options...
(beaucoup d'allocation d'objets avant que ceux-ci ne soient descendu
en base de données)
Pour les perfs... on fait des tests grandeurs natures maintes fois répétés...
Résultats....
Pour ceux qui ont fait le test...
il y a maintenant suffisament de participants pour comparer votre
perf à la perf moyenne (note moyenne : 7.3/12, la gaussienne commence
à se dessiner)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager