J’étais un peu inquiet quand à l’organisation de cette nouvelle conférence, et ça n’a pas loupé … non je rigole, c’était nickel. Trente secondes pour récupérer mon badge et à peine plus aux vestiaires : super. Quand on sait que il y avait 900 personnes et que c’est une première : je ne sais pas ce que valent les organisateurs en code pur, mais en gestion de projet événementiel : ils sont vraiment bons !

Après un croissant et trois cafés (il faut bien ça) direction la Scene C pour une conférence sur la programmation parallèle avec Java. (quand j’ai dit qu’il fallait bien trois cafés ) : Du début de java à nos jours avec une vision sur le futur et java 8.

L’intervenant José Paumard est connu pour être membre du Jug paris et un nom connu de la communauté java parisienne. Et ça vaut le coup, sûrement habitué a l’exercice, il s’exprime bien, est tres didactique et fait passer des explications complexes avec beaucoup de pédagogie. En gros : on sent qu’il maitrise bien le sujet

Que retenir de cette conférence très technique et pointue :

• Que les processeurs sont amenés a avoir plusieurs centaines voir milliers dans coeurs dans le futur, et qu’il faudra bien que nos langages de programmation nous permettent de les exploiter
• Que java évolue régulièrement depuis sa version 1.1 pour améliorer et simplifier la programmation concurrente dans le coeur de langage : de threat/runnable jusqu’en java 4, Future/callable en java 5 et 6, Fork&Join en java 7 et bientôt l’intégration de parallel() dans l’api des collections java 8
• Que les STM* ont le vent en poupe, car bientôt intégrés aux processeurs intel même si ce n’est pas non plus la solution à tout
• Qu’il faut que je refasse l’effort de me replonger dans akka
• Que la bonne façon de faire un singleton, c’est de passer par un enum
• Que je relise le trés bon Java Concurrency in Practice

Et enfin, que voir quelqu’un parler de cache L1, L2 et L3 des coeurs d’un processeur dans une conf java, c’est quand même bien fun

voila: il est tard : vivement demain !

*STM : Software transactional memory : en gros commit et rollback comme une base de données, mais en mémoire