Veille technologique semaine 17 et 18

Je vous propose, pour les semaines 17 et 18 les quelques articles suivants :

• l'art de la séparation des préoccupations : article très théorique,
• les dix commandements des tests unitaires,
• la troisième partie sur les EJB 3.1 : l'asynchronisme des services,
• comment transformer une méthode en objet : les closures,
• un premier article sur la réalisation d'application multi-threadé en Java pour exploiter les multi-cores,
• un complément au noyau 2.6.25 de la supervision des threads temps réel,
• l'instrumentation des classe par un agent pour réaliser du tissage de code pour faire de la programmation par aspects (AOP) pour les trace de log,
• la sortie de NetBeans 6.1 en version finale

Bonne lecture.

The Art of Separation of Concerns
In software engineering, Separation of Concerns refers to the establishment of
logical boundaries to define and delineate purpose. This improves the ability to
manage and maintain systems by providing order and elegance to the form and
function of system design.
The goal of this article is to promote the understanding of Separation of
Concerns and to establish a set of foundational concepts useful to developers and
architects toward its application.

The Value of Separation
Applying the principle of Separation of Concerns can increase the stability,
maintainability, extensibility, reusability, adoption, and even the logical and
aesthetic design and flow of a system.

Les 10 commandements des tests unitaires
Les tests unitaires ne sont pas qu'une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d'un développement itératif.

Le refactoring et la modification d'une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.

Vous trouverez ci-dessous nos 10 commandements des tests unitaires.

New Features in EJB 3.1 part III
This series of articles is a preview of the changes the EJB 3.1 expert group is working on for the next version of the Java EE specification. The idea is to give you a head's up on the changes as well as gather your feedback early so the expert group has the best chance of getting it right. EJB 3.0 brought simplicity to Java EE 5 by moving away from a heavyweight programming model. EJB 3.1 aims to build on those successes by moving further down the path of simplicity as well as adding a handful of much-needed features. In each article in this series, I will let you know about the progress made by the expert group.

• Asynchronous Invocation of Session Beans
• EJB Lite is Here
• Features Still on the Table

First-class methods: Java-style closures
In Java, the method is the principal construct where application logic resides. At present, a method can only exist within a class and cannot be manipulated or referenced in any simple manner.

Other languages permit a block of application logic to be referenced outside of a class, and this is often referred to as a function or a closure. A Java developer can approach the power of functions/closures using two techniques - reflection and inner classes. However, neither is very developer friendly - reflection is not compile-time safe or refactorable, and inner classes are very verbose.

As a result of the difficulty of writing code using reflection and inner classes the techniques tend to be limited to callbacks between an application and a framework. However, the majority of uses of functions or closures in other languages is for small-scale code re-use. This typically involves refactoring out common sections of code which may have a common beginning and end, but different code in the middle. In this scenario, the extracted code isn't run at a much later time like a callback is, but immediately as the original code would have done.

Building Multi-core Ready Java Applications, Part I
With the advent of multi-core processors, the existing subject of symmetric multiprocessing has been thrust to the forefront in the development community. As multi-core CPUs make parallel processing systems more prevalent, and more affordable, there is an increasing need for frameworks that help to handle threading, synchronization, deadlock detection, memory management, data pipelining, vertical/horizontal data partitioning, and so on.

This two-part article series will discuss some of the special design, development and testing techniques that must be used to take full advantage of multiprocessor systems. It examines some frameworks available to make Java-based parallel programming easier and even transparent in some cases.

Finally, Secure Real-Time on the Desktop
Real-Time Group Scheduling, a feature which allows to limit the amount of CPU time real-time processes and threads may consume.

Traditionally on Linux real-time scheduling was limited to priviliged processes, because RT processes can lock up the machine if they enter a busy loop. Scheduling is effectively disabled for them -- they can do whatever they want and are (almost) never preempted by the kernel in what they are doing.

Add Logging at Class Load Time with Java Instrumentation
When trying to analyze why a program failed, a very valuable piece of information is what the program was actually doing at that time. In many cases this can be determined with a stack trace, but frequently that information is not available, or perhaps what you need is information about the data which was being processed at the time of failure.

Traditionally this means using a logging framework like log4j or Java Logging API, and then writing and maintaining all necessary log statements manually. This is very tedious and error prone and well-suited for automation. Java 5 added the Java Instrumentation mechanism which allows you to provide "java agents" which can inspect and modify the byte code of the classes as they are loaded.

This article will show how to implement such a java agent which transparently will add entry and exit logging to all methods in all your classes with the standard Java Logging API. The example used is Hello World:

NetBeans 6.1 released
The NetBeans community has announced the final release of NetBeans 6.1, now available for download:

"NetBeans IDE 6.1 supports a wide range of open source scripting technologies and offers improved performance. This release extends language support beyond Java technology by providing a rich set of features for C/C++, JavaScript and the Ruby language, including Ruby on Rails.

One of the downloads available is an Early Access preview of support for PHP. Advance versions of new modules, such as JavaScript debugger, support of ClearCase, AXIS, and Hibernate are available as separate plugins.

NetBeans IDE 6.1 also contains all of the improvements made in 6.0 including: the new smarter editor, next generation of the ground-breaking GUI builder (formerly known as Project Matisse), visual mobile designer, integrated profiler, and Java EE 5 support.

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...

Veille technologique semaine 13

Toutes les analyses montrent un réel besoin d'ajouter la notion de programmation concurrente (parallèle) dans les langages informatiques. Microsoft investi 20 millions de dollars avec Intel pour compléter la plate-forme DotNet. La loi de moore doit maintenant être prise en compte par le logiciel. SUN propose déjà une machine avec deux processeurs ayant chacun 8 cœurs exécutant chacun 8 threads : total 128 threads physiques. Il est considéré que ces 128 threads physiques seront pour le grand public dans 5 ans. Conclusion : préparer la conception de vos logiciels pour prendre en compte la loi de moore.

• Microsoft investi avec Intel dans la programmation parallèle.
• La gestion de la concurrence du JDK 7 n'est pas suffisante : en plus des API, il faut intégrer cette notion dans le langage Java.
• avec l'unification des runtimes, il est possible de faire exécuter du code JRuby dans un serveur d'application EJB pour bénéficier des services techniques : remote, persistance, répartition de charge, tolerance aux pannes ....
• Le JSR 303 proposé en draft final pour le JDK 7 pour la validation (vérification) des contraintes d'un modèle de données métier : @NotNull, @Length, @NotEmpty, @Range(min=4, max=40), ...

Bonne lecture.

Microsoft, Intel to invest $20M in parallel computing
Microsoft and Intel have recently announced a $20 million joint investment into parallel computing over the next 5 years. The money will go to two Universal Parallel Computing Research Centers located at University of California Berkeley and the University of Illinois. The Berkeley university will add $7 million for its center, while the University of Illinois will bring $8 million to fund the research in its own center.

The purpose of the research is to develop software that runs more efficiently on systems with multiple processors. The move was triggered by the current trend of the industry to develop processors with multiple cores. The idea is to distribute the work over multiple cores or processors so several tasks can be executed simultaneously. A white paper written by UC Berkeley researchers affirms:

Conventional wisdom is now to double the number of cores on a chip with each silicon generation. ... Our view is that this evolutionary approach to parallel hardware and software may work from 2 or 8 processor systems, but is likely to face diminishing returns as 16 and 32 processor systems are realized, just as returns fell with greater instruction-level parallelism. The target [of the research] should be 1000s of cores per chip.

But the computing power of a 100 cores processor won't be of much help if the software running on it does not scale well.

The concurrency support in Java7 is not enough
In the Java programming language it is easy to see the evolution of the language:

• 1995: Support for threads built into the language (Thread, synchronized, volatile)
• Java5: Included java.util.concurrent (which adds a lot of nice to have classes when doing Thread programming)
• Java7: Talk about introducing frameworks supporting further multi-core usage

My main concern for Java7 is that it might not be enough to cover the new ballpark being brought forward by the many-core hardware. What do I base this fear on then?

Rails Powered by the GlassFish Application Server
This article introduces JRuby, JRuby on Rails, and the GlassFish application server. It presents a traditional
Ruby-on-Rails application deployment, describes an alternative using the GlassFish application server, and
explains the various options for deploying JRuby applications on GlassFish.

Many developers see the GlassFish application server as the superior solution for developing and deploying JRuby-on-Rails applications chiefly due to the following advantages:

• You can develop in the same environment in which you deploy.
• You can deploy multiple applications in a GlassFish instance that is already running.
• GlassFish can handle multiple requests by maintaining JRuby runtimes and database connections in pools.
• Clustering and high availability are integrated into GlassFish v2.
• GlassFish leverages existing investment in the Java Platform, Enterprise Edition (Java EE) while hosting JRuby-on-Rails applications in the same environment.

JSR 303: Bean Validation
This document is the specification of the Java API for JavaBean validation in Java EE and Java SE. The technical objective of this work is to provide a class level constraint declaration and validation facility for the Java application developer, as well as a constraint metadata repository and query API.

Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving time consuming and error-prone.

To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the
domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself.

This JSR defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the meta-data through the use of XML validation descriptors.

The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the Java- Beans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility are influencing the design of this specification.

Veille technologique semaine 12

Pour cette semaine, je vous propose le cocktail suivant :

• Le catalogue des sessions proposée par SUN au prochain JavaOne les 6 au 9 mai 2008 à San Francisco.
• Les tech days de Microsoft de février dernier au palais des congrès à Paris
• Intel propose 8 règles pour le design multi-threadé des applications qui souhaitent bénéficier de la puissance des processeurs multi-cores.
• Un résumé des propositions du JDK 7 : Dolphin
• Le Beans Binding du JDK 7 intégré à NetBeans
• Les fenêtres translucides et non rectangulaires

Bonne lecture.

JavaOne 6-9 may 2008 San Francisco : Content Catalog

TechDays Microsoft : exercice de séduction vis-à-vis des développeurs
Pour sa première session pleinière, Microsoft France a surtout fait des démos technos de ses nouveautés liées à Visual Studio 2008 et SQL Server 2008.

Salle comble dans l'amphithéâtre du Palais des Congrès Porte Maillot à Paris pour la première session pleinière orientée développeurs des Microsoft TechDays (du 11 au 14 février).

8 Simple Rules for Designing Threaded Applications
The Threading Methodology used at Intel has four major steps: Analysis, Design & Implementation, Debugging, and Performance Tuning. These steps are used to create a multithreaded application from a serial base code. While the use of software tools for the first, third, and fourth steps is well documented, there hasn't been much written about how to do the Design & Implementation part of the process.

There are plenty of books published on parallel algorithms and computation. However, these tend to focus on message-passing, distributed-memory systems, or theoretical parallel models of computation that may or may not have much in common with realized multi-core platforms. If you're going to be engaged in threaded programming, it can be helpful to know how to program or design algorithms for these models. Of course, these models are fairly limited and many software developers will not have had the opportunity to be exposed to systems that need such specialized programming. Multithreaded programming is still more art than science.

This article gives 8 Simple Rules that you can add to your palette of threading design methods. By following these rules you will have more success in writing the best and most efficient threaded implementation of your applications.

Rule 1. Be sure you identify truly independent computations.
Rule 2. Implement concurrency at highest level possible.
Rule 3. Plan early for scalability to take advantage of increasing numbers of cores.
Rule 4. Make use of thread-safe libraries wherever possible.
Rule 5. Use the right threading model.
Rule 6. Never assume a particular order of execution.
Rule 7. Use thread-local storage whenever possible; associate locks to specific data, if needed.
Rule 8. Don't be afraid to change the algorithm for a better chance of concurrency.

Java SE 7.0 Proposals Dolphin's Overview

À 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, …

Synchronizing Properties with Beans Binding (JSR 295)
Beans Binding is a Java platform library defined by Java Specification Request 295. JSR 295 is an open source project that tries to simplify how developers synchronize two properties, usually in two different objects. The JSR has a reference implementation available as the Beans Binding project on java.net. Additionally, NetBeans IDE 6 includes the latest release of the Beans Binding library, making it easy for NetBeans users to try out the new library.

• Synchronization Without Beans Binding
• Beans Binding Setup
• Properties
• Binding
• Binding Conversions

Translucent and Shaped Swing Windows
Support for translucent and shaped windows has been a long-standing request for the AWT and Swing teams. Even though native applications have had access to this functionality on all major operating systems for quite a few years, it has not been accessible in core Java. This is changing in the upcoming "Consumer JRE," a major update to Java SE 6 which provides an API to create shaped, globally translucent, and per-pixel translucent top-level windows.

Veille technologique semaine 11

Je vous propose pour cette semaine, les quelques articles suivants :

• Comment la programmation par aspect et le développement centré sur le modèle peuvent être complémentaire ? Comment la séparation des préoccupations peut elle être faite correctement ?
• Les types nullable de C#
• Les garbages collectors générationel du JDK 6 et ceux du JDK 7 : garbage first
• Java et le temps réel pour les applications d'entreprises
• La suite des nouvelles fonctionnalités des EJB 3.1 : les times services, le packaging
• Les super package du JDK 7 : gestion plus souple des visibilités des classes et des méthodes.
• l'outil de visualisation de l'activité d'une JVM : VisualVM, plug-in de la jconsole du JDK 6.

Bonne lecture.

Cross-Cutting Concerns in Model-Driven Software Development
Abstract
Aspect Oriented Programming (AOP) as well as Model-Driven Software Development (MDSD) are both becoming more and more important in modern software engineering. Both approaches attack important problems of traditional software development. AOP addresses the modularization (and thus, reuse) of cross-cutting concerns (CCC). MDSD allows developers to express structures and algorithms in a more problem-domain oriented language, and automates many of the tedious aspects of software development.

How can cross-cutting concerns be handled effectively in an MDSD based development environment?

Working with Nullable Types in C#
Use nullable types to assign null values to value types(primitives) and avoid run-time exceptions in your applications.
Working with value types was sometimes awkward in .NET 1.x, because they could cause serious problems in applications that retrieved data from database tables containing columns that can have null values—those that may or may not hold data. C# 2.0 presents a new concept called "nullable types" that lets you initialize value types to null values. This article discusses how you can apply the new nullable types feature to solve issues that result from having null values in database columns.

GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7)
L'analyse empirique montre que dans une application la très grande majorité des objets créés sont détruits presque immédiatement. 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

Real-Time Java for the Enterprise
When people hear about real-time computing they often make the mistake of thinking that these have to be fast systems and are nearly always used for control of mechanical systems. It is true that in most cases the response times required are fast, but speed is not what defines a real-time system. The true core of a real-time environment is that the system will guarantee to perform some task within a pre-defined time so that the system's behaviour becomes fully deterministic.

New features in EJB 3.1 part 2
This series of articles is a preview of the changes the EJB 3.1 expert group is working on for the next version of the Java EE specification. The idea is to give you a head's up on the changes as well as gather your feedback early so the expert group has the best chance of getting it right. EJB 3.0 brought simplicity to Java EE 5 by moving away from a heavyweight programming model. EJB 3.1 aims to build on those successes by moving further down the path of simplicity as well as adding a handful of much-needed features. In each article in this series, I will let you know about the progress made by the expert group.

The Open Road: Superpackages
Since Java 1.0, packages have offered a convenient means of organizing code into different namespaces at the source code level. Classes in the same package can see non-public, non-protected, and non-private methods and fields in other classes in the same package that classes in other packages cannot see.

Unfortunately, there's no standard adjective for members that have no explicit access specifier. The most common, though by no means standard, name for these fields and methods seems to be "default" access. They're also sometimes referred to as "package protected" or "package private." The Java Language Specification uses "default (package)," and that is what I'll use in this article.

What's VisualVM?
VisualVM is a visual tool that integrates several existing JDK software tools and lightweight memory and CPU profiling capabilities. This tool is designed for both production and development time use and further enhances the capability of monitoring and performance analysis for the Java SE platform.

We would like to announce the availability of the VisualVM Beta.

Key news in Beta:

• Applications defined by JMX connection
• Application snapshots
• Defined hosts and VM coredumps persistent between VisualVM sessions
• Save As & Load for thread dumps and heap dumps
• Autodiscovery of jstatd started after defining remote host
• Improved support for JRockit VMs
• New icons
• Main menu & toolbar cleanup
• New icons
• Customizable Options
• GlassFish plugin on VisualVM Beta Plugin Center

VisualVM is an open-source Java VM monitoring and performance reporting tool that provides visual feedback about running Java applications. The project released its first beta version on java.net. Visualizing characteristics of a running Java application was pioneered by BEA's JRockit virtual machine, which was followed by a large array of monitoring and performance reporting tools, such as jconsole, jstack, or jinfo.

Each of these tools was designed to provide feedback on a specific subset of application execution characteristics, requiring developers to employ multiple tools to get a complete picture of a Java application's execution. At the same time, none of those tools provide a detailed picture of how well an application actually performs.

VisualVM, a new open-source tool developed on java.net, aims to unify many of the capabilities present in earlier tools, and amend those with performance reporting as well. VisualVM can be used during development, and even on a production application, according to the project's documentation, as the tool can be attached to any running Java application:

VisualVM is a tool that provides detailed information about Java applications while they are running. It provides an intuitive graphical user interface that allows you to easily see information about multiple Java applications. Java applications are run by a Java Virtual Machine, or VM. The name VisualVM comes from the fact that VisualVM provides VM information visually.

There are many new features in this release: applications defined by JMX connection, application snapshots, defined hosts and VM coredumps persistence, Load & Save As for thread dumps and heap dumps, autodiscovery of jstatd started after defining remote host, improved support for JRockit VMs, new icons, main menu & toolbar cleanup, customizable Options, GlassFish plugin on Plugin Center.