Discussion :

[reseau-emploi]

Bonjour,

j'ai mis en place un test de compétence Java, j'aimerais
bien avoir un retour de quelques personnes qui s'y connaissent
bien en java... (c'est également mon cas, mais bon une boulette
est vite arrivée et on peut toujours améliorer ce qui a été fait

-http://www.reseau-emploi.com/tests/tests-competence.php
(puis cliquer sur Java)

Merci d'avance pour vos remarques...

(note : pour lancer le test, vous devez avoir un plug-in java relativement
à jour ce qui devrait être le cas des personnes visitant se forum !)

[eclesia]

resultat : 10/16

2 erreurs sur faute d'attention, (pas vue qu'une variable était pas instanciée)
4 autres normales vu mon niveau théorique pitoyable (c'est le defaut d'être un autodidact)

remarques :
- une petite question sur les générics serait pas mal, ca montre que la personne ce tient a jour.
- la question sur le fichier .class, les reponses 1 et 2 sont tres proches je trouve, bianire toute plateforme ou binaire source ... a reformuler je pense

[reseau-emploi]

resultat : 10/16

2 erreurs sur faute d'attention, (pas vue qu'une variable était pas instanciée)
4 autres normales vu mon niveau théorique pitoyable (c'est le defaut d'être un autodidact)

remarques :
- une petite question sur les générics serait pas mal, ca montre que la personne ce tient a jour.
- la question sur le fichier .class, les reponses 1 et 2 sont tres proches je trouve, bianire toute plateforme ou binaire source ... a reformuler je pense

tu as raison pour les générics... je vais y réfléchir... à moins que tu n'ais une
idée de question...

Sinon, je suis d'accord pour la question sur le .class ... je vais
la modifier
(note : l'ordre des réponses est tiré aléatoirement )

[reseau-emploi]

j'ai modifié la question sur le .class

merci pour la remarque

[reseau-emploi]

resultat : 10/16

2 erreurs sur faute d'attention, (pas vue qu'une variable était pas instanciée)

En fait 10/16 c'est déjà un bon niveau car le test est difficile.
Et le coup de la variable pas instanciée est particulièrement vachard

[®om]

J'ai eu 13/16.

Je me suis trompé à la question 2 (j'avais oublié un truc dans la boucle ^^).

Également à la question 5, mais là, il faut choisir la réponse fausse, il y en avait 2 ("Le programmeur peut forcer le lancement du Garbage Collector" est fausse également... System.gc() n'offre aucune garantie que le gc sera lancé).

Et enfin à la question 13 (j'aurai du lire plus attentivement le code o_O).

[reseau-emploi]

Également à la question 5, mais là, il faut choisir la réponse fausse, il y en avait 2 ("Le programmeur peut forcer le lancement du Garbage Collector" est fausse également... System.gc() n'offre aucune garantie que le gc sera lancé).

j'ai modifié la réponse:"Le programmeur peut demander le lancement du Garbage Collector",
merci

[Razgriz]

J'ai eu 12/16.

C'est vrai qu'une question sur les génerics serait interressante (déclaration générique de tableaux, ...)

J'ai fait une faute conne c'est à l'affichage du compteur (celui qui fait modulo 5 == 4) j'ai oublié qu'on repassait une fois dans la boucle...

Si je peux faire uen sugestion par contre j'enlèverrai la question avec la classe Vector, cette classe est obsolète et n'a plus de raison d'être que de fonctionner avec de vielles appli dont le code n'a pas été encore modifié.

Sino j'ai quelques stress : La question avec LinkedList, qui recherche un élément et le vire s'il le trouve. Cette méthode ne peut-elle pas lancer une NoSuchElementException? Parce que si l'élément est supprimé entre le test est la suppression par itérateur, on va pas le trouver... Et LinkedList n'étant pas thread-safe, ça risque d'arriver non?

Sinon je ne comprend pas pourquoi il y a 5 instances de crées avec les Points.
On crée p1 => 2 instances : p1 et centerPoint
On crée p2 => + 1 instance : p2 (centerPoint de p2 vient écraser l'ancien centerPoint de p1).
Donc on a bien 3 instances au final non? J'ai peut-être ma compris la question...

[adiGuba]

14/16

Je me suis trompé sur le modulo dans la boucle (les maths et moi ) et sur le nombre d'instance de Point (je n'avais pas vu que centerPoint était static et initialisé)

Si je peux faire uen sugestion par contre j'enlèverrai la question avec la classe Vector, cette classe est obsolète et n'a plus de raison d'être que de fonctionner avec de vielles appli dont le code n'a pas été encore modifié.

Et surtout la différence peut être assez infime et vraiment sensible que sur de grande quantité de données...

Sino j'ai quelques stress : La question avec LinkedList, qui recherche un élément et le vire s'il le trouve. Cette méthode ne peut-elle pas lancer une NoSuchElementException?

Le NoSuchElementException peut bien être levée par la méthode next() de l'itérator, mais seulement dans le cas où on fait un appel à next() sans vérifier la valeur de retour de hasNext() (ce qui n'est pas le cas ici).

Parce que si l'élément est supprimé entre le test est la suppression par itérateur, on va pas le trouver... Et LinkedList n'étant pas thread-safe, ça risque d'arriver non?

Dans ce cas là cela provoque un ConcurrentModificationException : c'est la règle des Iterator, on ne peut pas modifier une collection pendant son parcours (sauf si on utilise l'itérator pour cela).

Sinon je ne comprend pas pourquoi il y a 5 instances de crées avec les Points.
On crée p1 => 2 instances : p1 et centerPoint
On crée p2 => + 1 instance : p2 (centerPoint de p2 vient écraser l'ancien centerPoint de p1).
Donc on a bien 3 instances au final non? J'ai peut-être ma compris la question...

Il y a bien 5 instances de créées :

• centerPoint au chargement de la classe (attribut static)
• p1 et centerPoint dans le premier new
• p2 et centerPoint dans le second new

Bien sûr comme centerPoint est créé 3 fois, deux de ses références seront supprimés et il ne restera que 3 objets, mais en tout on en aura bien créé 5...




Sinon, deux remarques concernant les Q/R :

• Une assez général : les noms d'attributs de la forme m_x font très " C++ "... En Java on utiliserait plutôt x tout simplement
• Dans la question 6 :

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  package test;
   
  public class A {
  	protected int m_x = 0;
  	private int m_y = 0;
  }

  La réponse est "incomplète" (en gras ce qu'il manque) :
  m_x est accessible par les sous classes de A et par toutes les classes du package test, et m_y n'est accessible que par la classe A.

a++

[reseau-emploi]

C'est vrai qu'une question sur les génerics serait interressante (déclaration générique de tableaux, ...)

Pour les génériques... j'ai un peu la flemme

Si je peux faire uen sugestion par contre j'enlèverrai la question avec la classe Vector, cette classe est obsolète et n'a plus de raison d'être que de fonctionner avec de vielles appli dont le code n'a pas été encore modifié.

Pleins de petit jeunes l'utilisent car ils ne savent pas qu'il vaut mieux ne plus l'utiliser... Ainsi que des vieux de la vieille en java qui ne se remettent pas
en question.
C'est en fait la raison de vivre de cette question

Sino j'ai quelques stress : La question avec LinkedList, qui recherche un élément et le vire s'il le trouve. Cette méthode ne peut-elle pas lancer une NoSuchElementException? Parce que si l'élément est supprimé entre le test est la suppression par itérateur, on va pas le trouver... Et LinkedList n'étant pas thread-safe, ça risque d'arriver non?

Non car la fonction remove ne renvoie pas cette exception !
(cf spec java)

Sinon je ne comprend pas pourquoi il y a 5 instances de crées avec les Points.
On crée p1 => 2 instances : p1 et centerPoint
On crée p2 => + 1 instance : p2 (centerPoint de p2 vient écraser l'ancien centerPoint de p1).
Donc on a bien 3 instances au final non? J'ai peut-être ma compris la question...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 public class Point {
 
  private static Point centerPoint = new Point();  // +1 car static 
 
  private int m_x = 0;
  private int m_y = 0;
 
  public Point() {   
  }
  public Point(int x, int y) {
    m_x = x;
    m_y = y;
    centerPoint = new Point(); // +1 +1 (appelé deux fois)
  }
 
  public static void main(String[] args) {
    Point p1 = new Point(1,1);  // +1
    Point p2 = new Point(2,2);  // +1
  }
}

Donc 5 en tout

[reseau-emploi]

• Une assez général : les noms d'attributs de la forme m_x font très " C++ "... En Java on utiliserait plutôt x tout simplement
• Dans la question 6 :

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  package test;
   
  public class A {
  	protected int m_x = 0;
  	private int m_y = 0;
  }

  La réponse est "incomplète" (en gras ce qu'il manque) :
  m_x est accessible par les sous classes de A et par toutes les classes du package test, et m_y n'est accessible que par la classe A.

a++

Pour m_x c'est parce que j'ai toujours trouvé que c'était
une bonne habitude... donc je l'applique perso en java sasn plus
m'en rendre compte

La réponse est "incomplète" : oui mais c'était fait exprès
Comme quoi je suis un sadique... C'est bien la bonne réponse,
les autres étant fausses et celle-la exacte mais pas complête.

[adiGuba]

La réponse est "incomplète" : oui mais c'était fait exprès
Comme quoi je suis un sadique...

Ben pas tant que ca en fait : je suis sûr qu'il y a un grand nombre de personne qui ignore que les attributs protected sont accessible par les autres classes du même package...


a++

[reseau-emploi]

Ben pas tant que ca en fait : je suis sûr qu'il y a un grand nombre de personne qui ignore que les attributs protected sont accessible par les autres classes du même package...


a++

La, tu n'as pas tord...
au fait, félicitation pour ton score... il est excellent vu la difficulté
du test...

[CyberChouan]

14/16

Décidémment, elle est fourbe cette question sur la boucle... et j'ai d'ailleurs un peu de mal à comprendre pourquoi on repasse par l'incrémentation de i puisqu'on a 11 > 10... Mais bon, passons!

Et sinon, l'autre erreur est sur le nombre d'instances créées de "Point". Je trouve la question un peu ambigüe, et je l'avais interprêtée comme "combien d'instance différentes a-t'on à la fin de l'exécution du code": on a bien créé 5 instances, mais le milieu ayant été écrasé deux fois, on n'a plus que 3 instances distinctes référencées, les autres étant perdues dans les méandres de la JVM et appelées à être impitoyablement détruites par le GC...

[adiGuba]

Décidémment, elle est fourbe cette question sur la boucle... et j'ai d'ailleurs un peu de mal à comprendre pourquoi on repasse par l'incrémentation de i puisqu'on a 11 > 10... Mais bon, passons!

Par ce que l'incrémentation se fait à la fin du bloc, juste avant de réévaluer la condition :

1. i = 4, et la condition du if est alors vrai.
2. i passe alors à 11 (après multiplication et soustraction).
3. i est incrémenté par le for i = 12
4. i > 10 et donc la condition n'est plus vrai, la boucle s'arrête

a++

[CyberChouan]

Par ce que l'incrémentation se fait à la fin du bloc, juste avant de réévaluer la condition :

Oui... c'est logique! Ca fait des années que j'utilise les boucles 'for' et je ne m'étais jamais posé cette question existencielle. Je me coucherai un peu moins bête ce soir.

Merci adiGuba d'avoir éclairé ma lanterne

[leminipouce]

Bon ben voilà, il en fallait bien un qui passe en dessous de la barre des 10... Je n'ai eu que 9 !

A ma décharge, plusieurs remarques faîtes ici (je me cherche des excuses là).
La première... l'inattention évidement. Quand un Point n'est pas instancié...
Ensuite le coup du GC -j'ai pas vraiment fait la différence entre demander et forcer... et vu que 2 étaient fausses il fallait bien en choisir une !
Il ne me semblait pas qu'on passait par le finally quand il y a un return dans le catch. Alors que c'est là tout son intérêt ! -Des fois c'est bien aussi de réfléchir 2 secondes quand on fait un test.
Pour les instances crées, si j'avais mieux lu... (sans aucune mauvaise foix) j'étais bien d'accord sur le fait que 5 sont instanciées, mais vu qu'on en garde que trois à la fin... !
Je ne suis pas forcément très alèse avec les Threads. Pour faire le "dead lock" on s'y prend comment ? Deux threads, un qui appelle incV1V2() et un autre qui appelle mulV1V2() ?
Je me suis laissé fourvoyé par les interfaces. Je n'y ai, de mémoire, jamais déclaré d'attributs...

[bassim]

Je vais me sentir tout petit là 5/16

pour la question de la valeur du i ,j'ai mis 11 .merci Adibuga pour l'explication .
Le nombre d'instances ,j'ai mis 4 au lieu de 5. faute d'inattention ,j'ai pas vue la première instanciation .
les questions sur les threads ,je n'ai pas repondu du moment que je n'ai jamais pratiqué.
le nombre d'erreurs de compilation (je ne sais plus quel numero), j'aimerais bien qu'on m'explique.
l'exception qui ne survenait jamais ,j'ai répondu presque par hasard .

Il ne me semblait pas qu'on passait par le finally quand il y a un return dans le catch. Alors que c'est là tout son intérêt ! -Des fois c'est bien aussi de réfléchir 2 secondes quand on fait un test.

j'ai pensé la même chose !

Je me suis laissé fourvoyé par les interfaces. Je n'y ai, de mémoire, jamais déclaré d'attributs...

moi aussi !

Pour quelqu'un qui a commencé avec Java depuis 1 an ,je pouvais pas faire mieux

[adiGuba]

Je ne suis pas forcément très alèse avec les Threads. Pour faire le "dead lock" on s'y prend comment ? Deux threads, un qui appelle incV1V2() et un autre qui appelle mulV1V2() ?

Oui c'est ca : comme les bloc synchronized ne sont pas dans le même ordre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
synchronized(verrou1) {
	synchronized(verrou2) {
		// ...
	}
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
synchronized(verrou2) {
	synchronized(verrou1) {
		// ...
	}
}

On peut se retrouver dans un cas où un thread perd la main entre les deux demandes de verrou, par exemple :

1. Un thread appelle incV1V2() (1er code) et un autre qui appelle mulV1V2() (2eme code).
2. Le premier thread s'exécute et récupère le verrou1.
3. Hasard de l'ordonnanceur : le thread 2 prend la main et il récupère le verrou2.
4. Le thread 2 entre en attente car il ne peut pas prendre le verrou1 (déjà pris par le thread 1).
5. Le thread 1 entre lui aussi en attente car il ne peut pas prendre le verrou2 (déjà pris par le thread 2).

Bref les deux threads possèdent un verrou et attendent le second. Donc les deux threads s'attendent mutuellement dead lock.

C'est particulièrement dangereux car cela dépend de l'ordonnancement et le code peut très bien fonctionner (et dans 99.99% des cas cela marche parfaitement en DEV mais plus lorsqu'on passe en PROD )

Je me suis laissé fourvoyé par les interfaces. Je n'y ai, de mémoire, jamais déclaré d'attributs...

On peut seulement y déclarer des constantes (attributs public static final).

D'ailleurs le code suivant est tout à fait correct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public interface MonInterface {
	int X = 0;
 
	void method();
}

Et est strictement équivalent à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
interface MonInterface {
	public static final int X = 0;
 
	public abstract void method();
}

Les attributs d'une interfaces sont obligatoirement public static final (et implicitement si absent).
Les méthodes d'une interface sont obligatorement public abstract.

le nombre d'erreurs de compilation (je ne sais plus quel numero), j'aimerais bien qu'on m'explique.

Les classes internes static ne sont pas lié à une instance de la classe conteneur, et donc elles ne peuvent accéder directement qu'aux attributs static (et il n'y en avait qu'un sur les 3)

a++

[bassim]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Qu'obtenez vous si compilez et éxecutez ce code

Pourquoi une erreur de compilation ?
p.dump(); devrait etre detecté aprés exécution comme NullPointerException non ?!!!!

J'ai foiré à la première question aussi ,quelle honte