Un mémento des mots-clés du langage Java

Version imprimable

03/06/2013, 19h46
thierryler

Un mémento des mots-clés du langage Java

Bonjour,

Je vous propose un nouvel article intitulé « Un mémento des mots-clés du langage Java » et disponible à l'adresse suivante :
http://thierry-leriche-dessirier.dev...ots-cles-java/

L'article vous propose de télécharger un PDF gratuit à imprimer vous-même en recto verso.

Résumé : ce document présente les 53 mots réservés de Java, à l'aide de définitions et d'exemples simples. Il vous offre également un mémento et un livret à imprimer vous-même.

Comme toujours, les remarques sont les bienvenues.

Bonne lecture.
Thierry
10/06/2013, 10h23
Gugelhupf

Merci :ccool:

PS: J'ai remarqué quelques petites fautes, par exemple "Interface" au lieu de "interface". Ou sinon "Authorise" au lieu de "autorisé".
10/06/2013, 10h43
thierryler

@Gugelhupf: Merci c'est corrigé.

J'ai deux remarques:
pour 'this', j'aurais ajouté l'utilisation pour accéder à l'instance englobante dans les classes anonymes :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public class Mother() { public void process() { new Thread(new Runnable() { public void run() { Mother.this.doSomething(); } }).start(); } public void doSomething() { // ... } }
le modificateur de visibilité vide (package-private) n'est pas entre public et protected, mais entre protected et private.

12/06/2013, 11h06
thierryler

Effectivement... oups...

Faudrait lancer un sondage sur qui utilise "vide"...
12/06/2013, 16h18
Gugelhupf

thierryler, je n'oublierai jamais le jour où tu m'as aidé pour résoudre un problème de visibilité package.

Je pense que c'est un gros défaut de Java, cette visibilité ne devrait pas exister (devrait être "public" par défaut).

Merci :ccool:
12/06/2013, 16h56
thierryler

Ouais je m'en souviens, j'avais vraiment galéré pour trouver l'erreur à l'époque.

Petites erreurs

Bonjour,

J'ai relevé une typo : dans le § sur "for", la virgule est utilisée comme séparateur au lieu du point-virgule ; d'ailleurs, plus loin (§ sur le "break"), les boucles "for" sont correctement écrites.

Plus sérieux, ce qui me semble une erreur dans le § sur "synchronized" :

Code:

1
2
3
4
5
String s = "";
...
    synchronized (s) {
        ...
    }

On ne peut pas synchroniser des String sans risque de deadlock, le problème étant que les String ne sont pas des objets comme les autres, et ceci en revanche aurait marché :

Code:

1
2
3
4
5
Object o = new Object();
...
    synchronized (o) {
        ...
    }

Mais pas avec les String, car la JVM peut prendre la liberté de donner une instance de String qui existe déjà, on ne peut pas faire confiance à String s= ""; dans l'espoir d'obtenir une instance spécifique. Voir la spec. Java à ce sujet

Pour synchroniser des String, il faut donc :
-recourir à un wrappeur
-gérer la portée des String qui sont susceptibles d'être identiques (en tant qu'objet) de ceux qui doivent être considérés comme différents.

Voici 2 classes qui permettent de gérer un bloc de code qui assure une exclusion mutuelle sur des String :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
/**
 * A mutex, based on a string ID, safe for
 * synchronization for a given user context.
 * 
 * <h3>Usage</h3>
 * <pre>    MutextContext mutexContext = new MutextContext();
 *    ...
 *    
 *    String id = someObject.getCanonicalID(); // or whatever you want
 *    Mutex mutex = mutexContext.getMutex(id);
 *    synchronized(mutex) {
 *       ...
 *    }
 * </pre>
 * 
 * @see MutexContext
 */
public class Mutex {
 
	private final String id;
 
	Mutex(String id) {
		this.id = id;
	}
 
	public boolean equals(Object o) {
		if (o==null) {
			return false;
		}
		if (this.getClass()==o.getClass()) {
			return this.id.equals(o.toString());
		}
		return false;
	}
 
	public int hashCode() {
		return this.id.hashCode();
	}
 
	public String toString() {
		return this.id;
	}
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
import java.lang.ref.WeakReference;
import java.util.Map;
import java.util.WeakHashMap;
 
/**
 * Manages a set of mutexes unique in this context.
 *
 * <p>As mentionned in section 3.10.5 of the Java Language Spec 2.0,
 * "Literal strings within different classes in different packages
 * likewise represent references to the same String object."<br/>
 * This class allow to create a context in order to manage safe
 * string-based mutexes, that is to say without the inherent
 * conditions of the String class that can lead to a dead-lock.</p>
 *
 * <p>This class is not magic:<p>
 * <ul>
 *              <li>It's up to the user to create a context per domain to avoid
 *              ID collisions. The scope of such domain depends on the application.</li>
 *              <li>It can't avoid dead-lock due to programming (it only avoids
 *              the inherent possibility of dead-locks due to string usage)</li>
 * </ul>
 *
 * <p>A mutex doesn't have to be explicitly remove from this context,
 * it will be automatically removed after all references to it are
 * dropped.</p>
 *
 * @see Mutex
 */
public class MutexContext {
 
	// based on http://illegalargumentexception.blogspot.com/2008/04/java-synchronizing-on-transient-id.html
 
	private final Map<Mutex, WeakReference<Mutex>> mutexMap = new WeakHashMap<Mutex, WeakReference<Mutex>>();
 
	/**
         * Return a lockable mutex.
         *
         * @param id The string ID.
         *
         * @return A synchronizable object, unique in this context.
         */
	public Mutex getMutex(String id) {
		Mutex key = new Mutex(id);
		synchronized(mutexMap) {
			WeakReference<Mutex> ref = this.mutexMap.get(key);
			if (ref==null) {
				this.mutexMap.put(key, new WeakReference<Mutex>(key));
				return key;
			}
			Mutex mutex = ref.get();
			if (mutex==null) {
				this.mutexMap.put(key, new WeakReference<Mutex>(key));
				return key;
			}
			return mutex;
		}
	}
 
}

Tout commentaire bienvenu.

a+
Philippe

17/06/2013, 09h52
thierryler

@ppoulard: Très bonnes remarques. Problème de relecture pour la virgule. Et j'ai mis un Chien (Milou) pour le synchronized. Comme c'est juste un mémento, je n'ai pas fait un gros texte dessus mais ça mériterait d'être dans un billet de blog car c'est intéressante ton truc.
17/06/2013, 23h43
tchize_
Citation:
Envoyé par ppoulard

Bonjour,

Code:

1 2 3 4 5 String s = ""; ... synchronized (s) { ... }

On ne peut pas synchroniser des String sans risque de deadlock, le problème étant que les String ne sont pas des objets comme les autres, et ceci en revanche aurait marché :
J'apporte personellement la solution bourrin suivante mais moins verbeuse:
Code:

1 2 3 4 5 String s = "".intern(); ... synchronized (s) { ... }
Autre remarque: extends et super, ces mot clés bénéficieraient d'une clarification: il peuvent aussi être utilisé pour les generics:
Code:

1 2 3 public void method(List<? extends JComponent> composants); public void method2(List<? super JComponent> composants);
18/06/2013, 15h58
fpritchard
merci pour cet article.
J'ai aussi quelques remarques sur des détails :
- IV-A-1. class : dans l'exemple donné le mot class est écrit avec un C (majuscule) au lieu de c (minuscule)
- IV-B-2. char : ce n'est pas très utilisé (et c'est limité) mais il existe aussi la possibilité d'utiliser la notation octale:
  
  Code:
  
  char a = '\141'; // equivalent de char a = 'a';
  
  Il pourrait aussi y avoir les séquences d'échappement courantes: '\b', '\f', '\n', '\r', 't', '\'', '\"', '\\'
- IV-B-6. long : l'exemple donné est avec un int au lieu de long
- IV-D-1. private : il faudrait ajouter une accolade fermante } à la fin de l'exemple
- IV-F-3. switch : il est indiqué :
  
  Citation:
  
  Les switch n'acceptent que des valeurs convertibles en int, comme un long ou un char.
  
  Or justement les long ne sont pas convertibles en int (sans cast) et ils ne sont donc pas autorisés dans un switch
18/06/2013, 16h25
thierryler

Merci tchize_ et fpritchard. Ces inattentions sont corrigées.
20/06/2013, 09h51
adiGuba
Citation:

Envoyé par Deaf

le modificateur de visibilité vide (package-private) n'est pas entre public et protected, mais entre protected et private.

La visibilité "package-private" est bien situé entre protected et private, mais le modificateur de visibilité "vide" ne correspond pas toujours à cela !

En fait cela dépend du contexte :
- Dans une classe, cela correspond bien à une visibilité package-private.
- Dans une interface ou une annotation, cela correspond à une visibilité public.
- Dans une enum, cela correspond à une visibilité package-private, sauf pour les constructeurs où cela correspond généralement à une visibilité private (ce dernier point n'est pas vrai si on utilise des sous-classes pour certains éléments de l'enum - on a alors une visibilité package-private)
a++
20/06/2013, 11h39
Deaf

En effet, il est important de distinguer le "package-private" de l'absence de modificateur. Mais du coup j'en suis à me poser la question:

Citation:

Est-ce vraiment le rôle de ce memento de décrire cela?

Le modificateur "package-private" n'est pas vraiment un mot-clé et n'a donc peut-être pas sa place dans ce memento. Du coup, la liste des exceptions citées par adiGuba (ainsi que la description du package-private) aurait peut-être plus sa place dans une description de la syntaxe Java ou de ses modificateurs de visibilité.
20/06/2013, 11h54
adiGuba

@Deaf : oui en effet, mais il y a une description des modificateurs public/protected/private, donc c'est logique d'y retrouver une explication sur le modificateur "vide"...

a++
21/06/2013, 13h51
ppoulard

Synchroniser sur String.intern(), c'est mal !
@tchize_
Citation:
J'apporte personellement la solution bourrin suivante mais moins verbeuse:

Code:

1 2 3 4 5 String s = "".intern(); ... synchronized (s) { ... }
Bonjour,

Je ne me risquerais pas avec cette solution :
-les Strings sont conservés ad vitam aeternam dans le pool de Strings de la JVM, sans libération de mémoire
-on s'expose à un risque de deadlock, car on peut passer plusieurs fois dans ce bloc de code (ou dans un autre identique) et obtenir une référence sur une instance qu'on ne veut pas égale à une référence qui existerait déjà

http://stackoverflow.com/questions/1...string-objects

a+
Philippe
21/06/2013, 14h11
tchize_

Citation:

Envoyé par ppoulard

Je ne me risquerais pas avec cette solution :
-les Strings sont conservés ad vitam aeternam dans le pool de Strings de la JVM, sans libération de mémoire

Faux. La mémoire est libérée comme une autre en cas de besoin. La référence native est considérée comme une weak reference, donc ignorée par le garbage collector. Le seul inconvénient, c'est que les String intern sont allouées sur le permgen et non pas sur la heap. Donc faut prévoir un permgen plus gros si jamais tu garde des hard reference à beaucoup de strings internées.

Citation:

-on s'expose à un risque de deadlock, car on peut passer plusieurs fois dans ce bloc de code (ou dans un autre identique) et obtenir une référence sur une instance qu'on ne veut pas égale à une référence qui existerait déjà

Me semblait que le but de l'exemple était le contraire, montrer comment on peux créer un lock unique liée à un nom (chaine de caractères). Evidement, si tu veux des locks différenciés, tu passe pas par là.
21/06/2013, 15h42
thierryler

J'ai remplacé par un Chien donc...