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.
