JavaDay: Merci !

Cela faisait longtemps que je n'avais pas passé une journée aussi exceptionnelle! De l'énergie, du contenu, des orateurs motivés et des participants attentionnés. Un vrai plaisir que j'ai senti partagé par tous. Mais une telle réussite n'aurait jamais été possible sans l'implication d'un certain nombre de personnes et de communautés et je vais de ce blog, toutes les remercier. En premier lieu, je voudrais rendre à nouveau hommage au professionnalisme pétillant d'Alexis qui aura mené de front l'organisation de ce Javaday, la session AJAX et la naissance du petit Alexandre. Un Google de merci. C'est également grâce au même Alexis que nous avons pu conjointement travailler avec la communauté française de l'OSSGTP. Je tiens à remercier personnellement Vincent Massol et Didier Girard qui ont monté une remarquable présentation des projets OpenSource Java de ce groupe. Un grand merci à ceux qui étaient également présents à cette table ronde:

• Ludovic Dubost, XWiki
• Emmanuel Bernard, Hibernate
• Guillaume Laforge, Groovy
• Marc-Antoine Guarrigue, Jcaptcha
• et Vincent Massol, Maven, ...

Ce Javaday fut également l'occasion d'écouter (en français) un excellent Romain Guy tombé du ciel qui a brillamment fait la même démonstration le lendemain aux chercheurs médusés de l'INRIA. Ludovic Champenois (ceci est un remerciement), revenu spécialement de Corse, nous a démontré combien NetBeans et Glassfish sont devenus des outils incontournables du développement Java EE 1.5, ce que Emmanuel Bernard, au nom de JBoss, a largement confirmé. Enfin merci à Philippe Davy (groupe Test) d'avoir animé la table ronde concluant cette matinée qui a réuni Hervé Crespel (Club Java), Vincent Massol (OSSGTP), Tugdual Grall  (Oracle), Jean-Pierre Blanger (Ricoh). Merci à tous. Une mention spéciale à Thibault Régnier, du Club Java, qui nous a présenté sa vision de JavaOne 2006 en fin de journée. Et quand il s'agit de partager une même passion, rien de vaut l'enthousiasme de ceux qui feront la France de demain. Un immense merci donc à:

• Toute l'équipe de SunInfo qui a assuré les install party de NetBeans et Solaris (des pros, rien à rajouter)
• Au Groupe d’Utilisateurs du Système d’Exploitation Solaris (GUSES) pour l'install Solaris (idem)
• A l'équipe fon, qui a converti par sa compétence et son ouverture, des centaines de nouveaux foneros
• A l'ASS2L pour son coup de main marketing

Merci à tous nos sponsons (Oracle, Ricoh, AR Systems et AMD) et partenaires presse (developpez.com et programmez): nous avons fait du bon travail. Mais il aurait été dommage d'oublier ceux qui nous ont permis d'organiser la soirée qui a conclu cette grande journée. Merci (Marie), merci (Paul) et merci (Stéphane) de Silicon Sentier: je ne pouvais pas rêver plus parfaite conclusion. Que dire également du plaisir de passer deux jours avec un homme aussi remarquable que James Gosling ? Souplesse, pertinence, ouverture d'esprit: pas étonnant qu'avec un père comme celui-là, Java soit devenu au bout de 11 ans un tel phénomène. Et puis, une fois n'est pas coutume, c'est à moi-même que je voudrais adresser un dernier merci. Ce JavaDay fut un passionnant projet à penser, construire et vivre. Et l'avoir réussi, n'est pas la moindre de mes fiertés.

PS: Ce post est beaucoup trop long ... alors, pour les patitents, j'ai mis quelques photos du JavaDay sur flickr.

Plus fort que moi !

J'ai passé un excellent weekend gentiment invité par Laurence dans sa jolie maison des Yvelines qui finalement est un bel endroit de la région parisienne. La chaleur cet été 2005 fait de l'apéritif un moment à la fois délicieux et incontournable, surtout quand il se trouve être partagé par des gens aussi charmants et accompagné des incontournables Apéricubes. Je vous livre le premier que j'ai pris au milieu d'une bonne centaine d'autres: édifiant!

Pour ceux qui trouveraient le sujet un peu éloigné de nos préoccupations actuelles, je me permettrais de rappeler que la boucle d'oreille de la Vache qui Rit est un parfait exemple de mise en abîme graphique si chère à Escher et qui pourrait s'apparenter à l'appel récursif infini d'un développeur Java débutant.

ㅟ피

Très intéressant article sur la place des TIC au pays du matin pas si calme en train de devancer le Japon dans le domaine de la mobilité et des nouveaux services en ligne. Ce qui est à retenir de cette leçon d'économie technologique est qu'une vraie politique nationale ne se fait pas sans intervention des entités gouvernementales concernées par ces nouveaux marchés. L'exemple de WIPI (Wireless Internet Platform for Interoperability) est en cela remarquable: démarré au début de l'année 2002, WIPI est une initiative du ministère de l'industrie coréen visant à repositionner les fournisseurs locaux de contenus pour les téléphones mobiles, essentiellement basés sur la technologie BREW, vers J2ME afin d'éviter leur enclavement et orienter ce bouillonnement créatif vers le reste du monde. Du coup, la dynamique des acteurs comme Samsung, LG, SKT ou KTF est parvenu à créer une véritable concurrence (l'ARPU coréenne dépasse celle du Japon) aidée par la portabilité des applications entre terminaux et des numéros de téléphones entre opérateurs (également imposée par l'état).

La prochaine fois que Mr Chirac va en Asie, il devrait faire comme moi: ne pas oublier d'aller voir ce qui se passe chez les mangeurs de 김밥 avant d'aller parler de Victor Hugo aux petits enfants du général Giap.

Dans la boîte

J'ai trouvé ce matin dans ma boîte aux lettres la nuée habituelle des prospectus vantant les mérites de prix tous sacrifiés pour que la rentrée des vacances le soit un peu moins. Je n'ai pas pour habitude de lire ces publicités, mais depuis quelques temps je prends soin de vérifier la place laissée à Java dans les pages consacrées à la téléphonie mobile. Ma déception est généralement grande, sauf cette fois-ci où Java est clairement positionnée, pour ce grand de la grande distribution, comme un must have de tout téléphone portable digne de ce nom. Nous avons bien souvent la mémoire trop courte : je suis sûr qu'un jour, nous avons tous rêvé chez Sun de voir une de nos technologies distribuée à des millions d'exemplaires et devenir une banalité incontournable. C'est fait aujourd'hui, grace à 74g d'électronique et à la clairvoyance de James Gosling (et à bien d'autres).

Dans cet été qui ressemble à l'automne, moi, j'apprécie beaucoup!

TR != RT

Il y a de cela quelques semaines, nous avons eu la chance d'avoir la visite de Greg Bollella, Distinguished Engineer (terminologie totalement intraduisible) à Sun Labs, venu chez nous pour parler du projet Mackinac à une grande société française travaillant dans la défense. Plus de 35 personnes étaient présentes, un record pour un vendredi après-midi en plein mois de juillet. Ce projet est basé sur la spécification Real-Time Specification for Java du JSR 1 qui, comme son nom l'indique, fut historiquement le premier à démarrer au sein du Java Community Process en 1999. On pourrait être surpris du temps qu'il aura fallu à ce groupe de travail pour aboutir à une spécification stable dont une démonstration a été faite durant le dernier JavaOne. Pourtant, en écoutant Greg, je me suis rendu compte de l'énorme chantier qu'a représenté l'adaptation de Java au temps-réel (TR). Trois principes ont servis de base pour le JSR 1: supporter les pratiques du monde du TR en matière de programmation et conception d'applications, rester compatible avec les versions officielles de Java en passant les tests du TCK du JSR 1 et de ceux de J2SE, J2ME et J2EE, offrir aux développeurs une couche d'abstraction leur permettant de « penser » leurs applications en termes de contrôle de comportement temporel.

Big deal! On pourrait croire que la montée en puissance des processeurs et de la taille mémoire disponible sont suffisants pour permettre de qualifier un programme de TR sans avoir à ce préoccuper de la logique interne de son fonctionnement (the faster, the better). Ceci est évidemment une erreur que les participants à cette présentation, tous spécialistes du TR, ne faisaient pas. Ils ont donc particulièrement apprécié qu'au travers des API de RTSJ leur soit donné le contrôle du temps par les 28 points d'entrée à priorité variable du scheduler et de la mémoire par les fonctionnalités apportées par les classes ScopeMemory et NoHeapRealTimeThread. Le débat reste ouvert sur les futures évolutions des garbage collector afin que ceux-ci soient capables de prendre en compte le TR, ce qui résoudrait le problème actuel de RTSJ qui oblige le programmeur à se préoccuper à nouveau de la gestion de la mémoire de son application. Prochaine étape en Mars !