23 novembre 2009

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
16 novembre 2009

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
SOA
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
12 octobre 2009

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Lire la suite de cet article »
14 septembre 2009

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
31 août 2009

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Architecture
Actualité éditeurs / SSII
RIA
Le coin de la technique
Lire la suite de cet article »
24 juin 2009
Cette deuxième journée de Jazoon a commencé par une keynote de Danny Coward, qui a établi deux tops 5 distincts, à savoir le top 5 de ce qui va arriver dans le JDK 7, et celui de ce qui existe déjà dans JavaFX 1.2 (on peut noter cette amusante différence d’échelle).
Laissons de coté le top 5 JavaFX (nous y reviendrons dans un autre billet), pour nous concentrer sur les 5 nouveautés du JDK 7, « les plus excitantes » pour un Sun Fellow.
Lire la suite de cet article »
15 décembre 2008

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Lire la suite de cet article »
12 mars 2008
L’analyse empirique montre que dans une application la très grande majorité des objets créés sont détruits presque immédiatement. C’est d’autant plus vrai pour les applications web et/ou stateless où la plupart des objets sont créés pour traiter une requête et peuvent être donc détruits juste après ce traitement. De ce constat résulte l’idée de ne pas traiter de la même façon les objets fraîchement créés et ceux qui existent depuis plus longtemps. Les Garbage Collector qui utilisent des implémentations basées sur ce principe sont appelés GC générationnels. On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit. Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa), ils dépendent souvent du type d’applications : dans une application interactive, nous privilégierons les pauses, et au contraire, dans un batch, seul le débit compte.
La suite du billet est décomposée en deux parties :
- La première décrit le fonctionnement des algorithmes générationnels traditionnels (Implémentation actuelle des JVM Sun)
- La seconde détaille le nouvel algorithme que Sun essaye de pousser pour sa future JVM
Lire la suite de cet article »
27 février 2008
Lors de la revue de presse du début décembre, nous annoncions le passage en public draft de la JSR-294 (Improved Modularity Support). Cette JSR fait partie de la liste des évolutions potentielles proposées comme amélioration pour le JDK 7. Ce billet fait le point sur ce qu’elle propose.
Si vous développez en Java depuis plusieurs années, et avez eu l’occasion de travailler sur des bibliothèques réutilisables, vous avez peut-être été confronté au problème suivant : la publication sélective de classes ou de composants. En clair, vous auriez aimé, dans certaines situations, exposer certaines classes d’un package à celles d’un autre package – typiquement dans une relation de type fabriquant-fabriqué que l’on retrouve dans le pattern ‘Factory’. Or Java ne vous propose que 2 options pour exposer une classe : elle peut être publique – donc visible depuis n’importe quel autre package – ou « package private » – c’est-à-dire visible uniquement depuis les classes appartenant au même package. Pour contourner cette gêne, les concepteurs d’API recourent généralement à des stratégies de contournement :
- Soit ils rendent certaines implémentations internes « publiques », en précisant dans la documentation que leur utilisation n’est pas garantie, et en indiquant les moyens « légaux » de les instancier et de les manipuler. C’est la philosophie adoptée notamment par les auteurs du framework Eclipse.
- Soit ils simplifient la structure des packages pour regrouper les classes en question. Cette stratégie est plus simple et fiable, mais ne fonctionne pas vraiment avec les API de type SPI (Service Provider Interface), qui ont vocation à être étendues par des tiers.
Lire la suite de cet article »
20 février 2008
Xebia a récemment ouvert ses journées de partage de la connaissance au public (XKE). Ce billet présente l’un des sujets abordés lors de la session de février : les nouveautés du jdk7.
À l’heure où ces mots sont écrits, il n’existe pas de JSR officielle regroupant les futures fonctionnalités de Java SE 7.0. Il semblerait que Danny Coward y travaille. Il est Chief Architect chez Sun et représentant Sun du Executive Commitee pour le Java Community Process. La JSR officielle devrait voir le jour dans les prochains mois, peut-être avant la prochaine édition de Java One qui aura lieu en mai 2008 à San Francisco. Aucun des points abordés dans cette présentation n’est donc officiel, il ne s’agit que d’une tendance générale.
Puisque la communauté Java aime les animaux, étudions rapidement l’évolution des noms de codes des différents JDK. Le JDK 5 était représenté par un mammifère carnivore (Tiger) qui annonçait la force et le caractère des nouveautés de celui-ci. La puissance et la rapidité du JDK 6 étaient représentées par un cheval du Nord-Ouest américain (Mustang). Les nouveautés du JDK 7 sont elles représentées par un animal beaucoup plus calme : l’esprit de la mer (Dolphin). Comme les noms de codes s’assagissent à chaque version, et vu que celui du JDK 8 n’est pas encore connu, nous proposons de l’appeler ‘Kitty’, ‘Butterfly’ ou ‘Bunny’.
Plaisanteries mises à part, la présentation ci-dessous est découpée en 4 parties principales, elle aborde les points suivants :
- Nouveautés du langage : les sucs syntaxiques et autres modifications du langage
- Modularité : Superpackage (JSR 294) et Java Module System (JSR 277)
- Nouvelles API : Nio 2 (JSR 203), Unit and Quantities (JSR 275), Date and Time (JSR 310), Concurrency Utilities Updates (JSR 166y), XQuery (JSR 225), …
- Nouveautés JVM : Tiered Compilation, new Script engines, G1 garbage collector, …