Publié par
Il y a 5 années · 7 minutes · Events

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Actualité éditeurs / SSII

Google Developers Expert arrive en France

(par Mathieu Breton)

Le Google Developers Expert (GDE) est un programme du géant de la recherche qui vise à faire reconnaître les experts dans les technologies plébiscitées par l’entreprise comme le Cloud, HTML5, Android, Chrome ou le social.

Ces experts seront choisis selon bien sûr leurs compétences techniques élevées, mais devront aussi avoir une forte présence au sein de la communauté au travers de publications, d’animation de conférences et autres.

Au delà de la reconnaissance via les évènements, blogs et participations aux projets, les personnes retenues auront aussi quelques privilèges : accès en avant-première aux produits Google, invitations à des évènements exclusifs, relation privilégiée avec les équipes notamment via des contacts directs avec les « developer advocates », et enfin une invitation annuelle au QG de Google.

Si vous êtes intéressé pour devenir un « Google Developer Expert », sachez que, après des tests au Japon et en Israël, le programme est désormais ouvert en France.

Jigsaw a (encore) raté le train

(par Alexandre Dutra et Nicolas Demengel)

Dans un mail à l’Expert Group du JDK 8, Mark Reinhold vient de proposer le report du projet Jigsaw à Java 9.

Reprenons du début: l’idée d’un système modulaire pour Java remonte à 2005 (!) avec la JSR 277 et ses fichiers « .jam ». Celle-ci, peut-être pas assez réfléchie, rencontra une vive opposition, fut mise en suspens puis remplacée par les « Superpackages » de la JSR 294, initiée en 2007 puis remplacée à son tour par le projet Jigsaw, dont l’idée a germé en 2008. Mais ce projet emblématique connaît depuis un avenir en dents de scie: initialement prévu pour Java 7, puis décalé vers Java 8 à la faveur du «Plan B», il est aujourd’hui de nouveau reporté.

Or le besoin de modularité devient de nos jours critique, comme le démontre le succès de Maven et d’OSGi. Le JDK monolithique actuel devra tôt ou tard subir ce – douloureux? – lifting, notamment afin de:

  1. Faciliter la construction, la maintenance et la distribution d’applications de plus en plus larges, ayant de plus en plus de dépendances;
  2. Permettre des configurations adaptées à des environnements hétérogènes, du serveur d’application au smartphone;
  3. Permettre de meilleurs performances à l’exécution et une empreinte mémoire optimisée;
  4. Régler définitivement le problème du JAR hell (différentes versions d’une même classe dans le classpath).

Seulement voilà, tous s’accordent sur le but, mais beaucoup reculent devant l’ampleur de la tâche: il s’agit ni plus ni moins que du remplacement du bon vieux classpath par un système de modules versionnés assorti d’un mécanisme de résolution de dépendances, le tout s’inspirant de quelques exemples réussis, comme les librairies partagées UNIX, OSGi ou encore Maven. Sans oublier la rétro-compatibilité!

Pourtant dans son blog, Mark Reinhold énumère les progrès accomplis jusqu’à présent: Jigsaw dispose de spécifications détaillées, d’un design initial détaillant la syntaxe de déclaration d’un module, et même d’un prototype. Mais il restait encore des points d’achoppement. En particulier:

  1. La modularisation du coeur même de Java, tout en gardant la rétro-compatibilité totale, est particulièrement ardue; InfoQ mentionne à ce titre les références circulaires entre certains packages comme java.lang, java.io, java.net ou encore l’exemple de java.beans.Beans#instantiate(), qui dépend d’AWT.
  2. Le support des « conteneurs » comme les IDE, serveurs d’applications et conteneurs d’applets est loin d’être abouti, en raison notamment de la délicate gestion du multi-versionnage (plusieurs composants chargés par le conteneur référençant des versions différentes d’un même module).

Mark Reinhold s’est ainsi retrouvé face à un choix cornélien: ajourner tout Java 8 pour permettre à Jigsaw de finir le travail et notamment la nécessaire phase de tests et de retours d’expérience, ou bien releaser Java 8 à temps, sans Jigsaw. C’est la deuxième option qui a été retenue, notamment afin de permettre à Java d’être désormais livré tous les deux ans, à la fin de l’été. Ne seront embarqués que les développements terminés, mais il n’est plus question de repousser les versions.

Alexis Moussine-Pouchkine a réagi vivement à cette annonce et n’hésite pas à parler de « débâcle »: Oracle ne mobiliserait pas toutes les ressources possibles sur le projet. Il déclare même qu’une telle décision risque d’être fatale à Jigsaw car elle encouragera les projets alternatifs, et conteste au passage l’idée d’une release bisannuelle, rythme selon lui trop lent « dans un monde où rester sur place est synonyme de fossilisation ». Et pourquoi ne serait-il pas possible de couper le projet en deux : l’ajout d’un vrai système de modularisation à Java d’une part, et la modularisation de la plateforme elle-même d’autre part ?

Les yeux se sont aussi tournés, non sans malice, vers la communauté OSGi, que l’on soupçonne de se délecter encore et encore des échecs de Sun/Oracle pour proposer une alternative viable à ce standard de facto. Dans ce contexte, Neil Bartlett, auteur de OSGi in Practice, a également réagi au report de Jigsaw. Selon lui, il ne faut pas (trop) s’en réjouir car les deux projets, bien que souvent présentés comme compétiteurs, seraient en vérité plutôt complémentaires: en gros, Jigsaw se placera au coeur de la JRE, sera chargé en même temps que la JVM, et effectuera des bindings statiques – tout le contraire d’OSGi. De plus, avec son lourd rt.jar, le coeur de la JRE, comme évoqué plus haut, est un écheveau inextriquable de dépendances: même OSGi gagnerait à ce que Jigsaw y mette un peu d’ordre, notamment pour pouvoir traiter le namespace java.* comme un namespace parmi d’autres. Rappelons d’ailleurs que le Projet Penrose a été créé dans le but d’explorer les interactions entre Jigsaw et OSGi, et a marqué un virage positif dans les rapports qu’entretenaient jusque-là l’OSGi Alliance et le JCP.

Evidemment, tout cela nous fait redouter un Java 8 vidé de toute substance. Tant que le Projet Lambda (JSR 335) est présent, diront certains, tout n’est pas perdu. Moins médiatisés, les projets Date and Time API (JSR 310) et Annotations on Java Types (JSR 308) apportent eux aussi leurs lots de contributions substantielles.

Le coin de la technique

Event sourcing avec Scala

(par Xavier Bucchiotty)

Martin Fowler nous présente ce principe dans ce billet blog. Le concept est plutôt simple: plutôt que de stocker en base de données le dernier état de l’objet, il vaut mieux stocker chaque événément. A partir d’un état initial, chaque événement est rejoué sur les objets pour obtenir leur dernier état valide. Cet état n’est présent qu’en mémoire, ce qui permet de ne plus avoir la base de données comme goulet d’étranglement.

Le principe vous séduit et vous utilisez Scala et Play? Alors vous devriez jeter un oeil sur cet article en deux parties. L’auteur partage son implémentation via un projet sous github pour une application de gestion de blog. Le premier article aborde l’implémentation des actions jusqu’à la performance de son application avec une campagne Apache JMeter. Le second article quant à lui revient sur la distribution du traitement et la gestion de la consistance des évènements. Les deux articles sont très complets et surtout avec du code à l’appui. Reste cependant que cette stratégie de stockage n’est pas la plus naturelle à concevoir…

Evènements de notre communauté en France et à l’étranger

Conférence Android et Sécurité

(par Dahlia Scherr)

Le Paris Android User Group nous propose ce mercredi 25 juillet une conférence sur le thème de la sécurité dans les locaux de l’Epita.

Au programme :

  • Philippe Prados, architecte chez Smart Mobility, présentera le développement sécurisé sous Android : Architecture et techniques, exploitation du modèle pour ajouter un privilège à une application.
  • Daniel Fages, spécialisé en développement système et sécurité, abordera l’aspect Sécurité des communications sous Android, analyse des menaces  et des contre-mesures associées.

Plus d’infos et inscription sur le site du PAUG.

Xebia France
Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 11 ans nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

5 réflexions au sujet de « Revue de Presse Xebia »

  1. Publié par emmanuel lecharny, Il y a 5 années

    Event sourcing : cobtrairement à ce qui est écrit dans l’article, il ne s’agit pas de remplacer le stockage de l’état courrant par des logs d’events, mais simplement de stocker *aussi* les events. Sinon, le post de MF n’apporte rien de nouveau, ce sont des techniques de base employées depuis des décennies… Comme d’habitude avec Fowler…

  2. Publié par Dominique De Vito, Il y a 5 années

    J’ai du mal à comprendre pourquoi Oracle met dans le même bain l’ajout d’un vrai système de modularisation à Java d’une part, et la modularisation de la plateforme Java elle-même d’autre part:
    a) ajout d’un vrai système de modularisation à Java : il y a des cas d’utilisation avérés, cf. le succès de OSGi et de Maven
    b) modularisation de la plateforme Java elle-même : ça fait déjà plus de 10 ans que l’on fait sans, et si j’entends des plaintes à propos de Maven (et de son intégration aux IDE), je n’entends rien à propos de la modularisation de la PF Java ; elle peut attendre encore un peu.

    Eclipse+Maven+GWT+tous les plugins « qui vont avec » peut être tellement une horreur pour un gros projet que je me dis que l’on n’est pas vraiment gâté, dans le monde Java, actuellement, en matière d’env de dev. J’ai même plutôt l’impression de régresser en matière de productivité (vu les gels de l’IHM Eclipse que m’impose fréquemment le plugin Maven de mon Eclipse).

    Avec ce report évoqué pour le JDK 9, on a l’impression que, dans Jigsaw, tout est lié, et que, rien n’est prêt, rien n’est pas à récupérer dans le JDK 8.

  3. Publié par Arnaud, Il y a 5 années

    Effectivement, j’ai une application basé sur l’ « Event Sourcing » depuis presque 10 ans, donc rien de nouveau. Mais ce nom n’existait pas à l’époque, et aujourd’hui ça fait plus sérieux. :)

    L’Event Sourcing « pure » n’a pas besoin de snapshots de l’état courant, juste des events.
    (Les snapshots permettent éventuellement d’accélérer la reconstruction,
    mais ça complique plutôt les choses et le gain de perf n’est pas forcément significatif.)

    Intéressant dans l’article en Scala: la combinaison Event Sourcing + STM

  4. Publié par Nicolas Demengel, Il y a 5 années

    @Emmanuel & Arnaud : le post de Martin Fowler n’est pas ici présenté comme une nouveauté ; c’est l’exemple de son application en Scala qui a retenu l’attention :-)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *