Lors de la dernière édition de la conférence JavaOne, Oracle annonçait la release du projet open source : Avatar
C'est lors de l'édition 2011 que le projet avait été annoncé.

Aujourd'hui, l'ensemble des applications Web définissent une architecture SPA (Single Page Application). Dans ce type d'application, l'ensemble de la logique est déportée du serveur vers le client, où l'on retrouve l'ensemble des composants modèle, vue et contrôleur. Pour aider à l'implémentation, il existe une multitude de frameworks (Angular.js, Backbone.js, …)

Ce type d'architecture requiert une connaissance avancée de Javascript.

L'idée du projet Avatar est de proposer un framework basé, entre autres, sur Javascript côté serveur et HTML5 coté client. 

C'est-à-dire que toute la stack technique côté serveur est basée sur Javascript (un schéma très clair est disponible ici : https://avatar.java.net/docs/overview.html). 
Cette couche a pour objectif de fournir des services basés sur un protocole 'standard' (REST et Websoket).

La partie cliente sera basée principalement sur HTML5 et propose un découplage net entre la vue et la couche de service.
Le framework facilite la conception et la réalisation d'application de type SPA.
Un point original : La documentation du projet indique que les développeurs ont seulement besoin de faire des copier/coller à partir d'exemples, et ensuite adapter le code pour bâtir une application.  

L'utilisation de Javascript n'est pas là pour remplacer Java, mais plutôt comme une nouvelle possibilité dans les choix d'implémentation côté serveur.
Il est naturellement possible d'utiliser conjointement les deux langages (cas d'une ancienne API écrite en Java, par exemple).

Les pré requis techniques : 
– un conteneur compatible avec la spec JavaEE 7, 
– un runtime Java 8

L'interprétation du Javascript côté serveur sera assurée par le runtime issu du projet Nashorn.

Le projet est sous licence open source et le code est disponible sur github.
La documentation du projet est bien faite et permet une prise en main aisée de l'outil.

Avatar permet à Oracle d'intégrer dans son socle technique qu'est la stack JavaEE, la possibilité d'implémenter facilement des applications aux architectures contemporaines.

Je me souviens que lors d'un épisode du podcast des castcodeurs, Antonio Goncalvez exprimait le regret de l'absence d'un outil tel que Avatar dans la stack JavaEE… visiblement son vœu a été exaucé.

#java #javaEE7 #Avatar

Voici un pointeur vers un article que je trouve assez original : Débogage en Java/JavaEE

Même si cela peut paraître évident pour des vétérans du développement en java, l’article peut être vraiment intéressant pour les petits juniors qui débarquent sur des projets informatique de la vraie vie :).

Je sais que la notion de débogage dans le développement est un sujet à point de vue divergent.
Je pense que le débogage est une bonne chose et c’est comme toutes les bonnes choses, il ne faut pas en abuser.

Dans tous les cas cet article fait un point sur les différentes techniques et donnera sûrement des billes à celui qui débute et qui se retrouve sur application 5 ou 6 ans d’ages.

Cet article ne s’adressera pas sûrement au plus senior d’entre nous, mais une lecture rapide ne peut jamais faire de mal

Bonne lecture!

#java   #debug   #javaEE  

Courant juillet 2012, Oracle annoncait  le  report du projet Jigsaw de la version 8 à la version 9 du JDK.  Ce décalage de release était du à un problème de temps et des soucis techniques rencontrés. Nous en avions parlé lors d’un post sur cette page : https://plus.google.com/112440333946538821016/posts/MrYT1eBkTnV

Aujourd’hui, c’est au tour de la plateforme Java EE d’annoncer un changement dans sa roadmap initialement prévue au quatrième trimestre 2012.

C’est sur le blog d’Oracle que la nouvelle est tombée le 30 août 2012 annoncant que toute la partie Cloud ( Paas et la mutualisation) est reportée sur JavaEE 8.
Les raisons données, par la responsable de la spécification JavaEE 7, Linda DeMichiel, sont liées à une avancée lente sur toute cette partie par rapport aux planifications.

D’après les explications données par Linda, ces ralentissements sur l’agenda  sont du principalement  :
– au manque de maturité des technologies du cloud (mutualisation, déploiement d’application, etc) 
– ainsi qu’à la volonté, des équipes d’Oracle, de vouloir faire les choses correctement, compte tenu de l'expérience limitée de l'industrie dans le domaine de nuages ​​lorsque le travail a été entamé.

En gardant la cible initiale JavaEE 7 pour ces fonctionnalités, cela aurait eu pour conséquence de décaler la release au printemps 2014, soit un décalage de 2ans.
Le report des fonctionnalités liées au Cloud présente les avantages suivants : 
– Cela permettra aux revendeurs des platformes JavaEE de gagner en expérience sur leur implémentations dans ce domaine.
– La communauté n’aura pas à supporter le prix des fonctionnalités nécessitant plus de temps à mettre en place. 
– parce que dans Java EE 7, une partie des bases nécessaires à l’infrastructure du Cloud ont déjà été posées (définition des métadatas, amélioration de la configuration de la couche de sécurité,etc). Ces bases permettront d’accélérer la livraison de JavaEE 8 (estimée au printemps 2015).

Au delà des avantages présentés ci-dessus, cette modification de planning permettra au équipes de : 
– garder un focus sur l’amélioration de la simplification et de la convivialité de la platforme
– livrer dans les temps les fonctionnalités largement plébiscitées par les développeurs (Websocket, JSON-P, la simplification de l’api JMS  2.0, etc).

On comprend que la réduction du scope des fonctionnalités est un choix plutôt raisonnable. En effet, l’entreprise préfère tenir son planning en terme de date et fournir des fonctionnalités très attendues par la communauté ; au détriment du Cloud qui aurait imposé un décalage de livraison important. 
Comme on dit : “mieux vaut tenir que courir”. En espérant qu’il n’y ait pas de nouveaux rebondissements, rendez-vous au quatrième trimestre 2012…

#java #javaEE7 #javaEE8 #annonce #report