Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Google essuie les plâtres et met à jour l’Android NDK
• MIDP 3 et MSA 2 pour sauver J2ME ?

Agilité

• Départs de la Scrum Alliance : bruits de couloirs

RIA

• Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le coin de la technique

• Les roadmaps des implémentations de JPA 2.0
• Web Beans est mort ! Longue vie a Weld !

Actualité éditeurs / SSII

Google essuie les plâtres et met à jour l’Android NDK

Pour rappel, le NDK est un environnement de développement complémentaire au SDK qui permet d’utiliser des langages autres que Java pour développer sur Android. Ce NDK est principalement dédié au développement C et C++. Parmi les nouveautés de la version 1.6, vous trouverez :

• Les librairies OpenGL ES 1.1 qui rapprochent encore un peu Android de l’IphoneOS.
• Ciblage de version Android pour garantir le fonctionnement de votre application.
• Possibilité de mélanger les sources Java et le code natif dans un même projet.

Mais la semaine passée fût aussi l’occasion d’une joute entre Google et certains développeurs Android. Sujet de la discorde, le CyanogenMod une version libre, modifiée, d’Android. Google n’a pas apprécié le fait que son développeur ait la riche idée de distribuer avec son mod, les applications propriétaires qui lui sont chères. Citons par exemple : GMail, YouTube, Maps et Market. Nul besoin de dire que le système perd de son intérêt quand il est privé de ces outils estampillés Google…

Le spécialiste de la recherche a donc demandé l’interruption de toute distribution de ce mod, en attendant que le développeur trouve un moyen de livrer de l’Android sans aucune des G-Apps. C’est un baptême du feu pour ce système que Google a voulu ouvert. D’aucun disent que Google avait la possibilité de créer une alternative libre au jardin d’Eden d’Apple entouré de hauts remparts, à la place ce sera un autre jardin avec des murs un peu plus bas.

MIDP 3 et MSA 2 pour sauver J2ME ?

Mobile Information Device Profile (MIDP), associé à Connected Limited Device Configuration (CLDC) constitue l’API de base de J2ME, c’est cette architecture qui constitue le parc de 2 milliards de devices revendiqués par SUN.

La JSR-248 (Mobile Service Architecture), quant à elle, définit un ensemble d’APIs additionnelles pour les environnements MIDP J2ME apportant chacune un service particulier permettant souvent d’accéder à des fonctionnalités matérielles sous-jacentes (Bluetooth, GPS, Camera, …).

Ces deux piliers de J2ME sont en train d’évoluer avec la finalisation de MIDP 3 et MSA 2. Tandis que le premier apportera un rafraichissement de l’API de base de J2ME, le second poussera plus loin les possibilités d’intégration des applications mobiles J2ME.

Alors que les valeurs montantes du moment dans le monde du développement mobile sont clairement les plates-formes Android et iPhone, le rafraîchissement des APIs J2ME vieillissantes est le bienvenue et viendra épauler JavaFX Mobile dans son hypothétique ascension. On peut toutefois douter que cela suffira à inverser la tendance même si J2ME, fort de son parc colossal, n’est clairement pas menacé à court terme.

Agilité

Départs de la Scrum Alliance : bruits de couloirs

Vous le savez surement, la fin de l’été a marqué un tournant au sein de la Scrum Alliance.
Le 15 Septembre, dans un communiqué laconique (et très américain – nous remercions … blablabla pour son excellent travail … blabla), il nous était annoncé le départ de deux éminents membres de la Scrum Alliance, Ken Schwaber (son CEO) et Jim Cundiff (son Managing Director).
Après une enquête acharnée et au détour de quelques indiscrétions de sources (que nous ne citerons pas), il s’avère que Ken a eu un grave accident de vélo et que Jim a été démissionné compte tenu de ses manquements dans la refonte du processus de certification dont il était en charge.

RIA

Sécurité : 13 choses que les agresseurs d’applications web ne vous diront pas

Le Denim Group regroupe dans 13 Things a Web Applications Attacker Won’t Tell You les principales failles de sécurité de nos applications web :

1. Transformer une requête GET en POST ne cachera pas les paramètres même s’ils n’apparaissent plus dans la barre d’adresse du navigateur (vérifiez avec Charles Proxy ou Fiddler si vous en doutez).
2. Utiliser un champ de formulaire hidden ne permet ni de cacher une information ni d’empêcher sa modification.
3. Idem pour les cookies (voir #1).
4. Contrôler les données coté client avec du javascript ne m’empêchera pas de modifier leur valeur.
5. J’aime vous entendre dire « Cela n’arrivera jamais en production ».
6. Et j’adore quand vous dites « Un pirate ne ferait jamais ça ».
7. Je déteste les validations strictes cote serveur.
8. Cette page d’erreur avec le message détaillé me facilite tellement la vie.
9. La plupart des bannières « Sécurité Garantie ! » ne me servent qu’a voir que vous n’avez pas compris les bases de la sécurité.
10. Ce scanneur d’application web que vous avez lancé, il n’a rien trouvé. Il n’a même pas effleuré les failles de votre application.
11. Ce scanneur réseau que vous avez lancé, il n’a même pas commencé a tester la sécurité de votre application.
12. Je connais AJAX (et toutes les nouvelles technologies a la mode) mieux que vous et mieux que vous ne pouvez imaginer.
13. Le plus astucieux vous vous croyiez, le mieux je me sens.

Moralité, soyons humble et rigoureux, nous ne pourrons pas dire que nous ne savions pas, ces conseils sont répétés par la plupart des tutoriaux de frameworks web :-).

Le coin de la technique

Les roadmaps des implémentations de JPA 2.0

Alors que la JSR-317 (Java Persistence API 2.0) vient de diffuser une Proposed Final Draft 2 et que sa finalisation approche, nous souhaitions faire un tour d’horizon des principales implémentations en préparation. Comme c’est souvent le cas avec les JSRs, les développeurs n’attendent pas la finalisation des spécifications pour commencer à les implémenter. Ainsi, on se souvient que JPA 1.0, intégré à la JSR-220 (Enterprise JavaBeans 3.0) avait fait l’objet d’implémentations alpha chez JBoss dès la diffusion des early drafts, ce qui avait permis la stabilisation du conteneur peu après la finalisation de la JSR.

• Hibernate : l’équipe de développement Hibernate a annoncé fin aout la disponibilité d’une version 3.5 beta 1 qui implémentait la majorité des nouveautés de JPA 2.0. Aucune indication n’était alors donnée sur la date de finalisation, mais le bon avancement permet de supposer qu’elle arrivera rapidement. A noter toutefois que certaines optimisations importantes telles que la compilation des requêtes criteria n’arriveront que dans une version ultérieure.
• EclipseLink : la fondation Eclipse avait annoncé fièrement en début d’année 2008 qu’EclipseLink serait l’implémentation JPA 2.0 de référence. Une roadmap mise à jour en avril dernier fait état d’une version 2.0 d’EclipseLink implémentant JPA 2.0 pour l’automne 2009.
• Apache OpenJPA : le projet OpenJPA maintient une roadmap très rigoureuse tablant sur un démarrage de phase release candidate pour la fin de l’année. Il s’agira de la version 2.0 d’OpenJPA, elle est actuellement développée sur le trunk du projet.

La première version de la spécification JPA a été un succès puisque de nombreux développeurs ont reconnu sa légitimité et l’ont adopté dans leurs projets plutôt que de se reposer sur l’API propre à leur framework de persistance. Toutefois, pour certaines fonctionnalités telles que les requêtes criteria ou des options de mapping évoluées, il était jusqu’alors nécessaire de contourner JPA. Dès lors, on imagine aisément que JPA 2.0, comblant les manques de son ainée, bénéficiera d’une large adoption. La disponibilité des moteurs JPA 2.0 qui seront utilisés par JBoss AS, Glassfish et WebSphere autour de la fin de l’année devrait par ailleurs accélérer l’omniprésence de cette nouvelle API.

Web Beans est mort ! Longue vie a Weld !

Apres les bruits de couloir de la Scrum Alliance, nous continuons la rubrique people avec une fois encore Web Beans. Après le changement de nom de la JSR 299 en Java Contexts and Dependency Injection, voici que la Reference Implementation se rebaptise Weld.
Pendant ce temps, la JSR 330: Dependency Injection for Java continue son chemin avec son implémentation partielle dans Spring Framework 3.0 RC1 et son intégration dans Google Guice.