I. Introduction▲
L'année 2006 a été cruciale dans l'histoire de Java puisqu'elle a vu l'ouverture, par Sun, du code Java et son passage sous la licence GPL. Cela a donné naissance à l'OpenJDK un an après.
À vrai dire, OpenJDK n'était pas ouvert à 100 %, car près de 5 % du code était encore fermé et demeurait la propriété de Sun. Cette situation a poussé Redhat à lancer en juin 2007 le projet IcedTea.
L'objectif d'IcedTea est de créer une implémentation 100 % open source de Java SE.
II. Cycle de mise à jour▲
Avec la version 6 de Java, les mises à jour de Sun/Oracle JDK ne correspondaient pas à celles de l'OpenJDK, c'est-à-dire que pour chacune des versions 6uN d'Oracle n'existait pas forcément une version N correspondante pour OpenJDK.
Des améliorations à ce manquement vont être apportées à partir de la version 7, et OpenJDK deviendra par la même occasion l'implémentation de référence de Java SE 7 (JSR 336) !
OpenJDK est maintenant le RI pour Oracle. Ce choix a permis de pallier les incohérences qui existaient entre les spécifications du standard et son implémentation parce qu'avant cela, plusieurs plugins contenaient des fonctionnalités qui n'étaient pas spécifiées dans le standard favorisant ainsi la création d'écart entre la spécification et les implémentations.
Pour qu'une implémentation soit certifiée, elle doit passer le « Test Compatibility Suite » (TCK) mis en place par Oracle et doit être comparée à OpenJDK comme étant l'implémentation de référence du standard.
III. Licence : BCL vs GPL v2▲
Le code source OpenJDk est disponible sous deux licences différentes :
- La Licence publique générale GNU (utilisée par le système d'exploitation GNU/Linux) ;
- Sun's Java Research License : licence non commerciale utilisée dans le cadre des travaux académiques.
Le JDK d'Oracle quant à lui est disponible sous la licence BCL (Binary Code License) qui autorise l'utilisation du code compilé Java sans ses sources : http://www.oracle.com/technetwork/java/javase/terms/license/index.html
IV. Performances▲
Afin de comparer les performances des deux implémentations, des tests officiels ont été réalisés et les résultats publiés sur http://www.spec.org/jvm2008/.
La machine utilisée pendant les tests présente les caractéristiques suivantes :
- Phenom II 940 CPU (4 cores @ 3.0 GHz, 1.8 GHz Northbridge and L3 cache) ;
- 8 GB of DDR2-800 DRAM (operating in unganged mode) ;
- Asus M4A78 Pro motherboard (AMD 780 G + SB700 chipset) ;
- four 500 GB disk in AHCI mode + software RAID 10 (near) configuration ;
- S.O. Linux RedHat 6.3x64.
Les caractéristiques des JVM utilisés pendant ce benchmarck sont :
- OpenJDK Runtime Environment (RE) 1.6.0.24 ;
- OracleJRE 1.6.0.37 ;
- OpenJDK RE 1.7.0.9 ;
- OracleJRE 1.7.0.9.
Ce benchmark a donné les résultats suivants :
- la version 1.7 d'Oracle est la plus rapide ;
- la version 1.7 d'OpenJDK et la version 1.6 d'Oracle ont des performances équivalentes ;
- la différence en termes de performances entre les différentes versions est vraiment minime.
Passons maintenant au benchmark par catégorie :
- on remarque qu'Oracle JRE 1.7 est toujours en tête dans pratiquement tous les tests ;
- OpenJdk 1.7 et Oracle JRE 1.6 sont quasiment comparables en termes de performances ;
- OpenJdk 1.6 est plus lent pour les tests sur les traitements coûteux (sérialisation, marshalling/unmarshalling xml…) ;
- dans les tests de démarrage (startup), les différentes versions d'OpenJDK sont en tête ;
- les nouvelles versions sont plus rapides dans les benchmarks de compilation.
V. Conclusion▲
Cette comparaison nous montre qu'à partir de la version 7 de Java, les différences qui existaient auparavant du point de vue de la fréquence de mise à jour ainsi que des performances ont disparu. OpenJDk est maintenant une version de référence qui couvre toutes les spécifications du JCP, ce qui constitue une bonne nouvelle pour le monde open source qui a tant inspiré Java.
VI. Remerciements▲
Cet article a été publié avec l'aimable autorisation de la société Arolla et l'article d'origine (OpenJDK) peut être vu sur le blog/site de Arolla.
Nous tenons à remercier milkoseck pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.