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. 

2 commentaires:

Anonyme a dit…

I couldn't refrain from commenting. Well written!

My web-site; voyance par telephone

Anonyme a dit…

Very good post! We will be linking to this great content on our site.

Keep up the great writing.

Feel free to visit my weblog: voyance par telephone