Nous avions laissé nos héros au moment où ils allaient se rendre compte que List<Integer> n’était pas une extension de List<Number>. Emplis de désarroi, ils se tournèrent donc vers le type anonyme ?, qui va leur permettre de contourner ce problème. Même si ce chemin n’est certes pas exempt d’embûches, cela leur permettra au moins de terminer le tour d’horizon des génériques, commencé la semaine dernière.
Archives mensuelles : mai 2011
Nouvelles URL
Je viens de changer les options de création des URL quelques articles de ce blog. Je me suis rendu compte que le p?88 était qualifié d’ugly par les instances officielles de WordPress, alors que les nouvelles sont maintenant pretty. En ces temps où le paraître est plus important que le contenu, il fallait que ce changement soit fait !
Ca va permettre de perdre définitivement les rares (et d’autant précieux !) lecteurs de ce blog.
Donc si vous aviez des signets sur les articles de ce site, la bonne nouvelle du soir, c’est qu’elles ne sont plus valides !
Lumière sur les génériques – 1
En ces périodes de restrictions de prestations sociales, utiliser les génériques est une recommandation classique. Ne reculant devant rien pour satisfaire à l’effort national de réduction des déficits, je me suis lancé dans cette mise en lumière, en me disant qu’il en sortirait bien quelques chose.
Les génériques, c’est un peu comme le vélo, ça a tendance à marcher tout seul. Et si ce n’est pas le cas, tout le monde sait qu’il est inutile de chercher à comprendre, et qu’il sera beaucoup plus efficace de bombarder son code de casts aléatoirement distribués jusqu’à ce que ça marche à nouveau.
Et puis, à un moment, malgré ce remède pourtant préconisé par le ministère de la Santé, ça déraille vraiment, et là on se retrouve les mains dans le cambouis, en se demandant ce qui a bien pu se passer.
Les génériques sont passés dans les mœurs depuis Java 5. L’impact a été énorme, puisque des centaines d’API ont été adaptées lors de leur introduction. Dans la plupart des cas, leur utilisation est naturelle, ce qui les rend très agréables à utiliser. Mais leur spécification recèle des mystères, et parfois des erreurs de compilation cryptiques apparaissent.
C’est à un petit voyage sous ces arcanes que je te convie, cher et précieux lecteur. Il ne nous mènera pas beaucoup plus loin que l’incomparable JLS, mais peut-être y découvriras-tu des paysages nouveaux ?
Synchronisation et volatilité
Les deux notions de synchronisation et de volatilité sont en train de prendre, depuis quelques années, une importance croissante. La généralisation des processeurs multicœurs, jusque dans les téléphones portables, fait surgir des bugs dans les applications Java, qui ne s’observaient pas auparavant.
Nous avons de la chance, nous autres développeurs Java, pour deux raisons. La première, c’est que nous avons une doc, la JLS (Java Language Specification, nous vivons sous le règne de la v3), qui spécifie tous les aspects du langage. La deuxième, c’est que cette doc comporte un chapitre 17, qui traite précisément des problématiques de la programmation concurrente.
Nous avons aussi deux malchances. La première, c’est que la JLS est vraiment un document pénible à lire. Et la deuxième, c’est que le chapitre 17 est totalement hermétique. Finalement, traiter des problèmes complexes dans des documents illisibles a au moins un mérite : ça peut justifier l’écriture d’articles dans des blogs techniques.
Donc, ne reculant devant rien pour te satisfaire, précieux et intrépide lecteur, je te propose une petite explication de texte sur la synchronisation en Java, qui, je l’espère éclairera ta lanterne sur une problématique majeure du développement, actuellement et pour les années qui viennent.