Revue de Presse Xebia

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

Actualité éditeurs / SSII

Le coin de la technique

Actualité éditeurs / SSII

Google Android disponible en Open Source

Google a officiellement mis à disposition le code source de la plateforme Android et encourage les développeurs à la tester.

Cette annonce survient au moment du lancement du nouveau téléphone le HTC Dream G1 de HTC par T-Mobile aux États-Unis. Le code source est livré sous licence Apache, ce qui implique que son utilisation est gratuite et que les développeurs ne sont pas tenus de rendre public le code source de leurs nouveaux produits.

Le code source d’Android est à présent disponible au téléchargement à l’adresse suivante : http://source.android.com/download.

Quant à ceux qui souhaiteraient développer des applications pour ces téléphones, Google recommande Ubuntu comme environnement de programmation pour Android (il est également possible d’utiliser MacOS).

Amazon EC2 passe en production

Le service d’hébergement d’applications Amazon EC2 n’est plus une bêta depuis le 23 octobre. Aurait-on donc de nombreux changements à se mettre sous la dent ?
Pas vraiment. La seule « révolution » est l’introduction d’un SLA (Service Level Agreement, autrement dit un engagement de résultat) qui garantit une disponibilité à 99.95% du temps. Si le taux de service chute sous cette barre, le client peut remplir une demande et accéder à des remises commerciales (autant dire qu’Amazon a dû considérablement stresser son système avant d’annoncer de tels chiffres).

Dans un futur proche, le service d’Amazon devrait se voir enrichi des fonctionnalités suivantes :

  • Console d’administration.
  • Load Balancing.
  • Adaptation automatique à la charge (AutoScaling).
  • Monitoring global de l’ensemble des instances.

ainsi que de nouveaux logiciels : Windows Server 2003, SQL Server Standard 2005 ou Express (déjà disponibles en bêta), Windows Server 2008 (à venir)

Une nouvelle pierre dans le jardin des hébergeurs traditionnels…

Le coin de la technique

Sortie de Seam 2.1.0.GA

Dans une précédente revue de presse, nous vous avions présenté les nouveautés de Seam 2.1. L’équipe Seam concrétise ces nouveautés avec la sortie officielle de Seam 2.1.0.GA.

Seam 2.1.0.GA intègre les composants suivants :

  • RichFaces 3.2 (implémentation JSF de JBoss).
  • GWT (Google).
  • Wicket (Apache) (exemple d’intégration de Wicket dans Seam : Seamless Wicket: Orchestrating your application).
  • Groovy 1.5 (pour rappel il est possible d’écrire des composants Seam avec le langage Groovy).
  • JBoss Cache 2 (ou JBoss Cache ou EHCache).
  • JAX-RS (REST) via l’implémentation du projet JBoss RestEasy.
    A noter que RestEasy n’est actuellement qu’en version bêta.
  • Documentation pour intégrer Seam dans d’autres containers que JBoss AS : WebLogic, WebSphere, OC4J et Glassfish.

Prochaine étape : Seam 2.1.1, l’équipe s’attachera à encore améliorer les performances, la scalabilité et le clustering de Seam.

En parallèle, la spécification Web Beans commence à pointer le bout de son nez : Web Beans Teaser.

Félicitation à l’équipe Seam pour le travail qui a été réalisé.

JBoss AOP 2.0.0 disponible, JBoss AS 5 se rapproche …

La sortie officielle de la version 2.0.0 de JBoss AOP vient d’être annoncée. Après s’être posé la question en début de semaine, Kabir Khan a finalement décidé de publier celle-ci. Doit-on y voir les signes avant-coureurs d’une sortie imminente du nouveau serveur d’applications made in JBoss ? Il est encore un peu tôt pour le dire. Notez tout de même que JBoss AS 5 est en RC2 depuis déjà plus d’un mois, date à laquelle il avait franchi la plus grande marche lui restant à gravir (La Certification JEE).

Pour en revenir au cœur du sujet, si JBoss AOP est directement intégré au sein du futur serveur d’applications, rien ne vous empêche d’utiliser celui-ci en standalone. La meilleure présentation de ce framework reste l’article de 5 pages publié sur DZone cet été : An Introduction to Aspect-Oriented programming with JBoss AOP qui en présente les principales nouveautés :

  • Un nouveau mode de weaving permettant l’ajout d’advices autour des exceptions (before / after / throwing / finally).
  • L’interception des accès à chaque élément d’un tableau.
  • Un déploiement et une mise à jour à chaud des advices et des interceptors.
  • Une intégration avec le microcontainer JBoss AS 5.

Autres liens :

Embedded Jopr pour JBoss AS : une console JMX de nouvelle génération

JBoss vient de mettre à disposition de la communauté une console JMX nouvelle génération pour la supervision et l’administration d’une instance du serveur JBoss AS. La console est une application web basée sur le framework Seam. Le code source de l’application est livré sous licence LGPL.

Une particularité de la nouvelle console est la possibilité d’intégrer des plugins de RHQ et Jopr.

La version 1.0 offre la possibilité de gérer l’instance du serveur et les instances des applications d’entreprise, de mettre à jour les configurations, de contrôler les activités et d’exécuter les scripts qui résident dans le répertoire bin du serveur JBoss AS.

Une capture d’écran de la console :

Une présentation vidéo flash de la console Embedded Jopr en action : http://www.jboss.org/embjopr/demo.html#.

Exemples de la JSR 203 (la nouvelle nouvelle JSR I/O)

Les exemples concernant cette JSR NIO2 (dont nous vous parlions déjà dans une revue de presse précédente) continuent d’affluer.

Récemment, c’est Alex Miller (examples and more features) qui nous propose des exemples d’utilisation balayant quelques nouvelles fonctionnalités de cette API.

Parmi ces changements, et pour ne garder que ceux qui nous simplifieront la vie (et surtout les lignes de code), nous retiendrons :

  • L’objet central n’est plus File mais Path : il faudra donc, comme pour le Path d’Eclipse RCP, raisonner en « segments » (une liste de noms) représentant une hiérarchie, le dernier niveau représentant le fichier ou le dossier pointé.
  • Méthodes copyTo et moveTo directement intégrées à l’objet : et oui, terminé les Streams pour une copie ou un déplacement ! Il suffit d’avoir le Path d’origine, de définir le Path de destination et d’opérer directement l’opération souhaitée telle que fromPath.copyTo(toPath) ou fromPath.moveTo(toPath).
  • Itérateurs améliorés : recherche de fichiers à partir d’un filtre (DirectoryStream) ou d’un visiteur (SimpleFileVisitor). Là encore, on a la possibilité d’effectuer un traitement métier soit sur un type de fichier spécifique (défini par exemple par l’extension du fichier) soit sur tous les fichiers présents dans un dossier.
// Filter
DirectoryStream xmlFiles = myFolderWithXmlFiles.newDirectoryStream("*.xml");
for (Path xmlFile : xmlFiles ) {
   // Stuff...
}
// Visitor
Files.walkFileTree(myFolerToVisit, new SimpleFileVisitor() {
   public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) {
      // Stuff...
   }
});
  • Lecture des attributs des fichiers dont les principaux sont :
// Standard file attributes
BasicFileAttributes attrs = Attributes.readBasicFileAttributes(Path.get("test.xml"), true);
TimeUnit scale = attrs.resolution();
new Date(scale.toMillis(attrs.creationTime));
new Date(scale.toMillis(attrs.lastAccessTime));
new Date(scale.toMillis(attrs.lastModifiedTime));
attrs.isDirectory();attrs.isFile();attrs.isSymbolicLink();attrs.isOther();attrs.size();
...
// Dos file attributes
DosFileAttributes attrs = Attributes.readDosFileAttributes(Path.get("test.xml"), true);
attrs.isArchive();attrs.isReadOnly();attrs.isHidden();attrs.isSystem();
...
// Posix file attributes
PosixFileAttributes attrs = Attributes.readPosixFileAttributes(Path.get("test.xml"), true);
attrs.permissions();attrs.owner();attrs.group();
...

Cette très attendue API est prévue pour Java 7.

JVM 64 bits ? Oui mais avec compression des pointeurs

La généralisation des processeurs x86 et des systèmes d’exploitation 64 bits amène les exploitants à étudier l’utilisation de JVM 64 bits pour les serveurs d’applications Java. Si les JVM 64 bits permettent d’allouer de larges heap (> 3 Go), l’augmentation de la taille des pointeurs (de 4 à 8 octets) nuit aux performances et à la consommation mémoire (cf Revue de Presse du 26/05/2008).

C’est ce que montre David Dagastine, Java Platform Performance Lead, dans son article No Tuning Required: Java SE Out-of-Box Vs. Tuned Performance » >*No Tuning Required: Java SE Out-of-Box Vs. Tuned Performance*. Lorsque Sun configure ses JVM x86 pour SpecJbb2005, la mémoire allouée à la JVM 64 bits est le double de celle allouée à la version 32 bits alors que les performances de cette version 32 bits sont tout de même 13% meilleures que celles de la version 64 bits.

Marcus Lagergren (BEA Systems) et Bob Kasten (Intel) exposent la parade mise en place par BEA :
Oracle/BEA : Aim High with JRockit on Intel Architecture

JRockit 64 bits offre depuis la version 5.0-R26.4 un mécanisme de compression des pointeurs (-XXcompressedRefs, activé par défaut si la taille de la heap est inférieure à 4 Gb) pour concilier les performances et la consommation mémoire des JVM 32 bits avec l’allocation de larges Heap spécifique aux 64 bits.

JRockit 5.0 R26-4 release notes : « Compressed references has greatly increased the performance on 64-bit platforms. »

Aujourd’hui, seuls les mécanismes de compression de pointeurs disponibles sur les JVM JRockit 5.0+ et IBM 6.0 permettent d’utiliser des JVM 64 bits sans dégradation des performances (10-20%) ni augmentation de la consommation heap (> 50%). Ces mécanismes ne sont pas encore disponibles sur la JVM de Sun.

Pour conclure, on citera les communications « officielles » de Sun et d’IBM sur ce sujet :

Sun : FAQ About the Java HotSpot VM / What are the performance characteristics of 64-bit versus 32-bit VMs?

« Generally, the benefits of being able to address larger amounts of memory come with a small performance loss in 64-bit VMs versus running the same application on a 32-bit VM. This is due to the fact that every native pointer in the system takes up 8 bytes instead of 4.

The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. »

IBM Java Technology Center: What’s the Difference Between 32 and 64 Bit Java? (pdf)

« At Java 5, 64 bit can be around 20% slower than corresponding 32 bit runtime

We assume a ~20-30% increase in object size heap consumption – but can be much larger »

Commentaire

2 réponses pour " Revue de Presse Xebia "

  1. Published by , Il y a 15 ans

    Pas de dégradation de perf avec une JVM Sun Hotspot 64-bit sur AMD (je ne sais pas pour Intel, je n’ai pas d’info récente là dessus).
    Ceci dit, une autre question est de savoir combien de serveurs d’applications sont supportés sur JVM 64-bit. C’est encore assez marginal car le besoin pas évident (monter une base complètement en mémoire, gérer des 100aines de milliers de sessions SIP, …). Au passage 32 bits => 2^32 = 4Go max en théorie, en pratique c’est plus proche de 3.5Go, voir de 1.5Go quand on perd un bit (2^31).

Laisser un commentaire

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

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.