Veille technologique semaine 46

Pour le bulletin de cette semaine, je vous propose les sujets suivants :

• le JDK 5 a atteind la fin de son cycle de vie le 3 novembre dernier. Il n'y a donc plus de mise à jour publique du JDK 5 qui reste à l'update 22. La maintenance est passé en mode payant : de 15K$ à 250k$ par ans. La fin de vie du JDK 6 est prévue pour 2010.
• le produit de gestion de configuration subversion passe en projet apache.
• Oracle confirme le soutien des produits SUN : sparc, solaris, glassfish, openoffice, mysql, netbeans ...
• un mouvement anti SQL : noSQL.
• sortie de JavaFX 1.2.1 : perf et correction de bugs.
• Java et le multi-core :
• Groovy et la délégation : @Delegate
• JBossCache et le MVCC : Multi Version Concurent Controle.
• JUnit et l'annotation @Rule
• un article au sujet des performances de Java versus C/C++.

Bonne lecture.

Java SE 5 Reaches End Of Service Life
Sun's implementation of J2SE 5.0 reached its End of Service Life (EOSL) on November the 3rd 2009, which is the date of the final publicly available update of version 5.0 (J2SE 5.0 Update 22).

Customers looking for support from Sun can either update to Java 6 or subscribe to Sun's Java for business program.
Sun offers a number of paid support options for Java. Java classic support covers the latest release of Java for a period of three years from product release and comes in two variations: Standard support which provides business-hour (12x5) coverage with a four hour response time SLA, and premium support which offers 24x7 support with an immediate response time. The cost of Java classic support starts at $15,000 per year. Pricing increases by the size of the organisation and for very large enterprises could be up to around $250,000 per year.



Java SE & Java SE for Business Support Road Map
JDK 6 : GA Date = 6 December 2006, EOL Notification = 2009*, EOSL = 2010*, Support Period = 4 years*

* EOL Notification date, EOSL date, and exact support period for the Java SE 6 release family have not been determined at the time of the writing of this article. Information will be posted to the Java SE web site as it becomes available.


Subversion, le nouveau projet de la Fondation Apache

C'est officiel, Subversion fait maintenant partie des projets de la fondation Apache. Avant de pouvoir devenir projet top-level, Subversion doit d'abord passer par l'incubateur. Durant cette période, CollabNet continuera d'héberger le projet surhttp://subversion.tigris.org. De plus, les différents binaires continueront d'être publiés sur ce site au-delà de la période d'incubation. Nous sommes donc en droit de nous demander ce que cette nouvelle va finalement changer ?

Certains imaginent la refonte de Subversion pour lui ajouter des fonctionnalités de gestionnaire de sources distribué, comme GITou Mercurial. Il est pourtant difficile de croire à une telle transformation, Subversion étant connu comme le gestionnaire centralisé star du moment. Un tel virement de bord signifierait la fin de ce modèle centralisé.

D'autres perçoivent au contraire cette nouvelle comme une fierté personnelle et voient l'arrivée de Subversion dans l'ASF comme un aboutissement. Le projet est assez mature pour rentrer dans une nouvelle phase et Apache est la maison idéale pour le faire vivre sur le long terme tout en pérennisant la communauté.

Au final, la véritable réponse à cette question se situe probablement entre ces deux visions. Pourquoi le projet ne continuerait pas tout simplement à avancer sur le chemin qu'il suit depuis sa création ? Il lui reste du trajet à parcourir : performances, intégration avec les IDEs, outillage …

Oracle Announced Plans for the Future of Sun's Products, but Raised Concerns about NetBeans
Oracle has released an FAQ that describes its plans for the future of popular Sun technologies like GlassFish, NetBeans, MySQL and more. In some cases Oracle's announcement is unclear and raises concerns about product viability.
The announcement makes clear that the Oracle will continue to invest in Sun hardware, in Solaris, SPARC, GlassFish and OpenOffice.


Le mouvement NoSQL divise et intrigue

Le nom NoSQLest apparu courant 2009 pour qualifier un mouvement initié depuis longtemps mais qui a pris une importance et une visibilité particulière ces derniers mois. Il regroupe l'ensemble des projets proposant une solution de persistance de données non relationnelle qui se caractérisent par un design favorisant la scalabilité et la flexibilité. On reconnaît dans ces deux caractéristiques les besoins du Web, dont les grands acteurs que sont Google, Amazon et Facebook ont joué un rôle important en apportant leur propre solution (respectivement BigTable, SimpleDB et Cassandra).

Remettre en question le stockage relationnel exclusif qui s'était imposé presque comme une évidence dans le monde de l'entreprise ne pouvait se faire sans initier de nombreux débats. La dernière intervention en date est celle de Michael Stonebraker qui critique vivement cette initiative en avançant :

• Le choix du NoSQL comme solution de persistance est en général amené par un besoin de performance et de flexibilité. Ces deux caractéristiques peuvent être assurée par les RDBMS traditionnelle par la mise en place de bonnes pratiques épaulées d'un éventuel sharding
• Les systèmes NoSQL souffrent eux aussi de certaines des problématiques des RDBMS et ne sont donc pas une solution parfaite
• L'utilisation de procédures stockées permet d'obtenir la performance voulue dans de nombreuse situations

Ces arguments, assez classiques à l'encontre du NoSQL, sont opposés à ceux mis en avant par Debasish Ghosh, l'auteur du prochain DSLs in action à paraître chez Manning :

• Le sharding, solution souvent mise en avant pour sauver la scalabilité des RDBMS, est une solution très lourde à mettre en place, qui évolue mal et qui est très intrusive dans la logique métier ; elle est appliquée à des systèmes qui n'ont pas été prévus pour une telle utilisation
• Le théorème CAP montre que seule une approche différente des RDBMS classiques permet d'obtenir les performances voulues
• Une coopération intéressante se met en place entre les projets NoSQL afin de permettre des interopérabilités (tel queNeo4j s'appuyant sur Cassandra ou Riak sur CouchDB)

La remise en question apportée par le NoSQL est forcément bénéfique et ne peut amener qu'une innovation. Si le mouvement est encore récent et qu'il doit gagner en maturité, il amènera probablement à se poser plus naturellement la question de la ou des meilleure(s) solution(s) de persistance pour les données d'une application ou d'un système d'information.


JavaFX 1.2.1 is out, fixes binding leaks and performance
Sun just released the first maintenance update for JavaFX 1.2. This release brings mostly a batch of important javafxc fixes, that I dissect in this blog...


Creating Highly-Scalable Components in Java
With multi-core processors becoming main-stream, there is significant pressure on application developers to write correct highlyscalable applications to take advantage of the underlying hardware. Further, legacy applications have to be ported to run on the new architectures.
An efficient way to ensure scalability of applications is to use highly-scalable components to build the applications. For example, in various applications, java.util.concurrent.ConcurrentHashMap can replace a synchronized HashTable and make the application more scalable. Thus, providing a set of highly scalable building blocks that can be directly introduced into applications to introduce parallelism will be very useful.


Practically Groovy: The @Delegate annotation
Exploring the frontiers of duck typing in a statically typed language.
@Delegate is a compile-time annotation that instructs the compiler to push all of the delegate's methods and interfaces up to the outer class.


A Look Inside JBoss Cache
This follow-up article focuses entirely on the brand-spanking-new JBoss Cache 3.0.0 - codenamed Naga, and goes in depth to discuss how our high-performance concurrency model works.

MVCC has landed
Multi-versioned concurrency control - MVCC - was adopted as the default concurrency scheme in the cache. When run in local mode, the most costly part of the cache in terms of memory and CPU cycles is the locking involved in maintaining integrity of shared data. In a clustered mode, this locking is the second most expensive thing, after RPC calls made by the cache instance to remote instances.

Legacy locking schemes
In JBoss Cache 1.x and 2.x, we offered two different locking schemes - an optimistic one and a pessimistic one. Each had their pros and cons, but in the end they were both still costly in terms of performance.
The pessimistic scheme used a lock per tree node. Reader threads would obtain nonexclusive read locks and writer threads would obtain exclusive write locks on these nodes before performing any operations. The locks we used were a custom extension of JDK ReentrantReadWriteLocks, modified to support lock upgrading where within the scope of a transaction, a thread may start off reading a node and then later attempt to write to it.

So how does MVCC help?
MVCC offers non-blocking readers where readers do not block writer threads, providing a high degree of concurrency as well as removing the risk of deadlock. It also is fail-fast, in that writers work sequentially and don't overlap, and if they do time out in acquiring a write lock, it happens very early on in the transaction, when a write occurs rather than when a transaction commits. Finally, MVCC is also memory efficient in that it only maintains 1 copy of state for all readers, and 1 version being modified for the single, sequential writer. Even better, our implementation of MVCC uses no locks at all for reader threads (very significant for a readheavy
system like a cache), and a custom exclusive lock implementation for writers. This
custom lock is completely free of synchronized blocks and uses modern techniques like compare-and-swap and memory fencing using volatile variables to achieve synchronization. All this leads to a very highly performant and scalable locking scheme.


Writing Your Own JUnit Extensions Using @Rule
In the new release (4.7) you have access to a lot of interesting stuff (still in development for some). One that is really interesting is @Rule [1]. This annotation allows you to annotate a public field in your test class, which is of type MethodRule [2]. This binding will intercept test method calls like an AOP framework would do
and redefine the execution, skip it, or do anything else.


Java vs C performance... again...
I just foolishly got caught in a You-Tube discussion on Java vs C performance. Foolish because You-Tube comments are a lousy way to present anything and because it's hard to keep the level of discourse scholarly.
And foolish especially for me because I've had this discussion so many times and it always comes out the same way... so here's my attempt at distilling my arguments into something I can point people the *next* time I get caught in this silly discussion.

Is Java faster than C/C++? The short answer is: it depends.



Ubuntu : Intel® Q6600 quad-core Computer Language Benchmarks Game (Read the FAQ!)
You choose the language implementations for robust Box and Whiskers statistics of program time measurements on the default benchmarks!