Discussion :

[need2learn]

Bonjour,

Je suis en préparation du SCJP.

Voici quatre questions dont je ne comprends pas les réponses données par le livre.

Quelqu'un peut-il me corriger ou me dire si j'ai choisi la bonne réponse ?

Question.1

Code :

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

1
2
package sun.scjp;
public enum Color { RED, GREEN, BLUE }

Code :

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

1
2
3
4
5
6
7
package sun.beta;
// insert code here
public class Beta {
Color g = GREEN;
public static void main( String[] argv)
{ System.out.println( GREEN); }
}

The class Beta and the enum Color are in different packages.
Which two code fragments, inserted individually at line 2 of the Beta declaration, will allow this code to compile? (Choose two.)
A. import sun.scjp.Color.*;
B. import static sun.scjp.Color.*;
C. import sun.scjp.Color; import static sun.scjp.Color.*;
D. import sun.scjp.*; import static sun.scjp.Color.*;
E. import sun.scjp.Color; import static sun.scjp.Color.GREEN;
Answer: CE

Pour quoi pas D ?

___________________________________________________

Question.2
Given:

Code :

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

1
2
3
4
5
6
7
public String makinStrings() {
String s = “Fred”;
s = s + “47”;
s = s.substring(2, 5);
s = s.toUpperCase();
return s.toString();
}

How many String objects will be created when this method is invoked?
A. 1
B. 2
C. 3
D. 4
E. 5
F. 6
Answer: C

Pour moi la réponse est D, car 4 objets String sont créés à la ligne 2, 3, 4 et 5 ?

___________________________________________________

Question.3
Given classes defined in two different files:

Code :

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

1
2
3
4
package packageA;
public class Message {
String getText() { return “text”; }
}

and:

Code :

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

1
2
3
4
5
6
7
package packageB;
public class XMLMessage extends packageA.Message {
String getText() { return “<msg>text</msg>”; }
public static void main(String[] args) {
System.out.println(new XMLMessage().getText());
}
}

What is the result of executing XMLMessage.main?
A. text
B. <msg>text</msg>
C. An exception is thrown at runtime.
D. Compilation fails because of an error in line 2 of XMLMessage.
E. Compilation fails because of an error in line 3 of XMLMessage.
Answer: E

Moi je dirais plutôt la réponse B !?

___________________________________________________

Question.4
Given the command line java Pass2 and:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public class Pass2 {
public void main(String [] args) {
int x=6;
Pass2 p = new Pass2();
p.doStuff(x);
System.out.print(” main x = “+ x);
}
 
void doStuff(int x) {
 System.out.print(” doStuffx = “+ x++);
 }
 }

What is the result?
A. Compilation fails.
B. An exception is thrown at runtime.
C. doStuffx = 6 main x = 6
D. doStuffx = 6 main x = 7
E. doStuffx = 7 main x = 6
F. doStuffx = 7 main x = 7
Answer: B

Moi j'aurai dit C !?

Merci d'avance pour votre aide.

[Uther]

1> Je me serais aussi fait avoir aussi. On dirait que les enums ne sont pas importé avec un ".*".

2> Je ne suis pas sur mais je crois que la Java optmise le "substring" et ne crée pas de nouvel objet, il se contente de modifier les champs "offset" et "size" interne de l'objet.

3> La visibilité de "getText" n'a pas été déclarée il est donc dit "package private". Il n'est donc pas hérité et donc pas surchargeable par les classes d'un autre package.
Heu non je dis une betise, getText n'étant pas visible il est redéclaré(mais pas surchargé).
B me parait correct.

4> le main n'est pas "static"

[need2learn]

Pour la Question.2, voici une partie du cours de préparation :

Code :

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

1
2
3
4
5
6
String s1 = "spring ";
String s2 = s1 + "summer ";
s1.concat("fall ");
s2.concat(s1);
s1 += "winter ";
System.out.println(s1 + " " + s2);

What is the output? For extra credit, how many String objects and how many reference variables were created prior to the println statement?

Answer: The result of this code fragment is spring winter spring summer.
There are two reference variables, s1 and s2. There were a total of eight String objects created as follows: "spring", "summer " (lost), "spring summer", "fall" (lost), "spring fall" (lost), "spring summer spring" (lost), "winter" (lost), "spring winter" (at this point "spring" is lost). Only two of the eight String objects are not lost in this process.

[hwoarang]

Heu non je dis une betise, getText n'étant pas visible il est redéclaré(mais pas surchargé).
B me parait correct.

J'ai testé et à part un warning qui precise que la methode n'etend pas getText original (ce qui est normal vu qu'il n'est pas visible), j'obtiens bien le comportement B.

Pour la Question.2, voici une partie du cours de préparation :

Code :

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

1
2
3
4
5
6
String s1 = "spring ";
String s2 = s1 + "summer ";
s1.concat("fall ");
s2.concat(s1);
s1 += "winter ";
System.out.println(s1 + " " + s2);

Ca ne correspond pas au probleme puisque c'est le cas particulier de substring qui nous interesse. Et comme les String sont immutable, elles sont partagées donc faire substring ne crée pas une nouvelle String.

[thelvin]

Pour les questions 1 et 3, je ne sais pas. C'est peut-être une question de subtilité ou de version du langage. Il faudrait tester avec différents compilateurs. De toute façon on est aux cas aux limites. Des questions stupides.

Pour la question 2, vous vous plantez les gens.
Oui, substring() va créer un nouvel objet String, évidemment ! Il n'est pas obligé de le faire si c'est un substring qui produit la même chaîne que celle qui est appelée. Et on peut penser qu'il n'est pas obligé de le faire non plus pour produire la chaîne vide. Mais dans les autres cas, il n'a pas le choix ! Oui, le tableau de caractère, est probablement partagé entre les objets Strings. Mais les objets eux-mêmes sont distincts.

Le piège, c'est comment la question est tournée. Combien de String seront créées lors de l'invocation de la méthode ?

La première ligne, String s = "Fred"; assigne une String littérale. Donc une constante. Elle a donc été créée bien avant l'appel de la fonction. Au plus tard elle a été créée au chargement de la classe. Mais ça peut aussi dater de bien avant, si la constante est utilisée ailleurs, plus tôt, dans le programme.

Donc,
- la première ligne ne crée pas de String.
- la deuxième fait une concaténation, de non-constantes. Dans ces cas-là il y a création de String.
- la troisième fait un substring qui est bien obligé de créer un nouvel objet pour avoir les extrémités demandées.
- la quatrième fait un toUpperString sur une chaîne qui n'est pas déjà uppercase, donc bien obligé de créer encore une String
- la cinquième appelle toString() sur l'objet qui est déjà une String. C'est connu, dans ce cas la String se renvoie elle-même, elle n'en crée pas une autre.

=> 3 String créées.

[Uther]

Oui en effet en relisant, je me suis rendu compte de l'erreur. Je n'avais pas vu la subtilité du "when this method is invoked".

Le substring() crée forcément un nouveau String sinon, ça casserait l'immuabilité de la classe. C'est juste qu'il n'alloue pas un nouveau char[] interne car il réutilise celui de la String d'origine.

[Uther]

Bon la question 1 me taraudait, car je trouvait bizarre que un "*" n'importe pas les enum. J'ai testé, et ça marche très bien avec la réponse D.

Donc ne te fie pas trop à ce test. Les réponse aux question 1 et 3 sont fausses et je doute que ça soit un problème spécifique d'implémentation, c'est le genre de chose qui doivent être bien spécifiés.

[Laurent.B]

Bonjour,

J'ai testé, et ça marche très bien avec la réponse D.

Moi aussi j'ai testé et ça fonctionne des versions 5 à 7 de Java donc la réponse est clairement erronée.

Pour la 2, je peux me tromper mais non, ce n'est pas 3 mais 4 String créées. Si on teste ce code en mode debug, on voit bien qu'il y a 4 String créées.
A la limite, si le compilateur fait une optimisation en constatant que la chaîne dans son été originel n'est jamais utilisée et qu'il initialise directement avec le résultat de la seconde instruction alors oui, ça pourrait ne faire que 3 instances de String créées mais bon, rien n'indique cela.

[thelvin]

Pour la 2, je peux me tromper mais non, ce n'est pas 3 mais 4 String créées. Si on teste ce code en mode debug, on voit bien qu'il y a 4 String créées.
A la limite, si le compilateur fait une optimisation en constatant que la chaîne dans son été originel n'est jamais utilisée et qu'il initialise directement avec le résultat de la seconde instruction alors oui, ça pourrait ne faire que 3 instances de String créées mais bon, rien n'indique cela.

Relis ma réponse. Il y a 3 Strings créées quand la méthode est invoquée. C'est ça la question qui est posée, quand la méthode est invoquée. La chaîne "Fred" est créée bien avant.

[Laurent.B]

Relis ma réponse. Il y a 3 Strings créées quand la méthode est invoquée.

Mais moi je dis que non mode débug à l'appui. Et puis je ne vois pas pourquoi elle serait considérée comme une constante... Il n'y a même pas le mot clé final devant. Enfin bon, j'ignore qui a définitivement raison mais ce niveau de subtilité m'échappe...

Pour la 3, c'est la réponse B et non E (vérifié), sauf si on prend en compte le fait que les caractères “” ne sont pas les bonnes double quote ". Seulement faudra expliquer comment on peut faire fonctionner la 2...
Mauvaise saisie, copié/collé transformé à la volée, erreur présente à l'origine ?

[thelvin]

Mais moi je dis que non mode débug à l'appui.

Et comment ton mode debug prouve-t-il le contraire ?

Et puis je ne vois pas pourquoi elle serait considérée comme une constante...

Plus exactement une expression constante, j'avais fait un léger abus de langage. Et c'en est une parce que toute chaîne littérale est une expression constante.
Or toute expression constante sera toujours pré-évaluée par le compilateur. Donc toute expression constante de type String le sera. Il se trouve également que ces Strings sont dites "internes," c'est-à-dire équivalentes au résultat d'un appel à String.intern(). Autrement dit, chacune est créée une seule fois, et partagée par toutes les classes qui s'en servent.

Enfin bon, j'ignore qui a définitivement raison mais ce niveau de subtilité m'échappe...

La chaîne "Fred" est toujours la même d'un appel à l'autre, vérifiable à l'aide de ce même mode debug. De plus, si on utilise ailleurs, dans une autre classe, mais plus tôt, une chaîne "Fred", on constate que dans les deux cas ce sera la même chaîne. Au moins dans le cas général, c'est-à-dire si on ne suppose pas que la constante n'a jamais été utilisée auparavant, c'est moi qui ait raison.
Ici le niveau de subtilité n'est pas très élevé, il s'agit simplement de ne pas polluer la JVM avec d'innombrables fois une String dont on savait dès compilation qu'elle serait utilisée et probablement réutilisée.

[Laurent.B]

Le mode débug me le prouve tout simplement parce que quand j'exécute le code, la chaine n'existe que lorsque j'ai passé la ligne de la déclaration. Je ne sais pas si c'est une preuve en soit mais pour moi ça reste une référence.

Ensuite, que cette chaine soit stockée pour ne plus avoir à être réinstanciée à chaque appel de la méthode, il me semble que c'est assez récent comme optimisation, je ne suis pas sûr que c'était le cas avant Java 5... Et cela ne veut pas dire que la chaine est existante avant même l'appel à la méthode qui en fait usage. D'ailleurs j'en serai vraiment très étonné. Si c'était le cas, ça pourrait poser de gros problèmes de performances et de ressources prises inutilement.
Enfin bon, je doute également que la question 2 s'appuie réellement sur ce genre de subtilités. Ce n'est en tous les cas pas l'exemple donné par nead2learn après qui peut en faire la preuve.

Enfin bref ! Si tu veux être sûr d'avoir raison donne des références, c'est mieux.

[hwoarang]

Oui, le tableau de caractère, est probablement partagé entre les objets Strings. Mais les objets eux-mêmes sont distincts.

Le piège, c'est comment la question est tournée. Combien de String seront créées lors de l'invocation de la méthode ?

Effectivement, j'ai pensé au tableau de caracteres (vu que c'est ca qui prend de la place) mais l'objet string est bien créé. La prochaine fois, je lirais mieux la question meme si je trouve l'interet de celle-ci limité, surtout si on s'interesse à l'objet String plutot qu'au tableau de caracteres qu'il contient...

Le mode débug me le prouve tout simplement parce que quand j'exécute le code, la chaine n'existe que lorsque j'ai passé la ligne de la déclaration. Je ne sais pas si c'est une preuve en soit mais pour moi ça reste une référence.

Un petit bout de code (tres moche ) pour te convaincre :

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
 
   static String sav;
 
   public static void main(String[] args)
   {
      String fred = "FRED";
      String s = new String(fred);
      System.out.println(fred == s);
      System.out.println(fred == sav);
      if (sav == null)
      {
         sav = fred;
         main(args);
      }
   }

L'opérateur == verifie que les instances sont les memes. Si on execute ce code, on obtient :
false
false
false
true

[thelvin]

Pour l'internalisation des String, ben, la référence c'est String.intern(), je l'ai dit. On le trouve dans Java 1.4, avec un lien vers les JLS. Il n'y a pas de @since.

Mais pour la création de la String au chargement de la classe, ça en fait, c'est faux. Enfin, rien n'est garanti, mais il n'y a pas de raison de le penser et en pratique, effectivement, ce n'est pas au chargement de la classe, mais à la première utilisation de la constante. Et puis bon, c'est logique, de pas charger des String qui ne sont pas utilisées.
J'avais mémorisé les choses plus simplement qu'elles ne le sont.

C'est vrai qu'en y réfléchissant, la question devient ambiguë. "Lors de l'invocation de la méthode" ça pourrait être pris comme "la première fois que la méthode est invoquée." Et là, en principe, on devrait considérer qu'il y a création de quatre Strings.
Bon, ce n'est pas sûr, parce que la constante "Fred" pourrait avoir déjà été créée plus tôt, ailleurs, par une autre classe. Pourrait. Si c'était la chaîne vide, ou "test", ou "r", on penserait naturellement qu'elle a déjà été chargée par la bibliothèque de base. Mais "Fred", ça il y a peu de chances, il faudrait l'avoir fait soi-même, ailleurs.
Devant ces considérations, je me dis que j'aurais hésité à répondre entre trois et quatre : je pense toujours au cas général, et là j'aurais hésité entre cas général et cas probable, qui ont des réponses différentes.
D'un autre côté on pourrait débattre sur le sens de "création de String." C'est l'instruction d'obtention d'une String constante, elle est un peu particulière par nature, alors que les autres opérations font un simple new String().
Question ambiguë, donc.

[Laurent.B]

@hwoarang : Je ne pense pas avoir dit l'inverse de ce que tu indiques.

Bon, je pense qu'on est d'accord que la réponse à la 2, est sûrement la réponse D, donc 4 créations de String.
Sauf erreur d'interprétation, la spécification Java le confirme http://docs.oracle.com/javase/specs/...tml#jls-3.10.5
Cf. l'exemple Example 3.10.5-1. String Literals
Dans le contexte du SCJP, je pense que la réponse D est celle attendue.

Juste pour aller un peu plus loin dans cette analyse, en mode debug, si j'en crois l'évolution des id de String, je constate qu'il se crée également un certain nombre de String de façon sous-jacente.

Notamment, entre

Code :

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

String s = "Fred";

et

Code :

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

s = s + "47";

on passe de l'id 17 à 22. Alors que sur les instructions suivantes, l'incrément n'est que de 1 à chaque instruction. De plus, en inversant les instructions, on se rend compte que ce n'est pas en rapport direct avec ce que fait cette deuxième ligne...

Enfin bon, tout ça pour dire que le fait de connaître ces subtilités n'aura d'utilité que dans le cas de contraintes très fortes en terme de performance et de ressources mais dans le cas général, même si c'est intéressant, on s'en moque un peu.

[fr1man]

Moi j'aurais meme répondu E, pour 5 String créées :

Code :

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

1
2
3
4
5
6
7
8
 
public String makinStrings() {
String s = “Fred”; => une String créée, constante
s = s + “47”; => 2 String crées, une constante, plus le résultat de la concaténation
s = s.substring(2, 5); => une String créée
s = s.toUpperCase(); => une String créée
return s.toString();
}

[thelvin]

Moi j'aurais meme répondu E, pour 5 String créées

Ah oui, bonne remarque. Si "Fred" est créée à cette occasion, alors en principe "47" aussi, logique.

Sauf erreur d'interprétation, la spécification Java le confirme http://docs.oracle.com/javase/specs/...tml#jls-3.10.5
Cf. l'exemple Example 3.10.5-1. String Literals
Dans le contexte du SCJP, je pense que la réponse D est celle attendue.

Cette partie de la spec et cet exemple confirment que les Strings littérales ne sont pas créées plus d'une fois. Elle ne nous dit pas quand elles sont créées, ce qui peut se vérifier par la pratique, et finalement semble, c'est vrai, assez évident.

Juste pour aller un peu plus loin dans cette analyse, en mode debug, si j'en crois l'évolution des id de String, je constate qu'il se crée également un certain nombre de String de façon sous-jacente.

Notamment, entre

Code :

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

String s = "Fred";

et

Code :

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

s = s + "47";

on passe de l'id 17 à 22. Alors que sur les instructions suivantes, l'incrément n'est que de 1 à chaque instruction. De plus, en inversant les instructions, on se rend compte que ce n'est pas en rapport direct avec ce que fait cette deuxième ligne...

Ce sont des identifiants d'objet, pas forcément de Strings. Assez souvent, créer une nouvelle String nécessite de créer un nouveau char[], et la concaténation va en général créer un StringBuilder pour la générer, lui aussi possédant son propre char[], mutable donc impossible à partager.
Je ne m'explique pas pourquoi substring() génèrerait plus d'un objet, en principe il ne devrait pas. Il y a quelque chose qui m'échappe. Peut-être la méthode native System.arrayCopy() ?

Enfin bon, tout ça pour dire que le fait de connaître ces subtilités n'aura d'utilité que dans le cas de contraintes très fortes en terme de performance et de ressources mais dans le cas général, même si c'est intéressant, on s'en moque un peu.

Certes. Pas terribles, ces questions.