Oracle invite la fondation Apache à reconsidérer son départ du Java Community Process
La fondation ne répond pas
Le 2010-12-13 13:56:28, par Idelways, Expert éminent sénior
Mise à jour du 13/12/2010 par Idelways
Oracle a réussi à faire valider les spécification de Java 7 et 8 à une forte majorité (lire ci-avant). Il n'en demeure pas moins que le départ, provoqué par ce vote, de la fondation Apache, une fondation impliquée dans une centaine de projets dans l'écosystème Java, semble sérieusement l'inquiéter.
Après voir demandé à la fondation de reconsidérer son opposition aux propositions formulés pour Java 7 et 8 (lire ci-avant), Oracle vient de tendre la main à la fondation pour amorcer une tentative de réconciliation. Et la prie de revoir sa décision de quitter le comité exécutif de java (JCP)
Dans un court billet de blog, Adam Messinger, vice président du développement à Oracle, rappelle les faits et encourage la fondation Apache à "reprendre part aux efforts destinés à faire avancer la technologie Java".
Car, avoue Messinger, "la fondation Apache et ses nombreux projets open-source sont une partie importante de l'écosystème Java".
Sans en dire d'avantage, il semblerait que le départ de la fondation n'enchante pas Oracle.
De son côté, la fondation Apache fait (officiellement) la sourde oreille. Elle semble en tout cas moins pressée de répondre à ce message que la fois passée.
Jim Jagielski, président de la fondation, depuis son compte Twitter personnel se demandait néanmoins, dubitatif et quelque peu ironique, quelle raison pourrait justifier le retour de la fondation au Java Community Process.
Il allait même plus loin la semaine dernière dans un billet sur son blog personnel où il affirmait que le Java Community Process était tout bonnement mort et que c'était "Oracle qui l'a tué".
Jagielski y appelait également à la constitution d'un nouveau Community Process.
Pas sûr qu'une telle initiative emporte une adhésion massive.
Source : le message d'Oracle, le Twit de Jim Jagielski et son Blog personnel
Et vous ?
Comment évoluera la situation selon-vous ?
La naissance d'un autre Community Process est-elle possible ou même envisageable ?
En collaboration avec Gordon Fowler
Oracle a réussi à faire valider les spécification de Java 7 et 8 à une forte majorité (lire ci-avant). Il n'en demeure pas moins que le départ, provoqué par ce vote, de la fondation Apache, une fondation impliquée dans une centaine de projets dans l'écosystème Java, semble sérieusement l'inquiéter.
Après voir demandé à la fondation de reconsidérer son opposition aux propositions formulés pour Java 7 et 8 (lire ci-avant), Oracle vient de tendre la main à la fondation pour amorcer une tentative de réconciliation. Et la prie de revoir sa décision de quitter le comité exécutif de java (JCP)
Dans un court billet de blog, Adam Messinger, vice président du développement à Oracle, rappelle les faits et encourage la fondation Apache à "reprendre part aux efforts destinés à faire avancer la technologie Java".
Car, avoue Messinger, "la fondation Apache et ses nombreux projets open-source sont une partie importante de l'écosystème Java".
Sans en dire d'avantage, il semblerait que le départ de la fondation n'enchante pas Oracle.
De son côté, la fondation Apache fait (officiellement) la sourde oreille. Elle semble en tout cas moins pressée de répondre à ce message que la fois passée.
Jim Jagielski, président de la fondation, depuis son compte Twitter personnel se demandait néanmoins, dubitatif et quelque peu ironique, quelle raison pourrait justifier le retour de la fondation au Java Community Process.
Il allait même plus loin la semaine dernière dans un billet sur son blog personnel où il affirmait que le Java Community Process était tout bonnement mort et que c'était "Oracle qui l'a tué".
Jagielski y appelait également à la constitution d'un nouveau Community Process.
Pas sûr qu'une telle initiative emporte une adhésion massive.
Source : le message d'Oracle, le Twit de Jim Jagielski et son Blog personnel
Et vous ?
En collaboration avec Gordon Fowler
-
Emmanuel DelogetExpert confirméOu qu'ils n'avaient guère le choix, Oracle ayant exprimé sa position : même si le JCP votait non à sa proposition, il allaient quand même lancer les études sur les versions suivantes de Java, sans consulter personne et au mépris des règles mises en place pour ce groupe de travail (c'est à dire au mépris du contrat ayant valeur légale signé entre les différents membres du programme). En gros, Oracle a dit : soit vous nous suivez et ont vous fait bonne presse, soit vous ne nous suivez pas et non seulement on continue quand même, mais en plus on vous fait mauvaise presse. Du coup, certains votants ont exprimé leur désacoord en commentaire, tout en votant "oui". Seul Apache a voté "non", et Oracle n'a pas perdu son temps : ils deviennent ceux qui veulent ralentir le développement de Java pour des considérations médiocre (c'est plausible d'après vous ?) alors que Oracle et le JCP sont ceux qui veulent faire avancer Java pour le meilleur des mondes (toujours plausible ?).
Envoyé par _skip
Il existe des implémentation Open Source de Java, et sans accès à un kit de test de compatibilité, ces implémentations ne peuvent pas être testées. Face à un Oracle trop campé sur ses positions, et face à des violations de plus en plus fréquente des termes de la licence Open Source Java (après vérification, il s'avère effectivement que la guère que Oracle mène contre Harmony soit contraire aux accords signés entre Oracle, le JCP et la Fondation Apache), j'imagine mal les dévelopeurs Apache travailler principalement sur les JVM Oracle (ou IBM ; qui a appuyé la décision d'Oracle. Et obtenu une licence de 10 ans pour continuer de profiter des développements Java effectués par Oracle).Le seul projet directement menacé, c'est harmony. Et sans connaître sa part de marché je doute qu'il soit si populaire que ça. C'est donc une perte que l'écrasante majorité des entreprises peut absorber sans aucun dégât à l'heure actuelle.
Quand à menacer les entreprises, damned, Google se base dessus pour aider à la définition d'Android ! Combien d'entreprises sont elles concernées ? Apache s'en sert aussi, et combien d'entreprises sont concernées par les produits de l'ASF ?Il est toujours possible de développer des implémentations de frameworks par exemple en se basant sur les spécifications.Oracle n'a aucun intérêt à pousser java si c'est pour que 99% des projets en bénéficie gratuitement sans lui rapporter un centime.Et puis combien de projets Java sont touchés par les intransigeances d'Oracle ?
- Les JVM tierces qui ne sont pas libres au niveau des licences
- HudsonJe suis peut-être optimiste mais
- les projets Apache vont perdurer puisqu'ils sont le fruit de besoins
- idem pour les autres projets majeurs du libres (ou pas) comme Hibernate, Spring, ...Au point ou ca en est C# et Mono, c'est presque moins dangereux pour l'avenir.
Pour terminer, un des liens de la news pointe sur le blog de Jagielski - et ce blog explique beaucoup de choses concernant la décision d'Apache. Il serait bon de le lire, vous verrez que tout n'est pas si clair dans le rôle d'Oracle. Selon Jagielski, Apache ne poursuit pas que ses intérêts. Ils souleve un point qui tends à montrer que Oracle fait le forcing pour ne pas respecter les termes de la licence Open Source de Java, tout en faisant pression sur les membres commerciaux du JCP pour faire passer des changements qui ne sont souhaitables que pour Oracle. Ne vous laissez pas contaminer par la version Oracle de l'histoire.
Enfin, la fondation Apache n'est pas un organisme dictatorial : la décision n'a pas été prise pour une question d'ego ; elle a été discuté au sein de la fondation et avec les utilisateurs. Et je ne doute pas qu'elle a nécessité un consensus large. Dire que c'est une décision de la communauté Apache pour la communauté Apache me parait très réducteur. Un poil trop en fait.le 14/12/2010 à 9:58 -
tchize_Expert éminent séniorautant je comprend que leur position est difficile, autant leur décision (apache) se résume à "c'est un process basé sur un vote des différent membres, je suis dans la minorité qui était contre, et bien que j'étais minoritaire, vous n'avez pas fait ce que je voulais que vous fassiez. Alors puisque vous faites pas comme je veux, je me barre". Je trouve que ça fait un peu gamin comme décision et justification, vu de l'extérieur.le 13/12/2010 à 17:10
-
Emmanuel DelogetExpert confirméNote : ecrit avec un iPad. Clavier compliqué. Pas conseillé pour la redaction de long messages...
Le problème n'est pas la qualité des implementations de la fondation Apache, mais les fait qu'elles sont omniprésentes sur le web (et ailleurs). Combien d'intranet basé sur tomcat ? Combien de site tourant sur Apache ? Si Sun a créé un langage et un environnement solide, il faut reconnaitre que c'est la fondation Apache qui a fait enormément ces dernieres annees pour son developpement.
Avec a la clef un point problématique pour Oracle : si la suite dela fondatiion se met à ne plus suivre le standard Java, combien d'entreprises vont abandonner leur suite qui ne serait plus standard, quand on sait le cout du developpement d'un intranet complexe ? A mon humble avis, une minorité. Du coup, Java se fractionnerait, ou Oracle serait obligé de suivre, a moins de fermer de nouveau le code de la machine virtuelle ou de l'environnement. Ce qui serait vraiment un coup dur pour Java - car si de nouveaux decveloppements doivent voir le jour, les entreprises risquent fort de perdre la confiance qu'ils ont mis tznt de temps a acquerir.
C'est un tournant : s'il est mal négocié, Oracle peut parvenir a faire ce que Sun a toujours evité, comprenant que son avenir passait par cette plateforme : car nonobstant les qualité (réelles ou supposées ; mais ne tollons pas sur ce sujet, ce n'est pas le debat) de ce langage, Oracle pourrait provoquer sa fin, puis son abandons, a moyenne echeance.
C'est une erreur grave, a laquelle ils vont maintenant tenter de trouver une soldution a l'amiable. La raison pour laquelle la fondation ne se presse pas, c'est qu'ils ont tout a gagner a jouer la montre : petit a petit, les clients d'Oracle vont venir dire a la societe "hé, vous vous rappelez que nous, on a besoin de savsoir ce qui se passe, et ce qui va se passer ?", ce qui pourrait a terme faire plier Oracle. Et si Oracle ne cède pas, et bien la fondation a une base d'utilisateurs tout a fait consequente, et elle peut se passer d'eux - ils representent une force capable de créer un fork tout a fait viable du langage, et peuvent entrainer de nombreux participants a leur suite (dont une petite société du nom de Google ; m'etonnerais qu'a moitié que Google reprenne le fork de MySQL...)
Bref, tout ca pour dire qu'Elisson a singulierement manqué de vision sur ce coup - et que ca ne va pas les aider a regagner la confiance des afficionados de l'Open Source qu'ils ont violenté récemment.le 13/12/2010 à 23:14 -
Emmanuel DelogetExpert confirméAucun des intervenant ayant pris la parole dans cette histoire n'est tout blanc. On peut tou prendre avec des pincettes, mais lorsqu'on m'explique les choses telle que la fondation Apache le fait, je n'ai aucune raison d'y voir quelque chose de malintentionné de leur part. C'est à ça que ça sert la transparence. Et comme la fondation est la seule source d'explications claires et transparentes, il me semble naturel de considérer que leur point de vue est plus fondé que celui d'Oracle. Ou de Google. Ou d'un autre.
Maintenant, il me semble en lisant les posts ici que beaucoup de monde en veut à la fondation Apache, ce qui a tendance à conforter la position d'Oracle. Je vous demande à nouveau de lire ce que vous trouverez sur le sujet : vous verrez que le comportement d'Oracle est seul responsable de cet affrontement - comment Apache peut-il être responsable des interdictions imposées par Oracle ? Depuis son entrée dans le JCP, la fondation se bat pour la libération du TCK : Oracle leur a dit d'aller se faire voir en gras, leur a dit que de toute façon ils se foutaient royalement de ce qu'ils avaient à dire, et qu'en gros ils n'avaient qu'à suivre les décisions des adules, de fermer leur bouche et de relayer le foutage de g. auprès de leurs utilisateurs. Position difficile à tenir.
L'inconditionnalité de la redistribution est le point d'achoppement dans cette affaire. Si pour redistribuer Harmony, Apache a besoin de payer une licence à Oracle et que chaque acquéreur a besoin de faire de même, cette inconditionnalité n'est plus possible.
De part leur nature (redistribution des sources sans avoir à en avertir les ayants droits), aucune licence Open Source ne peut imposer un paiement. La gratuité est corrolaire de la notion de logiciel libre. Tu peux le tourner comme tu veux, mais si j'ai la possibilité de redistribuer un logiciel open source, alors j'ai la possibilité de le faire gratuitement. Si je ne peux pas le faire gratuitement, alors le logiciel n'est pas libre puisque certains ne peuvent pas avoir accès à ce code source.
Harmony ne pourrait pas du tout être distribué sous une quelconque licence Open Source. Qu'elle soit la licence Apache ou une autre licence ne change rien à l'affaire.Dans la fournée, le fait qu'IBM délaisse Harmony pour OpenJDK est aussi un signe. Mais cet état de fait existe avant Oracle, c'est Sun qui l'a instauré.
Pour info, Apache n'a jamais dit ne pas vouloir de Java 7. Apache dit : comme condition pour pouvoir évoluer vers Java 7, il faut libérer le TCK - ce qu'Oracle refuse de faire. Ce n'est quand même pas la même chose. Il est peut-être nécessaire que Java évolue (encore que je ne vois pas ce qui manque au langage. Il y a tant de trous que ça ? Ce n'est pas mon impression...).
Pour info 2, le JCP ne définit pas que ce qui sera ou non contenu dans la prochaine évolution du langage. Elle définit aussi les librairies, la VM, et par conséquent, le TCK. C'est une communauté autour de Java, pas une instance technique de définition de grammaire d'un langage. Il est faux de croire que le débat autour d'Harmony n'est pas lié au travail du JCP : sans TCK libre, il est difficile voire impossible de vérifier de manière pratique une implémentation libre particulière de Java (dans son ensemble). Du coup, définir des évolutions dans Java est nettement plus complexe, non ?
Vous utilisez - vous ne voyez pas nécessairement les implications d'une telle décision. Mais pour que vous puissiez utiliser sereinement Java, il faut quand même s'assurer que les différentes plateformes sont interopérables - sans quoi, le write once, run everywhere va avoir un sérieux problème et vous déciderez de vous même de ne plus utiliser Java pour ne pas vous enfermer avec une JVM particulière. Vous pouvez décider que ce combat ne vous concerne pas, mais ça ne veut pas dire que c'est le cas. Ca vous concerne de manière directe.le 14/12/2010 à 15:47 -
Emmanuel DelogetExpert confirméLe résultat des votes du JCP : http://jcp.org/en/jsr/results?id=5111. Comme tu peux le lire par toi même, (presque) tous les commentaires soulèvent le problème de licence. Y compris celui d'IBM d'ailleurs, qui nous donne un savoureux languedeboitisme. Comment peut-on dire qu'il n'y a pas de lien ?
Le commentaire de la Fondation Apache :
The Apache Software Foundation must vote no on this JSR. While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because :
a) This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions. We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.
b) On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations. We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.
c) The spec lead has ignored repeated requests from multiple EC members for and explanation of both a) and b)
d) The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice. We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP. The rules apply to everyone.
While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.
Je ne suis pas d'accord avec tout : s'il y a effectivement chantage, ce n'est pas pour que la fondation se la joue perso, c'est pour que tout le monde en profite au final. C'est pourquoi je ne vois pas comment quelqu'un pourrait en vouloir à la fondation (à moins de travailler chez Oracle, évidemment). D'où mon intense surprise de voir qu'une bonne partie des commentaires tape sur la fondation : soit c'est une réaction de non informé, soit c'est une réaction illogique. Je ne comprends pas qu'on puisse faire une analyse différente : tous les mots sont là, toutes les explications sont disponibles.
Et puis, ASF n'a pas été le seul à quitter le JCP récemment (ceux qui ne connaissent pas Doug Lea : cf. Wikipedia).
Non libre ne veut pas dire payant, certes - les freeware le prouve. Mon poste précédent dit que libre implique gratuit, ce qui n'entraine pas que non libre implique payant.
Dans le cas actuel, le TCK - et donc la certification d'un JSR indépendant - ne peut être distribué que par Oracle (la licence), malgré le fait que certaines portions soient en licence Apache. Si il était aisé de se procurer ce TCK (dont les dernières versions ne sont pas dans la liste complète des download Oracle) et de certifier une implémentation, je ne pense pas que la Fondation ferait trop la tête - et encore. Seulement, à l'heure actuelle, seul Oracle peut distribuer le TCK, et Oracle peut décider à qui le distribuer, créant ainsi une situation où ils sont les seuls à décider de quel JVM peut être développé, et à quelle condition - ce qui rend toute notion de JVM libre caduque, et fausse de fait une compétition acharnée dans le secteur. Oracle protège ses intérêts, certes. Mais au mépris des règles qui ont été adaptées en session du JCP.
D'ailleurs, que pensez-vous qu'Oracle votait avant qu'ils n'ait racheté Sun ? Un indice ce cache dans cette explication.
Non, je ne crois pas. Harmony est un projet déjà ancien, et ASF a déjà eu le "loisir" de combattre Sun sur le sujet de la licence du TCK, tel que je le rapelle plus haut. Le fait que IBM quitte Harmony n'a pas grand chose à voir avec l'énervement légitime de
Faux - toute JSR requiert une implémentation et un TCK correspondant. De fait, lorsqu'une petite JSR est implémentée, un petit TCK vient avec. C'est le lead sur le JSR qui est responsable du TCK et de sa licence - c'est probablement la raison pour laquelle on se retrouve avec du code sous licence Apache dans le TCK global. Bien sûr, et c'est une chose nécessaire et bonne, c'est Oracle qui est lead sur les JSR concernant la définition de nouvelles évolutions du langage. Du coup, c'est Oracle qui décide des termes du TCK correspondant. Les procédures du JCP sont expliquées sur leur site.
Du coup, voter OUI a ce vote particulier signifie accepter le TCK correspondant à cette JSR particulière.le 15/12/2010 à 10:17 -
tchize_Expert éminent séniorBen oui, tout est une question de besoin. Pourquoi on sort spring. hibernate ou J2EE dans un projet. Parce que ça permet de coder plus vite, et qu'un programmeur ca coute plus cher au mois qu'un serveur
. Si ce n'était pas le cas, on utilsierais pas ce genre d'outils et on attaquerais tout depuis la base à chaque fois pour répondre au besoin spécifique.
Et encore heureux qu'on a pas besoin de NHibernate pour faire du java () le 13/12/2010 à 14:12 -
BrzhkMembre du ClubJe suis quasi sur que tu as pensé différemment de ce que tu as écrit.
Si tu choisis des technos lourdes et que ton but final est de faire un blog, oui tu t'es trompé.
Par contre, si tu choisis des technos lourdes pour faire un gros truc qui est condamné à evoluer sur 10 ans, alors tu as tout bon.
Java + spring + hibernate & autres ne sont pas faits pour faire des blogs, point. Les servlets suffiront largement, avec un peu de JSF si le besoin s'en fait sentir.
Dans un sens plus général, j'ai observé la tendance des threads de ce forum à déraper sur du comparatif global de languages qui vire au flamewar.
Prendre un bazooka pour tuer une mouche et ensuite cracher sur le bazooka parce que vous avez raté la mouche est idiot. Du coup, faire des comparatifs entre les bazookas et les sarbacanes. "PHP vs C++ vs Java" n'a aucun sens balancé comme ca. S'il vous plait, restons en au sujet de base
Si Apache part pour un fork java 'libre' (avec un autre nom ou pas), on va scinder la communauté en deux et perdre la force d'innovation. Tout se fera en parallèle, et ce serait dommage. On réinventera la roue des deux cotés... Du temps perdu en somme. J'espère sincèrement qu'une solution 'libre' sera trouvée, car j'espère pouvoir continuer a coder dans ce langage qui me plait énormément sans payer une dime oracle/MS et en pouvant contribuer aux outils que j'utilise. J'aime bosser sur des outils qui tendent vers la perfection, et les outils opensource/libres vont dans la bonne direction !!le 14/12/2010 à 12:05 -
UtherExpert éminent séniorÉtant donné qu'il n'y a pas d'autre endroit pour régler les problème relatifs au TCK, je dirais plutôt que c'est pour moi le meilleur endroit pour le faire.
Le TCK servant justement à valider ces JSR, il ne me parait pas hors sujet de discuter la manière dont la spécification doit être validée.le 14/12/2010 à 18:12 -
manblaizoMembre confirméEn tout cas, en ce qui me concerne, je ne vois pas ce que tout cela va changer. Harmony n'est pas stratégique pour moi.
N'oublions pas que Sun a ouvert Java seulement en 2006, et cela n'avait pas empêché que des projets open source ne gagnent en ppopularité et dépassent leurs équivalents 'standards' (Struts, Hibernate, Spring, Ant...)
Non, franchement, Sun/Oracle ne fait que protéger ses intérêts en essayant de préserver ses royalties sur le mobile. Les opérateurs payent pour une licence JavaME à Oracle qui du coup n'a pas envie de voir que JavaSE soit détourné pour fonctionner sur les mobiles (cf. Android), d'où la clause "Field Of Use" à laquelle Apache ne voudrait pas souscrire parce que ça dénature leur propre licence; ce qui est compréhensible.
Enfin, bref, c'est juste une affaire de gros sous ici, parce que le principal visé c'est bien Google qui a basé son Android sur Harmony. Il faut juste espérer qu'ils arrivent à un compromis qui arrangerait tout le monde.le 15/12/2010 à 19:23 -
Emmanuel DelogetExpert confirméQué ?
Par définition, si une JVM passe les tests du TCK, elle reste dans le giron de ce que produit Oracle - elle est entièrement compatible, en d'autres termes. Bref, c'est un fork au niveau des sources, mais offrant les même services. En quoi est-ce ennuyeux pour Oracle ? En quoi est-ce un danger ? Ca permet au contraire de proposer une offre alternative, ce qui en retour permet de favoriser l'implantation du langage. En bloquant le développement de certaines machines virtuelles, Oracle se fait plus de mal que de bien, tout en déconsidérant le travail de milliers de passionnés de Java (parce qu'il faut être passionné pour faire un JVM). Même Microsoft ne se comporte pas comme ça - la spécification de C# est ouverte, ce qui a permis l'émergence de Mono. Mieux, MS participe activement au développement de cette plateforme, en fournissant des ressources d'ingénierie et de tests à Novell.
IBM a fait quelque chose de similaire à la fin des années 70. Ils ont décidé d'ouvrir une architecture matérielle, sous le nom "compatible PC". Sans tests de compatibilité, ça été dur au début (on se souvient des incompatibilités chroniques entres les "compatibles". Du coup, on a standardisé des tests. ET on les a rendu accessible à tout constructeur. Sans ça, le marché des PC se serait effondré sous son propre poids.
Je ne crois pas que ça ait fait du tort à l'informatique.
Le comportement d'Oracle est très lié à la façon dont l'esprit d'Ellison fonctionne : c'est brouillon, et ça montre un niveau de paranoïa élevé. La seule chose qui compte, au final, c'est l'argent qui rentre. C'est cynique. C'est le droit d'Oracle, mais c'est rudement cynique. C'est une vision à court terme, que je trouve dégoûtante du pognon qui dégouline. Ca ne va pas me donne confiance en Oracle pour l'avenir. Je ne suis certainement pas le seul, ce qui est plutôt bien : Oracle s'aliène aujourd'hui les DSI de demain - reste à savoir avec qui ils vont faire du business dans 15 ans.le 27/01/2011 à 22:11