Veille technologique semaine 16

Je vous propose, pour cette semaine, la petite sélection suivante :

• Java Temps Réel a été retenu pour le réalisation du logiciel pour un radar de surveillance,
• Microsoft travaille sur un container à injection de dépendance pour compléter le framework DotNet,
• Java a perdu la bataille du Web : les raisons et cela peut-il changer, rattrapé ?
• Le JDK 6 propose une petite classe java.util.ServiceLoader qui n'a l'air de rien mais qui peut être très utile pour faire de l'intégration de services via le JDK : à suivre.
• La liste de l'update 10 du JDK 6 : c'est une mise à jour du JDK 6 assez importante : l'implémentation du pipe Java2D sur Direct X pour windows est enfin terminé, le JRE est fractionné en plusieurs parties (Java Kernel), look and feel Nimbus, ...
• La suite de la semaine dernière sur les API du compilateur Java
• L'annonce de SUN sur le début de la fin du JDK 5. Le JDK 5 entre dans sa période de fin de vie (End Of Life) à partir du 8 avril 2008 jusqu'au 8 octobre 2009. Pour bénéficier des corrections critiques, SUN propose de migrer sur le dernier JDK gratuitement, ou de passer un mode de maintenance du JDK 5 financé.

Bonne lecture.

Sun Java Real-Time System Selected for Space Surveillance Radar
The Java Real-Time specification has been chosen to be launched into space to provide a reliable platform for the Eglin Space Surveillance Radar as part of it's upgrade from legacy components.

http://www.globalsecurity.org/space/systems/an-fps-85.htm

Java Real-Time, a high-level development platform for creating applications that require unprecedented execution predictability, will be running on Solaris 10 enabling the radar to move from legacy, one of a kind software to a more standard platform.

"Our comprehensive tests have proven that Sun Java RTS running on Solaris 10 OS meets the real time behavior and throughput requirements for Eglin Space Surveillance Radar," said Matt Prechtel, ITT's Software Lead for the project. "We are looking forward to moving to a software platform based on the Real-Time Specification for Java and are actively evaluating Java RTS for other projects."

Compliance with this open standard enables us to use off-the-shelf hardware and operating systems plus offering us a lot more flexibility in terms of solution design." I find it very interesting that Java has been chosen for this project. The selection of the Java RTS for this job is big news - as a specification it never really seemed to get off it's feet. I wonder why Scala wasn't chosen, as it boosts an impressive, easy to use concurrency API.

If you were developing a time critical application, what would you choose? Is that Java RTS enough for a full modernization of such a sytem, or should they go a step further?

Microsoft Unity Dependency Injection Application Block Released

The Microsoft patterns & practices group has released its Dependency Injection container called Unity or the Unity Application Block. Developers can now create loosely coupled applications that are extensible using this lightweight container. InfoQ had the opportunity to talk with Chris Tavares, the lead developer of the Unity project.

Unity is a Dependency Injection (DI) container. The standard article describing DI is from Martin Fowler[0]. As a quick summary, a DI container is a tool you can use to support building highly decoupled software. The DI container takes care of the details of which objects are interconnected, so you can build each one independently. This has a big impact for both testability and flexibility of the resulting code.

"Java is losing the battle for the modern web"...
Simon MacDonald pointed out a blog post from Andi Gutman, with the title "Java is losing the battle for the modern Web. Can the JVM save the vendors?" It's an interesting and challenging post from one of the founders of Zend Technologies. Why is this post relevant? Well, for one thing, as one of the authors of PHP, Andi can be described as being someone with influence – look at how many MySQL errors people can describe with Andi's work product. More seriously, Andi makes a lot of points about dynamic languages on the JVM, now getting a lot of traction from nearly all quarters.

Java is losing the battle for the modern Web. Can the JVM save the vendors?
A few years ago I worked on a very big Enterprise IBM Websphere project. We had some brilliant engineers in the project both in the development and architecture groups. I remember having had several discussions with some of the brightest people on the team regarding PHP and dynamic languages and generally they were looked upon as toy languages without a bright future. Lack of strict typing, scripting performance, and other reasons were given for why Java would persevere as the language of choice.

The service Provider Interface

I was looking for a simple, low-overhead way to do plug-ins and the service provider mechanism in the jar file specification seems to fit the bill, is dead-simple (once you grok the doc), and requires almost no coding on my part: Java automatically finds the plug-ins at startup and they can be retrieved by a call to the static ServiceRegistry.lookupProviders() method. I can't help but wonder if something's wrong with this since I haven't ever run across it before, (though, I must admit, it hadn't ever occurred to me to read the Jar file spec), and googling for service discovery strategies brought up little useful information about it.

Class java.util.ServiceLoader
A simple service-provider loading facility.

Introducing Java 6 update 10
Don't be fooled by its unassuming name: the upcoming Java 6 update 10 is a very different animal than the updates that preceded it. Java 6u10 pushes the envelope by adding more new features and functionality than in any previous Java programming language update release, including many that have been a long time coming.

Officially, a "Java update release" is a release in which only the fourth version number (the 10 in 1.6.0_10) changes. Unlike major releases, update releases are not allowed to add, remove, or change any public APIs, and generally this has limited update releases to only containing bug fixes. 6u10 likewise contains no new or changed public APIs -- but despite that restriction, we still managed to squeeze in some incredible new features.

Why A Special Update Release?

• Java Kernel
• Next-Generation Java Plug-In
• Java Deployment Toolkit
• Nimbus Look and Feel
• Performance
• Deployment Usability
• But Wait, There's More!

The Java Compiler API
Summary
Most developers think of the Java compiler, javac, as an unobtrusive command-line tool to invoke when you want to turn Java source code into class files. The Java Compiler API, JSR 199, released in final form last December, opens up the Java compiler to programmatic interaction as well. Artima spoke with JSR 199 spec lead and Sun engineer Peter von der Ahé about what programmatic compiler access means for developers.

Java SE 5.0 is in its Java Technology End of Life (EOL) transition period.
The EOL transition period began April 8th, 2007 and will complete October 8th, 2009, when Java SE 5.0 will have reached its End of Service Life (EOSL).

Customers interested in continuing to receive critical fixes, are encouraged to consider the following options:

• Migrate to the latest Java SE release
• Migrate to Java SE for Business 5.0

Veille technologique semaine 15

Je vous propose, pour cette semaine, des articles orientés interface homme machine et infrastructure JVM :

• La technologie JavaFX
• Le JSlider pas à pas
• L'afficheur de thread porté dans l'outil visualVM
• Le profiler qui permet de naviguer (walk) dans le tas des objets Java
• Les compléments du JDK 6 update 10 (disponible uniquement en bêta)
• Les API du JDK 6 pour faire de l'analyse de source Java avant la compilation javac
• L'outil de visualisation du code natif généré pas le compilateur Just In Time de la JVM : uniquement pour ceux qui lisent l'assembleur x86 des processeurs Intel.

Bonne lecture.

Using UI Components in Compiled JavaFX Script Technology
The previous article of this series, Creating Rich Internet Applications With Compiled JavaFX Script Technology, covered how to develop, compile, and run a simple JavaFX Script technology-based program. The article examined the program in detail and discussed several JavaFX Script concepts.

JSlider Appearance Improvements
The JSlider component is a popular component for selecting a value from a numerical range. While some people might think of a JScrollBar for numerical input, that really serves the purpose of scrolling around a viewport, not data input. By default, the input range of a JSlider is 0 to 100, with an initial value of 50. You can change any of the three defaults, the direction of the scrollbar, and whether tick marks should appear and what to show next to them. You'll look at all of these possible features.

Porting a Hot Java Thread Detector to VisualVM
Over on java.net, Bruce Chapman recently described a tool he's created "to output the stack traces for the three busiest threads in a Java process". He closes the article by suggesting that his hot thread detector might be useful in jConsole and VisualVM. Fortunately, he provided all his source code...

Walking the Java Heap with NetBeans 6.0 Profiler
NetBeans 6.0 brings a host of new features to Java and Ruby developers, including a totally rewritten editor, support for local file history, a new graphical file comparison utility, and support for the new Swing desktop framework. One area of particular emphasis is its profiler, which has improves support for detecting and fixing memory leaks, the focus of this article.

Java SE 6 Update 10 Overview
Overview
Java SE 6 Update 10 is an update release that introduces
new features and enhancements aimed at providing an optimized consumer-end user experience. Java SE 6 Update 10 focuses on the following areas:

• Enhanced Java deployment
• Improved performance and look & feel
• Next-Generation Java Plug-In

Source Code Analysis Using Java 6 APIs
Contents

• Invoking the Compiler from Code: The Java Compiler API
• Annotation Processing: The Pluggable Annotation Processing API
• Writing a Custom Annotation Processor
• Plugging In the Annotation Processor
• Accessing the Abstract Syntax Tree: The Compiler Tree API
• Setting the Source Location
• Verifying the Source Against Rules
• Running the Sample
• Summary
• Resources

Deep dive into assembly code from Java
One of the things I learned in The Server Side Java Symposium 2008 was a command-line option to print out the assembly code that JIT is producing. Since I've always been interested in seeing the final assembly code that gets produced from your Java code, I decided to give it a test drive.

Veille technologique semaine 14

Je vous propose quels articles pour cette semaine (avec ou sans un poisson d'avril ? A vous de vérifier).

• un premier sujet sur la non mutabilité (immutabilité) des objets en Java : comment supprimer les bugs de modification non souhaité des objets passés en paramètres des opérations. Le MIT propose le JSR 308 avec (entre autre) @ReadOnly pour indiquer la non mutabilité. Cette évolution du langage est essentielle car il est indispensable de préciser dans les interfaces des composants (services ou évènements), un contrat sans aucune ambiguïté sur les arguments en in (en entrée) : en lecture pour l'appelé, en out (en sortie) : en écriture pour l'appelé, ou en in out. C'est une notion proche du const du C / C++. La proposition du MIT doit être intégré dans le JDK 7. Cela va donc être une migration obligatoire.
  Question : comment gérer vous actuellement cette notion d'arguments in, out ou in out dans les opérations de vos interfaces ? Comment spécifier vous ces notions ? Comment les vérifiez vous en test unitaires ? Je suis très intéressé par vos réponses.
• des articles sur le principe d'un langage spécifique (DSL : Domain Specific Language) en Java pour les assertions de JUnit : les matchers de hamcrest également utilisé par JMock. C'est très puissant et très agréable à utiliser. C'est la raison de passer à JUnit 4.4 pour le assertThat() et à JMock 2.4 pour les expectations
• les prochaines présentation du club d'utilisateur Java sur Paris avec une présentation (en anglais) sur la programmation concurrente et les performances.
• la machine virtuelle Java est-elle lente : des petits tests qui montre que la pratique est conforme à la théorie : le compilateur dynamique JIT (Just In Time) donne des meilleurs résultats que la compilation statique (appelé parfois compilation native) AOT (Ahead Of Time).

Bonne lecture.

A Practical Type System and Language for Reference Immutability
What code may modify a data structure? Under what circumstances? Currently, inadequate language support for:

• documenting immutability
• verifying immutability



• Argument immutability
• Return value immutability
• Object immutability
• Benefits of immutability constraints

Simplifier les assertions JUnit et améliorer vos tests
Nombreux sont ceux d'entre nous qui ont déjà utilisé JUnit pour écrire des tests.
Quel est celui qui n'a pas été déçu par les limitations inhérentes aux différentes méthodes assertXXX() ?
Quel est celui qui n'a pas utilisé des librairies supplémentaires (JUnit-addons, Unitils, ...) contenant des
méthodes utilitaires du type assertContains, ... ?
Quel est celui qui n'a pas écrit sa propre méthode utilitaire ?
Si vous vous sentez concernés, lisez la suite de cet article qui aborde :

• Les limites et défauts de JUnit
• Les solutions classiques
• Une solution magique

Flexible JUnit assertions with assertThat()

The Hamcrest Tutorial
Introduction
Hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. There are a number of situations where matchers are invaluble, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used. This tutorial shows you how to use Hamcrest for unit testing.

Literate Programming with jMock

Prochaines réunions Paris JUG (Java User Group)

Les performances Java : mardi 8 avril 2008
19h à 19h15 : Accueil
19h15 à 20h30 : Les performances Java
*** La présentation est en anglais ***

La machine virtuelle Java est-elle vraiment lente ?
Le code natif n'est pas forcément plus rapide que du bytecode, et que cela pouvait même être l'inverse puisque les JVM actuelles utilisent un compilateur JIT.

Lorsqu'on compile un code natif, les compilateurs n'activent pas toutes les optimisations possibles afin que le programme puisse s'exécuter sur des machines ne disposant pas forcément du même type de matériel (et particulièrement le CPU).

A l'inverse, le bytecode Java est compilé dynamiquement à l'exécution par le compilateur JIT. Ce dernier peut donc prendre en compte les spécificités de la machine. Le gain de performance peut être très important...

Conclusion
Le code natif ne se révèle pas forcément plus rapide que le bytecode Java puisqu'il ne peut pas bénéficier de toutes les optimisations possibles du matériel à moins de procéder à une compilation spécifique. Il peut toutefois être plus performant que la JVM Client dans certain cas, reste à savoir si le gain de performance est vraiment aussi important sur une application cliente...

Dans bien des cas la JVM Server se montre la plus performante puisqu'elle profite au maximum des spécifités de la machine. Toutefois pour des applications normales (c'est à dire qui ne se contentent pas d'effectuer la même opération 100 millions de fois), le gain ne sera pas forcément aussi évident...

Concernant le mode interprété, il semble plus qu'évident qu'il est à l'origine du mythe sur la lenteur de Java, mais cela n'a plus rien à voir avec les JVM actuelles...