jeudi 11 juillet 2019

JEP 352: Non-Volatile Mapped Byte Buffers

Je vous propose un article sur l'intégration, dans le JDK 14, d'une classe tableau d'octet (ByteBuffer) qui est connecté
à de la mémoire non volatile : le contenu de cette mémoire n'est pas perdu lorsque l'alimentation est coupée (c'est de la RAM non volatile, pas un SSD).

Cette mémoire non volatile est utilisable pour la persistance des données : elles survivent à l'arrêt du programme.


Analyse :
Par rapport à cette évolution du hard (cette mémoire centrale non volatile), on comprend que la technologie matérielle évolue demande des changements des solutions logicielles. Ces changements doivent impacter les socles technologiques (socle au sens classique du terme),
mais ne devrait pas impacter le code fonctionnel : ceci est vrai lorsqu'il y a une parfaite séparation entre le code fonctionnel et les propriétés non
fonctionnelles comme la persistance.

La solution pour la persistance des données va peut être changer avec cette technologie : à fonctionnalité identique :
la persistance est une exigence (un besoin), un système de fichier, une base de donnée ou une mémoire non volatile sont des solutions.

Si cette technologie de mémoire non volatile se démocratise (inclus le prix), on peut imaginer un processeur 64 bits
avec 1To de mémoire centrale non volatile, en direct sur son bus de données (et pas via un PCI-Express comme les SSD actuel).

Il faudra modifier les OS pour leur demander d'effacer la mémoire ce qui ne doit pas être persistant (le droit à l'oubli ;-) ).
La persistance sera de base, la non persistance devra être ajouter ?

A suivre ...

https://openjdk.java.net/jeps/352

JEP 352: Non-Volatile Mapped Byte Buffers
Summary
Add new JDK-specific file mapping modes so that the FileChannel API can be used to create MappedByteBuffer instances that refer to non-volatile memory.
Goals
This JEP proposes to upgrade MappedByteBuffer to support access to non-volatile memory (NVM). The only API change required is a new enumeration employed by FileChannel clients to request mapping of a file located on an NVM-backed file system rather than a conventional, file storage system. Recent changes to the MappedByteBufer API mean that it supports all the behaviours needed to allow direct memory updates and provide the durability guarantees needed for higher level, Java client libraries to implement persistent data types (e.g. block file systems, journaled logs, persistent objects, etc.). The implementations of FileChannel and MappedByteBuffer need revising to be aware of this new backing type for the mapped file.
The primary goal of this JEP is to ensure that clients can access and update NVM from a Java program efficiently and coherently. A key element of this goal is to ensure that individual writes (or small groups of contiguous writes) to a buffer region can be committed with minimal overhead i.e. to ensure that any changes which might still be in cache are written back to memory.
A second, subordinate goal is to implement this commit behaviour using a restricted, JDK-internal API defined in class Unsafe, allowing it to be re-used by classes other than MappedByteBuffer that may need to commit NVM.
A final, related goal is to allow buffers mapped over NVM to be tracked by the existing monitoring and management APIs.
N.B. It is already possible to map a NVM device file to a MappedByteBuffer and commit writes using the current force() method, for example using Intel's libpmem library as device driver or by calling out to libpmem as a native library. However, with the current API both those implementations provide a "sledgehammer" solution. A force cannot discriminate between clean and dirty lines and requires a system call or JNI call to implement each writeback. For both those reasons the existing capability fails to satisfy the efficiency requirement of this JEP.
The target OS/CPU platform combinations for this JEP are Linux/x64 and Linux/AArch64. This restriction is imposed for two reasons. This feature will only work on OSes that support the mmap system call MAP_SYNC flag, which allows synchronous mapping of non-volatile memory. That is true of recent Linux releases. It will also only work on CPUs that support cache line writeback under user space control. x64 and AArch64 both provide instructions meeting this requirement.
Non-Goals
The goals of this JEP do not extend beyond providing access to and durability guarantees for NVM. In particular, it is not a goal of this JEP to cater for other important behaviours such as atomic update of NVM, isolation of readers and writers, or consistency of independently persisted memory states.
Recent Windows/x64 releases do support the mmap MAP_SYNC flag. However, the goal of providing this capability for that OS/CPU combination (or any other possible other platforms) is deferred to a later update.
Success Metrics
The efficiency goal is hard to quantify precisely. However, the cost of persisting data to memory should be significantly lowered relative to two existing alternatives. Firstly, it should significantly improve on the cost incurred by writing the data to conventional file storage synchronously, i.e., including the usual delays required to ensure that individual writes are guaranteed to hit disk. Secondly, the cost should also be significantly lower than that incurred by writing to NVM using a driver-based solution reliant on system calls such as libpmem. Costs might reasonably be expected to be lowered by an order of magnitude relative to synchronous file writes and by a factor of two relative to using system calls.
Motivation
NVM offers the opportunity for application programmers to create and update program state across program runs without incurring the significant copying and/or translation costs that output to and input from a persistent medium normally implies. This is particularly significant for transactional programs, where regular persistence of in-doubt state is required to enable crash recovery.
Existing C libraries (such as Intel's libpmem) provide C programs with highly efficient access to NVM at the base level. They also build on this to support simple management of a variety of persistent data types. Currently, use of even just the base library from Java is costly because of the frequent need to make system calls or JNI calls to invoke the primitive operation which ensures memory changes are persistent. The same problem limits use of the higher-level libraries and is exacerbated by the fact that the persistent data types provided in C are allocated in memory not directly accessible from Java. This places Java applications and middleware (for example, a Java transaction manager) at a severe disadvantage compared with C or languages which can link into C libraries at low cost.
This proposal attempts to remedy the first problem by allowing efficient writeback of NVM mapped to a ByteBuffer. Since ByteBuffer-mapped memory is directly accessible to Java this allows the second problem to be addressed by implementing client libraries equivalent to those provided in C to manage storage of different persistent data types.
Description
Preliminary Changes
This JEP makes use of two related enhancements to the Java SE API:
1.        Support implementation-defined Map Modes (JDK-8221397)
2.        MappedByteBuffer::force method to specify range (JDK-8221696)
Proposed JDK-Specific API Changes
1.        Expose new MapMode enumeration values via a public API in a new module
A new module, jdk.nio.mapmode, will export a single new package of the same name. A public extension enumeration ExtendedMapMode will be added to this package:
package jdk.nio.mapmode;
. . .
public class ExtendedMapMode {
   private ExtendedMapMode() { }

   public static final MapMode READ_ONLY_SYNC = . . .
   public static final MapMode READ_WRITE_SYNC = . . .
}
The new enumeration values are used when calling the FileChannel::map method to create, respectively, a read-only or read-write MappedByteBuffer mapped over an NVM device file. An UnsupportedOperationException will be thrown if these flags are passed on platforms which do not support mapping of NVM device files. On supported platforms, it is only appropriate to pass these new values as arguments when the target FileChannel instance is derived from a file opened via an NVM device. In any other case an IOException will be thrown.
2.        Publish a BufferPoolMXBean tracking persistent MappedByteBuffer statistics
The ManagementFactory class provides method List<T> getPlatformMXBeans(Class<T>) which can be used to retrieve a list of BufferPoolMXBean instances tracking count, total_capacity and memory_used for the existing categories of mapped or direct byte buffers. It will be modified to return an extra, new BufferPoolMXBean with name "mapped - 'non-volatile memory'", which will track the above stats for all MappedByteBuffer instances currently mapped with mode ExtendedMapMode.READ_ONLY_SYNC or ExtendedMapMode.READ_WRITE_SYNC. The existing BufferPoolMXBean with name mapped will continue only to track stats for MappedByteBuffer instances currently mapped with mode MapMode.READ_ONLY, MapMode.READ_WRITE or MapMode.PRIVATE.
Proposed Internal JDK API Changes
1.        Add new method writebackMemory to class jdk.internal.misc.Unsafe
public void writebackMemory(long address, long length)
A call to this method ensures that any modifications to memory in the address range starting at address and continuing up to (but not necessarily including) address + length are guaranteed to have been written back from cache to memory. The implementation must guarantee that all stores by the current thread that i) are pending at the point of call and ii) address memory in the target range are included in the writeback (i.e., there is no need for the caller to perform any memory fence operation before the call). It must also guarantee that writeback of all addressed bytes has completed before returning (i.e., there is no need for the caller to perform any memory fence operation after the call).
The writeback memory operation will be implemented using a small number of intrinsics recognised by the JIT compiler. The goal is to implement writeback of each successive cache line in the specified address range using an intrinsic that translates to a processor cache line writeback instruction, reducing the cost of persisting data to the bare minimum. The envisaged design also employs a pre-writeback and post-writeback memory synchronizaton intrinsic. These may translate to a memory synchronization instruction or to a no-op depending upon the specific choice of instruction for the processor writeback (x64 has three possible candidates) and the ordering requirements that choice entails.
N.B. A good reason for implementing this capability in class Unsafe is that it is likely to be of more general use, say for alternative data persistence implementations employing non-volatile memory.
Alternatives
Two alternatives were tested in the original prototype.
One option was to use libpmem in driver mode, i.e., 1) install libpmem as the driver for the NVM device, 2) map the file as per any other MappedByteBuffer, and 3) rely on the force method to do the update.
The second alternative was to use libpmem (or some fragment thereof) as a JNI native library to provide the required buffer mapping and writeback behaviour.
Both options proved very unsatisfactory. The first suffered from the high cost of system calls and the overhead involved in forcing the whole mapped buffer rather than some subset of it. The second suffered from the high cost of the JNI interface. Successive iterations of the second approach (adding first registered natives and then implementing them as intrinsics) provided similar performance benefits to the current draft implementation
A third alternative that was considered is to wait for Project Panama to provide access to foreign libraries and foreign datatypes mapped over NVRAM without incurring the overheads of JNI. While this is still considered to be a worthwhile option for the future it was decided that the current proposal is worth pursuing for two reasons: firstly, to allow users to experiment with the use of NVRAM from Java immediately, as it begins to become available; and secondly, to ease the transition involved in such a transition by supporting a model for use of NVRAM derived from the existing, familiar MappedByteBuffer API.
Testing
Testing will require an x64 or AArch64 host fitted with an NVM device and running a suitably up to date Linux kernel (4.16).
Testing on AArch64 may not be possible until suitable NVM devices are available for this architecture. As an alternative testing may need to proceed by mapping volatile memory and using it to simulate the behaviour of an NVM device.
Testing on both target architectures may be difficult; in particular, it may suffer from false positives. A failure in the writeback code can only be detected if it is possible to kill a JVM with those pending changes unflushed and then to detect that omission at restart.
This situation may be difficult to arrange when employing a normal JVM exit (normal shutdown may end up causing those pending changes to be written back). Given that the JVM does not have total control over the operation of the memory system it may even prove difficult to detect a problem when an abnormal exit (say a kill -KILL termination) is performed.
Risks and Assumptions
This implementation allows for management of NVM as an off-heap resource via a ByteBuffer. A related enhancement, JDK-8153111, is looking at the use of NVM for heap data. It may also be necessary to consider use of NVM to store JVM metadata. These different modes of NVM management may turn out to be incompatible or, possibly, just inappropriate when used in in combination.
The proposed API can only deal with mapped regions up to 2GB. It may be necessary to revise the proposed implementation so that it conforms to changes proposed in JDK-8180628 to overcome this restriction.
The ByteBuffer API is mostly focused on position-relative (cursor) access which limits opportunities for concurrent updates to independent buffer regions. These require locking of the buffer during update as detailed in JDK-5029431, which also implemented a remedy. The problem is mitigated to some degree by the provision of primitive value accessors which operate at an absolute index without reference to a cursor, permitting unlocked access; also by the option to use ByteBuffer slices and MethodHandles to perform concurrent puts/gets of primitive values.


samedi 11 août 2012

Veille technologique semaine 32

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • prolongation, par Oracle, de la maintenance gratuite du JDK 6 jusqu'à février 2013 au lieu de novembre 2012.
  • Les 20 ans d'OpenGL : de 0,64 millards de floating operations par secondes à 3.090 milliards de floating point operations par seconde (4.830 times faster).
  • La société Azul qui propose sa machine virtuelle Zing, sans pause liée au grabage collecteur, avec un accès gratuit pour les produits open sources.
  • Un article de fond au sujet de la bonne séparation des responsabilités des données, des traitements vis à vis de la conception objet.
  • Un article au sujet de LINQ : le langage de requête de DotNet : bientôt en Java ?
  • Un essai des expressions lambda du JDK 8 : à vos machines.
  • Une synthèse des collection en Java : faite le bon choix.
  • Comment une variable peut ne pas être égale à elle-même ?
Bonne lecture.


Java 6 End of Public Updates extended to February 2013
Earlier this year I announced that the EOL for Oracle JDK 6 had been extended from July 2012 to November 2012. JDK 6 was the default JDK for over 5 years, and so it seems fair that it have a longer publicly available support time-frame than past major releases.
After further consultation and consideration, the Oracle JDK 6 End of Public Updates will be extended through February, 2013. This means that the last publicly available release of Oracle JDK 6 is to be released in February, 2013.


OpenGL celebrates its 20th birthday with two new versions
OpenGL is 20 years old this year. Silicon Graphics published OpenGL 1.0 in January 1992. The Silicon Graphics RealityEngine, released in 1992, was spread across three to six circuit boards. The Geometry Engine board housed eight Intel i860XP CPUs at 50MHz each. Rasterization and texture storage were performed by one, two, or four Raster Memory boards, and display output was handled by a Display Generator board.

This powerhouse could process 1 million triangles per second and render 240 million pixels per second. Its total number-crunching power was about 0.64 billion floating operations per second.

Twenty years later, an NVIDIA GeForce GTX 680 can handle 1,800 million triangles per second, 14,400 million pixels per second, and has processing power totaling 3,090 billion floating point operations per second—between 60 and 4,830 times faster than the pioneering RealityEngine.



Azul Systems offre une licence de Zing aux projets Open-Source
Azul Systems, la société qui édite la JVM Zing a fait du bruit cette semaine en annonçant la mise à disposition d'une licence gratuite de Zing pour les projets Open-Source.
Lorsque l'on souhaite avoir un temps de réactivité excellent sur une application Java, on se heurte bien souvent aux pauses du Garbage Collector qui interrompent complètement l'application, le fameux mode « Stop-the-World ». Sur une JVM standard, par exemple Hotspot, il faut alors en passer par un tuning poussé du Garbage Collector pour minimiser la fréquence ou la durée de ces pauses (choix du type de GC, ratios des différents espaces, seuils de déclenchement, …).
Ce n'est pourtant pas le chemin qu'a choisi Azul Systems. Depuis 2002, les équipes d'Azul sont allées jusqu'à créer leur propre hardware pour obtenir une JVM spécialisée dans les applications à très forte charge et ayant de gros besoins en mémoire. Le résultat ? La plateforme Vega et la JVM Zing, dont il est question ici.
Sous le capot, Zing gère la mémoire par le biais d'une table d'adressage. Chaque référence mémoire est, en réalité, une référence virtuelle qui est interceptée par Zing pour être traduite en une adresse physique. Par cette approche, la phase de compactage des garbage collectors classiques, habituellement longue, se résume à la mise à jour de l'adresse physique associée à une référence virtuelle dans la table d'adressage. Par ce biais (et bien d'autres), on en arrive à un garbage collector qui tourne en continu, et de manière complètement invisible, sans pause.
Les principaux points forts de Zing sont :

  • Un garbage collector fonctionnant sans pause (aucune collection ne se fait sur le mode « Stop-the-world »)
  • Supporte plusieurs dizaines de cores par instance
  • Supporte jusqu'à 512Go de Heap par instance
Pour en savoir plus, vous pouvez consulter cet excellent article de nos confrères d'InfoQ : The Azul Garbage Collector, ou plus simplement l'essayer vous-même sur votre/vos projets Open-Source.


Objets, données, traitements et modélisation
La réunification des données et des traitements, le tout en un. Fini les données d'un côté et les traitements de l'autre, « has been » tout ça, vive l'avènement de l'objet et de la modélisation objet. Moi, Monsieur, je pense Objet, je modélise Objet, je programme Objet.
On constate souvent ce genre de discours, et cette opposition qui est faite entre l'objet et le légendaire couple données-traitements. On fait d'ailleurs souvent ce raccourci pour définir ce qu'est un objet : « c'est comme une donnée avec les traitements en plus » Sommes nous vraiment sûrs que cette explication ou cette opposition soient justes ?
Maîtrisons-nous réellement la portée de ce raccourci : « c'est comme une donnée avec les traitements en plus » ? La fusion complète des données et des traitements est-elle réelle en objet ?


When will we have LINQ in Java?
LINQ is one of Microsoft's .NET Framework's most distinct language features. When it was first introduced to languages such as C#, it required heavy changes to the language specification. Yet, this addition was extremely powerful and probably unequalled by other languages / platforms, such as Java, Scala, etc. Granted, Scala has integrated XML in a similar fashion into its language from the beginning, but that is hardly the same accomplishment. Nowadays, Typesafe developers are developing SLICK - Scala Language Integrated Connection Kit, which has similar ambitions, although
the effort spent on it is hardly comparable: one "official" Scala developer against a big Microsoft team. Let alone the potential of getting into patent wars with Microsoft, should SLICK ever become popular.


JAVA 8: TESTING THE LAMBDA WATER
Java 8 is about a year away and comes with a language feature I really look forward to: Lambda Expression. Sadly the other big feature,
Modules for the Java Platform, has been delayed to Java 9. But nevertheless, bringing lambda expressions (or closures if you like) into the language will make programming in Java much better. So nearly one year to go – but as Java is developed open source now, we can have a look and try to use it right now. So let's go!


Which Java collection to use?
Java collections are one of the most commonly used data-structures by all Java professionals. But are you using the right collection class that would best suits your need. Most programmers usually use Vectors, ArrayList, HashMap or the Hashtable. There are many other collection classes available with the JDK that you can use instead of re-inventing logic to suite your needs. We will be trying to understand the different types of classes and when each Collection class could be used. We wouldn't be looking into the implementation details of any collection, for that please refer the latest Java Collection API docs.


[Java] Quand une variable n'est pas égale à elle-même

Est-il possible de faire en sorte que "pas égal" soit imprimé dans la console sans modifier la structure suivante ?

if (x == x) {
   System.out.println("égal");
   }
else {
   System.out.println("pas égal");
}

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!


samedi 28 juillet 2012

Veille technologique semaine 30

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • sortie de la version 7.2 de NetBeans avec des amélioration des performances, l'intégration du builder d'interface pour JavaFX et des nouvelles fonctionnalités d'analyse statique du code.
  • La participation de Twitter au développement d'OpenJDK, la version open sources de Java qui est la base du JDK 7.
  • Un article de fond au sujet de l'architecture logiciel et les frameworks : qui doit influencer l'autre ?
  • L'annonce d'Oracle de différer le projet Jigsaw de modularisation dans le JDK 9 (2015). La polémique commence.
  • La programmation concurrente avec les types atomiques du standard C++ 2011.
  • Des mesures de performances de la programmation concurrente du standard C++ 2011.
  • La sérialisation en Java avec les performances du C++ : c'est possible.
  • Un tutorial sur la généricité en Java, pour les débutants.
Bonne lecture.


NetBeans IDE 7.2: Smarter & Faster
NetBeans IDE 7.2 is alive! The NetBeans IDE 7.2 release comes with significantly improved performance and many new features in the Java Editor, with a special focus on FindBugs integration, providing new static code analysis capabilities.


NetBeans IDE 7.2 Available for Download
NetBeans IDE 7.2 provides significantly improved performance and an enhanced coding experience, with new static code analysis capabilities in the Java Editor and smarter project scanning.


The Importance of Twitter’s Participation in OpenJDK
Twitter has announced they’ve signed the Contributor Agreement for OpenJDK and plan to be active participants. Also, they announced that they’ve joined the JCP.
As an ecosystem guy, I find the fact that Twitter signaled their participation to be very important. It’s not because of their very cool and popular brand, or that they’re loaded with engineers with world class reputations, or that they’re running one of the fastest growing and massively scaled software projects on the planet (although, those all certainly are nice). From my perspective, it’s the fact they’re not an ISV*. They do not generate product revenue by selling software licenses. If OpenJDK were just and only about the Oracle/IBM/SAP’s of the world, plus individuals who sell consultancy hours, or to further academic research, based on their close participation, then I think OpenJDK would eventually suffer for it.


Debate: The Annoying Detail
Uncle Bob and Simon Brown debate on the infrastructure’s role in drawing a system’s architecture.
In an earlier post entitled Screaming Architecture, Robert Martin (a.k.a. Uncle Bob) drove home the point that the architecture of a software product should make it obvious for everyone what purposes that product is supposed to serve, adding that
the architecture of a system is supposed to reflect the use cases of that system and not the frameworks it uses.


Jigsaw a (encore) raté le train
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 laJSR 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.


Project Jigsaw: Late for the train
The aim of Pro!ject Jig!saw is to design and implement a standard module system for the Java SE Plat!form, and to apply that system to the Platform itself and to the JDK.
Jigsaw is currently slated for Java 8. The proposed development sched!ule for Java 8 expects work on major fea!tures to be finished by May 2013, in preparation for a final release around September. Steady progress is being made, but some significant technical challenges remain. There is, more importantly, not enough time left for the broad evalulation, review, and feedback which such a profound change to the Plat!form demands.
I therefore propose to defer Project Jigsaw to the next release, Java 9. In order to increase the predictability of all future Java SE releases, I further propose to aim explicitly for a regular two-year release cycle going forward.


Thoughts on the Jigsaw debacle
Disclaimer: this is a personal piece of opinion and in absolutely no way does it necessarily reflect the views of my current employer. I have spent 13 years at Sun/Oracle (5 of which in the GlassFish team which had a modularity experience of its own) and I still care very much about the future of Java. I now work at Google.


Jigsaw Deferred until Java SE 9 
Mark Reinhold, chief architect of the Java Platform Group, announced on his blog that proposal of adding a module system, and modularizing the JDK, is deferred to Java SE 9.
Despite being a difficult decision to make, doing so allows more focus to be given on the module system in order to get it right, without having to delay the release of Java SE 8, scheduled for just over a year's time in August 2013.
The decision is reminiscent of the well executed plan laid in 2010 for Plan B, which deferred the addition of Lambdas (aka JSR 335) until after JDK7 was released. This allowed JDK7 to be released around a year ago (July 2011), some four and a half years after the prior JDK6 released.


C++11 Concurrency Tutorial – Part 4: Atomic Types
In the previous article, we saw advanced techniques about mutexes. In this post, we will continue to work on mutexes with more advanced techniques. We will also study another concurrency technique of the C++11 Concurrency Library: Atomic Types


C++11 Synchronization Benchmark
In the previous parts of this serie, we saw some C++11 Synchronization techniques: locks,
lock guards and atomic references. In this small post, I will present the results of a little benchmark I did run to compare the different techniques. In this benchmark, the critical section is a single increment to an
integer. 

The critical section is protected using three techniques:
  • A single std::mutex with calls to lock() and unlock()
  • A single std::mutex locked with std::lock_guard
  • An atomic reference on the integer

Native C/C++ Like Performance For Java Object Serialisation
Do you ever wish you could turn a Java object into a stream of bytes as fast as it can be done in a native language like C++? If you use standard Java Serialization you could be disappointed with the performance. Java Serialization was designed for a very different purpose than serialising objects as quickly and compactly as possible.
Why do we need fast and compact serialisation? Many of our systems are distributed and we need to communicate by passing state between processes efficiently. This state lives inside our objects. I've profiled many systems and often a large part of the cost is the serialisation of this state to-and-from byte buffers. I've seen a significant range of protocols and mechanisms used to achieve this. At one end of the spectrum are the easy to use but inefficient protocols likes Java Serialisation, XML and JSON. At the other end of this spectrum are the binary protocols that can be very fast and efficient but they require a deeper understanding and skill.


10 points about generics in java – Tutorial Example
Generics Java Example Tutorial I have read many articles and tutorials on generics in java some of them are quite good and detailed but I still felt that those are either too much technical or exhaustively detailed, so I thought to write a simple yet informative article on generics in Java to give a head start to beginners without bothering there head too much. In this java generics tutorial I will cover How Generics works in Java, Mysterious wild-cards in Generics and some important points about generics in Java. I won't go in too much detail instead I will try explaining generics concept in simple words. 

mardi 24 juillet 2012

Veille technologique semaine 28

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • Microsoft et le multi-touch
  • La loi de Conway : l'architecture logicielle finie toujours par refléter l'organisation industrielle. C'est une pathologie.
  • Android 4.1 : à vos smartphones et tablettes.
  • Mise à jour de la spécification des expressions lambda pour Java : JSR 335
  • Un type de transistor plus rapide que ceux basés sur le silicium.
  • Sortie du COTS DataNucleus en version 3.1. COTS de persistances pour Java compatible JDO (Java Data Object) et JPA (Java Persistance API).
  • Le futur du COTS de test d'IHM : FEST.
  • C# : en manque d'idée pour la version 5 ?
  • Un exemple d'utilisation des modules du JDK 8 : définition et utilisation d'un service.
Bonne lecture.


Microsoft : l'amour du risque
Microsoft enfonce une nouvelle fois le clou : la vedette de sa Worldwide Partner
Conference (WPC) est un nouveau produit matériel. Il s'agit d'un écran multitouch de 82" qui de l'aveu de Steve Ballmer pourrait faire un tabac dans les grandes entreprises et dans le milieu de l'éducation. Une annonce qui pourrait paraître anecdotique, mais qui est en fait très révélatrice.


Architecture and Conway's Law
"…organizations which design systems … are constrained to produce
designs which are copies of the communication structures of these
organizations."
—Melvin Conway


Android 4.1: Open Sourced with UI, Connectivity, Services and Tools Improvements
The recently open sourced Android 4.1, aka Jelly Bean, comes with several UI, connectivity, services and SDK enhancements, including: smoother UI, better HTML5 rendering, cloud messaging, performance and debugging tools.


JSR 335: Lambda Expressions for the Java Programming Language
Part A: Functional Interfaces: Provides a definition of functional interfaces, which lambda expressions and method references can be used to instantiate.
Part B: Lambda Expressions: Defines the syntax of lambda expressions, including rules for the new kinds of parameter lists and statement lists.
Part C: Method and Constructor References: Defines the syntax of method and constructor references.
Part D: Poly Expressions: Describes poly expressions, which are a category of expressions that can adapt their typing to conform to a particular context.
Part E: Typing and Evaluation: Specifies the typing rules and evaluation behavior of lambda expressions, method references, and constructor references.
Part F: Type Inference: Redefines type inference to support lambda expressions, method references, and constructor references, and to allow context to be pushed down to nested poly expressions.
Part G: Default Methods: Describes the syntax and inheritance behavior of default methods, which are members of interfaces. Adapts the VM specification to support code-carrying methods in interfaces.


High-performance graphene transistors made using sticky tape
Graphene could be a useful material for high-performance transistors because it carries electrons faster than silicon.


DataNucleus
Almost a year from the release of version 3.0 and we move close to the release of version 3.1 (due late in July 2012). So what has changed in that time ?


The Future of Fest
'm very excited to be working on FEST again! It has been more than a year since my last commit and there is a lot of catch up for me to do.
I have put together a plan for the project and myself, which I'm going to share with
the rest of the team. The plan is the following:


Eric Lippert Reviews C# and Speculates on its Future
O'Reilly's Rachel Rouemeliotis recently spoke with Eric Lippert, Principal Software Design Engineer on Microsoft's C# Compiler Team. The conversation covered a number of topics and provided Lippert's brief summary of the C# world. This discussion prompted InfoQ to contact Lippert to provide greater context for his comments leading to a thoughtful analysis of the language's design philosophy.


Modular services with OpenJDK Jigsaw and Guice
This blog entry describes an experiment exploring the connection between Java modules and services in OpenJDK Jigsaw and the dependency injection framework Guice.
Modular services in Jigsaw define a very simple way to bind a (service) interface to implementations (service provider classes) and, using java.util.ServiceLoader, a way to iterate through all (service) instances of implementations bound to an interface.

samedi 7 juillet 2012

Veille technologique semaine 27

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • Le fondateur du framework Spring quitte la société qu'il a créée et part vers de nouvelle aventure.
  • Arret du minitel : imaginer FaceBook sur le minitel.
  • Sortie de la version 2 du langage Groovy : typage statique, compilation statique, modularité et performances.
  • Les développeurs seniors : la pénurie dans les équipes. A qui la faute ?
  • Une comparaison détaillées des expressions lambda du JDK 8 et Scala.
  • Un résumé de la spécification Java Enterprise Edition 7 : prévue pour début 2013. Le cloud, le cloud et le cloud.
  • L'état du langage Java d'après Oracle.
  • Le langage Xtend propose d'étendre le langage Java.
  • JavaFX : les ombrages dynamiques. Exemple de code

Bonne lecture.


Spring Founder Moves On To New Adventures
Yesterday, Rod Johnson, the founder of Spring, announced that he is to leave
VMWare to pursue some new interests. In 2001, Rod changed the way we look at enterprise software when he published Expert One-on-One J2EE Design and Development.
And he followed through with those ideas in 2002 when he founded Spring,
bringing a credible alternative to the enterpise solutions available at the time.



Minitel, France's precursor to the Web, to go dark on June 30
Minitels like this one are set to go dark at the end of this week.

Facebook as re-imagined on Minitel :


Groovy 2.0 est là !
La nouvelle mouture du langage Groovy‬, la 2.0, est enfin livrée dans sa version définitive au public (comme par hasard, le jour de l'anniversaire de son project leader : Guillaume Laforge). Les améliorations les plus importantes sont :
  • le static type checking : apparition d'une annotation @TypeChecked pour avoir des erreurs de compilation (plutôt que de runtime) sur des choses comme des variables ou méthodes inexistantes, des assignements de types incorrect, etc.
  • la compilation statique : nouvelle annotation @CompileStatic pour obtenir de la compilation static et ainsi avoir un bytecode identique à celui produit par un javac sur un code Java, et aussi rapide à exécuter.
  • la modularisation : pour ne charger que ce dont vous avez besoin, le coeur de Groovy est deux fois plus léger, et 15 modules l'accompagnent : Console, JMX, Ant, Swing, etc.
  • de meilleures performances : notamment grâce au support de invokeDynamic pour les utilisateurs du JDK7, et beaucoup de travail a été fourni pour que les utilisateurs du JDK6 aussi y trouvent leur compte.
Pour plus de détails :
S'il en était encore besoin, la preuve de la vivacité de l'écosystème Groovy a été apportée ce mois-ci (mois de la GR8Conf) : les projets Groovy‬, Gaelyk, Griffon et Gradle‬ ont chacun livré une version majeure.
Pour les pratiquants, la mise à jour s'imposera d'elle même. Pour ceux qui n'ont pas encore testé,vraiment vous devriez!


What's new in Groovy 2.0? 
The newly released Groovy 2.0 brings key static features to the language with static type checking and static compilation, adopts JDK 7 related improvements with Project Coin syntax enhancements and the support of the new "invoke dynamic" JVM instruction, and becomes more modular than before. In
this article, we're going to look into those new features in more detail.


Pénurie de seniors dans les équipes de développement
Maître Yoda dans ton équipe, plus forte elle sera Après plusieurs années passées à développer, concevoir et architecturer des applications, les développeurs les plus expérimentés, dits seniors, sont souvent propulsés à des postes décisionnels et/ou organisationnels.
En France, ce phénomène est tel que l'écosystème des développeurs informatique manque cruellement de ces profils. Bien que les mentalités commencent à évoluer, la réalité sur les projets est toute autre. Les applications sont mises entre les mains de profils juniors ou confirmés possédant moins d'expérience que leurs aînés, notamment dans la gestion de la dette technique. Dans ce domaine, les seniors possèdent plus de recul, de savoir faire et il est nécessaire que ces derniers continuent d'accompagner les équipes de développement. Nous vous proposons d'analyser ce phénomène.
Juniors, Confirmés, Seniors, …


Java 8 vs Scala: a Feature Comparison
With the release of JDK 8 planned for 2013, Oracle has a pretty fixed idea of what will be included.
Speaking at QCon London earlier this year, Simon Ritter outlined the new features that will be part of JDK 8, which include modularity (Project Jigsaw), JRockit/Hotspot convergence, annotations on types, and Project Lambda.


The Java EE 7 Feature List: Cloud Focused Upgrades
When it arrives later this year, Java EE 7 will offer key new features related to cloud computing.
by Manoj Debnath Java EE 7, under the specification of JSR342, is expected to be released in mid-late 2012. Anticipation of the update's platform as a service (PaaS) capabilities is looming large among technological enthusiasts. With a promise of numerous key improvements, the focus will be on the suitability of Java EE for cloud environments. This article spotlights key things to look for in Java EE 7.
Spotlights in Java EE 7


Status of Java


Xtend Extends Java
Together with the release of Eclipse Juno, the Eclipse Foundation is proud to announce the release of Xtend,
a Java-compatible language with lambdas and yet full compatibility with the Java runtime. Xtend is built
upon Xtext, a suite of DSL libraries and plugins for generating editors.
Unlike Scala, Ceylon or Kotlin, Xtend doesn't need its own separate bytecode compiler. Instead, Xtend source
files are translated into Java source files, which are then compiled with the regular Java compiler. As a result,
Xtend can be used as a development time translation tool that generates Java for use in a standard Java
project, or it can be used as source models that are used to generate Java source files at compilation time.


JavaFX recipes "Dynamic shadows"
This is the first blogpost of a series about JavaFX related tips and tricks that I came across.
Today I would like to explain how to add a dynamic shadow to a node. So first of all let me tell you what I mean with dynamic shadow. If you take a dial with some kind of pointer it will definitely look better when the pointer has a drop shadow. As an example let me show you two radial gauges.