samedi 4 août 2012

Veille technologique semaine 31

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • La fonctionnalité de modularité de Java est reporté pour le JDK 9 ce qui provoque beaucoup de déception.
  • Un résumé d'une thèse au sujet des transactions mémoires, pour résoudre les problèmes de la programmation concurrente avec les processeurs multi-coeurs. Le projet TMJava propose ces transactions mémoire.
  • Terracotta propose un produit BigMemory qui est capable de répliquer certifié jusqu'à 4TB de mémoire centrale par JVM (4 Terra Byte = 4000 Giga Byte).
  • Un article de fond proposé par l'université de Lille qui réalise une projection d'un modèle de composants PIM (Platforme Independant Model) vers un modèle de composant PSM (Plateforme Dependant Model) Fractal ou OpenCOM par des techniques de manipulation de binaire réalisé par des outils de programmation par aspects (AOP : Aspect Oriented Programming). La projection PIM -> PSM est en dehors du modeleur UML.
  • Un introduction du langage de programmation Groovy, écrit par Oracle. Le code listé en exemple est-il du code Groovy ?
  • Comment utiliser le builder d'interface de JavaFX et sont intégration dans NetBeans 7.2 pour construire rapidement un IHM.
Bonne lecture.



Reactions to Mark Reinhold's Recent Announcement of Project Jigsaw's Delay

Java developers across the ecosystem have been swift to react to Mark Reinhold's announcement last week that project Jigsaw, Oracle's planned modularity framework for Java, will now be delayed until Java 9, as previously reported on InfoQ. Jigsaw was originally scheduled to ship with Java 7 in 2011, then was deferred to Java 8, and is now delayed again until 2015.

The reactions to Mark Reinhold's blog are broadly divided into three camps:
1. Good agile development: Release early, release often; if Jigsaw is late defer it to the next release and deliver Java 8 on time.
2. Java 8 without Jigsaw is not worth the disk it's written to. Just wait for Jigsaw.
3. Jigsaw has already been delayed twice and who knows if it will ever be delivered. Give up, Oracle and put your weight behind an existing technology.

Project Jigsaw is intended to deliver on two distinct sets of requirements:
1. Separate the Java platform into distinct, independent modules that can be excluded until needed.
2. Provide a platform for building and delivering modular applications.

Reactions to the news seem to depend on where people fall between those two poles:


Semantics, performance and language support for transactional memory
Avec l'apparition des architectures multi-cœurs, les programmeurs doivent écrire des programmes concurrents pour exploiter pleinement la capacité de calcul de ces architectures. Actuellement, l'écriture des programmes concurrents est, en général, réalisée en utilisant les verrous, mais écrire un programme correct avec cette approche est difficile. Une approche récente pour simplifier la programmation concurrente est d'introduire des blocs transactionnels dans les langages de programmation. De tels blocs de code sont délimités par des éléments spécifiques du langage et s'exécutent de manière transactionnelle (c.à.d. le bloc peut être avorté et reexécuté au besoin). Inclure ces blocs de langage masque au programmeur la synchronisation des données entre fils d'exécution concurrents et, par conséquent, offre une alternative attractive à l'utilisation des verrous.

Malgré ses avantages, cette approche doit satisfaire les exigences suivantes pour qu'un programmeur soit convaincu d'utiliser des blocs transactionnels: (i) la sémantique du comportement transactionnel doit être simple et claire (ii) la performance d'un code utilisant des blocs transactionnels doit passer à l'échelle par rapport au nombre de fils d'exécutions concurrents (à condition que la charge de travail représentée par le code le permette) et doit en même temps offrir une performance supérieure à celle de l'exécution séquentielle lorsque le code s'exécute sur plusieurs fils d'exécution, et (iii) le support de langage associé aux blocs transactionnels doit être simple à utiliser, tant en termes de syntaxe que d'intéropérabilité avec les autres éléments de langage. Les premières deux conditions doivent être satisfaites par le support d'exécution, nommé Mémoire transactionnelle (MT), qui réalise le comportement transactionnel. Malgré l'existence de nombreuse MTs, il n'y a pas d'approche pour vérifier si elles satisfont ces deux conditions en même temps. De plus, il n'existe que peu de travaux visant à avoir un support de langage riche pour satisfaire la troisième condition. La présente thèse propose des solutions à chacun de ces problèmes à travers deux nouveaux outils: TMunit et TMJava.

TMunit est l'outil proposé aux programmeurs pour vérifier si une MT satisfait certaines conditions en termes de sémantique et de performance. La possibilité d'expérimenter avec ces deux aspects (sémantiques et performance) des MTs rend TMunit unique pour la conception des MTs. Côté sémantique, TMunit est capable de décrire des scénarios au niveau des opérations transactionnelles, et permet donc de définir des tests détaillés pour vérifier la sémantique des MTs. Côté performance, TMunit permet d'évaluer la performance des MTs en décrivant des scénarios plus complexes où les motifs d'accés aux données partagées peuvent être spécifié. TMunit propose une interface abstraite qui lui permet de stimuler n'importe quelle MT et il est accompagné d'une batterie de test pour que les aspects communs de sémantique et performance des MTs puissent être vérifiés aisément.

TMJava vise un support de langage riche pour les blocs transactionnel. Il propose une extension pour Java sous forme d'élément de langage transactionnels qui fournissent (i) la synchronisation des données automatisées, (ii) le flot de contrôle transactionnel, et (ii) un traitement des exceptions augmenté. L'atout distinctif de TMJava est le fait qu'il propose l'utilisation des blocs transactionnels non seulement pour la synchronisation des données, mais aussi pour le traitement des exceptions (qui n'est pas abordé par les autres approches existantes). En particulier, TMJava introduit une extension de langage novatrice, Atomic Boxes, qui permet aux programmeurs de traiter les exceptions de manière coordonnée. Cette extension est surtout intéressante pour propager les exceptions parmi tous les fils d'exécution concernés et pour exécuter des actions coordonnées de récupération d'exception à partir d'un état sûr du programme concurrent.



Terracotta BigMemory 3.7: Multi-Terabyte Support, Improved Search, Enhanced Security
Terracotta Inc has released BigMemory 3.7, an off-heap store snap-in for Enterprise Ehcache. BigMemory speeds up applications by keeping data in memory, without the long garbage collection pauses that is common for large JVM heap sizes. New in this version is support for multi-terabyte servers, lower search indexing overhead, and enhanced security.
BigMemory 3.7 now officially supports up to 4TB per JVM. Although BigMemory has no theoretical upper limit, it has now been officially tested and certified on multi-terabyte machines. BigMemory 3.7 has also implemented data compression, which allows it to store more data in memory.


Leveraging Component-Based Software Engineering with Fraclet
Component-based software engineering has achieved wide acceptance in the domain of software engineering by improving productivity, reusability and composition. This success has also encouraged the emergence of a plethora of component models. Nevertheless, even if the abstract models of most of lightweight component models are quite similar, their programming models can still differ a lot. This drawback limits the reuse and composition of components implemented using different programming models.


The contribution of this article is to introduce Fraclet as a programming model common to several lightweight component models. This programming model is presented as an annotation framework, which allows the developer to annotate the program code with the elements of the abstract component model. Then, using a generative approach, the annotated program code is completed according to the programming model of the component model to be supported by the component runtime environment.


This article shows that this annotation framework provides a significant simplification of the program code by removing all dependencies on the component model interfaces. These benefits are illustrated with the Fractal and OpenCOM component models.


Introducing Groovy
the basics of Groovy, a general-purpose scripting language that runs on the Java Virtual Machine (JVM).

Groovy is a general-purpose scripting language that runs on the Java Virtual Machine (JVM) and can largely be viewed as a superset of Java. For
example, take the program shown in Listing 1. Is it a Groovy program or a Java program?

public class Hello {
   String name;

   public void sayHello() {
      System.out.println("Hello "+getName()+"!");
   }

   public void setName(String name) {
      this.name = name;
   }

   public String getName() {
       return name;
   }

   public static void main(String[] args) {
      Hello hello = new Hello();
      hello.setName("world");
      hello.sayHello();
      }
   }


How to Get Started (FAST!) With JavaFX 2 and Scene Builder
A question I hear all too often is "How do I get started with JavaFX and/or Scene Builder?" Like most tools/toolsets, there are as many ways to use these implements as there are developers...but shouldn't there be an easy way to "hit the ground running"? While casting about for an end-to-end example, demo, or video, I found a wealth of useful information, but I couldn't find anything that took someone from start to finish, quickly and easily. JavaFX is easy and fun. But don't take my word for it; let's give it a try!


Aucun commentaire: