le premier projet d'envergure en Java a été réalisé à une époque quelque peu pionnière, il y a prés 11 ans. Dés lors cette plate-forme a été au centre d'un grand nombre de missions de conception et de mise en œuvre d'architectures JAVA/J2EE complexes auprès de très grands comptes (EDF, SNCF, RATP, HEC, AGF, etc.).

L'objectif de ce tutoriel est de regrouper mes meilleurs pratiques d'installation d'un environnement de développement dédié Java sous Linux. Et ce en tentant d'être le plus large spectre possible, de l'utilisation « simple » d'Eclipse à la mise en place d'une plate-forme dédiée à un client, en passant par la création, maintenant possible avec un Java GPL, d'application Linux qui se lancent sans tracas.

Lorsqu’il s’agit dénicher les fuites de performances, le développeur java prend rapidement peur devant la perspective de journées entières passées à attendre devant un Profiler surpuissant qui va mouliner à deux à l’heure. Et lorsque les hypothétiques résultats tombent, c’est généralement la panique devant l'avalanche de listes et de chiffres.

Fort heureusement, il existe une alternative à ses outils d’étude de code, puissants mais lourds : l'instrumentation dynamique.

Eclipse, comme pas mal d'application de nos jours, est basé sur un système de plugins permettant d'en étendre le fonctionnement. Or l'installation de ces greffons a longtemps été une vraie misère sur cette plate-forme qui tend aujourd'hui cependant à s'améliorer avec le système intégré de mise à jour.

Si la version 1.5 de java a apporté un lot inhabituel de nouveautés, c'est principalement les annotations et les types génériques qui ont été le plus appréciés. Le but de cet article n'est pas d'être le nième tutorial sur le sujet, google en regorge. Il s'agit plus d'une approche plus pointue de ce qu'il est possible de faire avec cette nouvelle syntaxe et d'en connaître les limites.

Mon besoin de base était de pouvoir utiliser l'API Java TuxDroid à partir de n'importe quelle application Linux. Par exemple dans le système de notification de KDE. Et en creusant un peu, les possibilités ne manquent pas. Il y a tout d'abord la très supportée mais aussi relativement lourde solution Corba utilisée par les applications Gnome. Nous avons aussi le très bon DCOP issue du monde KDE mais le portage Java semble quelque peu poussiéreux. Reste la relativement récente solution DBUS proposée par freedesktop.org et disposant d'un très bon "binding" java. Et force est d'avouer que cela fonctionne très bien.

Même si les threads font parti depuis un temps certain déjà du paysage, ils n'en restent pas moins méconnus de la grande majorité des dévelopeurs avec qui j'ai eu à travailler. Et pourtant, même sans parler de multi-core, le threading est une technique qui rend de très nombreux service, lorsqu'elle n'est pas simplement indispensable. Et lorsque l'on voit la simplicité avec laquelle elle peut être mise en oeuvre en Java, il est vraiment dommage de s'en priver.

Le manque de performance est le reproche régulièrement fait à la plate-forme Java. C'est l'inconvénient de l'âge et des précurseurs. Car s'il est vrai que les premières tentatives, datant de plus de dix ans (1995), ont été difficiles, les machines Java modernes n'ont elles plus à rougir face des applications natives, ni même, malgré l'emphase marketing de certains, face à une application .Net... Et tout cela a été rendu possible par la maturation de trois approches conjointes : La compilation temps-réel (JIT), l'optimisation des librairies et enfin, les JNI. Et c'est ce dernier point que nous allons apprendre à connaître...