vendredi 29 mai 2009

Veille technologique semaine 22

Pour le bulletin de cette semaine, je vous propose les articles suivants :
  • comment l'acquisition de SUN par ORACLE va-telle changer Java ?
  • le catalogue de JavaOne 2009, la plus grande manifestation du monde Java, à San Francisco : du 2 au 4 juin prochain.
  • le début et la fin de CORBA : quelle est l'espérance de vie de CORBA ? Cet article est un point de vue. Quel est le votre ?
  • Google annonce son soutient à HTML 5.
  • troisième partie sur des interviews de gurus du développement logiciel.
  • Les NIO2 pour le JDK 7 : accès au système de fichiers.
  • Les nouveautés de JDO 2.3
  • Les nouveautés de JPA 2.0

Bonne lecture.


Oracle/Sun: The end of Java as we know it?
A community weighs the pros and cons of Oracle's new claim on Java.

While Oracle and Sun Microsystems are hailing Oracle's purchase of Sun as a big boost for Java, others are not so sure. Some with stake in the Java ecosystem are questioning what kind of control Oracle might try to exercise over the popular software development platform, which has driven enterprise applications since its debut in 1995. Observers also expect Oracle to make a go of trying to make more money off of Java than Sun ever could.


JavaOne 2009 Content Catalog
Select your search criteria, then click on the ''Start Search'' button.
NOTE: Content subject to change.


JavaOne 2009 - Java 7 talks
Every year (can't believe this is the 3rd year now) I have done a list of Java 7 talks at JavaOne and here's my list for 2009:


The rise and fall of CORBA :
Depending on exactly when one starts counting, CORBA is about 10-15 years old. During its lifetime, CORBA has moved from being a bleeding-edge technology for early adopters, to being a popular middleware, to being a niche technology that exists in relative obscurity. It is instructive to examine why CORBA—despite once being heralded as the "next-generation technology for e-commerce"—suffered this fate. CORBA's history is one that the computing industry has seen many times, and it seems likely that current middleware efforts, specifi cally Web services, will reenact a similar history.



Google Bets Big on HTML 5: News from Google I/O
"Never underestimate the web," says Google VP of Engineering Vic Gundotra in his keynote at Google I/O this morning. He goes on to tell the story of a meeting he remembers when he was VP of Platform Evangelism at Microsoft five years ago. "We believed that web apps would never rival desktop apps. There was this small company called Keyhole, which made this most fantastic geo-visualization
software for Windows. This was the kind of software we always used to prove to ourselves that there were things that could never be done on the web." A few months later, Google acquired Keyhole, and shortly thereafter released Google Maps with satellite view. "We knew then that the web had won," he said. "What was once thought impossible is now commonplace."

Google doesn't want to repeat that mistake, and as a result, he said, "we're betting big on HTML 5." Vic pointed out that the rate of browser innovation is accelerating, with new browser releases nearly every other month. The slide below, from early in Vic's talk, shows the progress towards the level of UI functionality found in desktop apps through adoption of HTML 5 features in browsers. This looks like one
of Clayton Christensen's classic "disruptive innovation vs sustaining innovation" graphs. It's also fascinating to see how mobile browsers are in the forefront of the innovation.


The Developer Insight Series, Part 3: The Process of Writing Code
Over the years, I've heard developers talk about their favorite code, funniest code, most beautiful code, how to write code, how not to write code, the obstacles to writing good code, what they love and hate about writing code, and so on. In the process, I've encountered many insights worth sharing.
Parts One and Two of this series provided advice on how to write good code. In Part Three, developers reflect on the actual process of writing code, how it happens, what it feels like, and how they do it.



The Java NIO.2 File System in JDK 7
JSR 203, a major feature of JDK 7 under the leadership of Sun software engineer Alan Bateman as an OpenJDK project, contains three primary elements that offer new input/output (I/O) APIs for the Java platform:
  • An extensive File I/O API system addresses feature requests that developers have sought since the inception of the JDK.
  • A socket channel API addresses multicasting, socket binding associated with channels, and related issues.
  • An asynchronous I/O API enables mapping to I/O facilities, completion ports, and various I/O event port mechanisms to enhance scalability.
This article provides a basic overview of the first element, the File I/O API. The abbreviation NIO generally refers to new I/O APIs that allow for I/O operations in Java technology. The java.nio, java.nio.channels, and java.nio.charset packages have been in existence since the inclusion of JSR 51 in Java version 1.4.* JSR 203 adds NIO.2 in JDK 7.


Les nouveautés de JDO 2.3

JDO (Java Data Objects), longtemps délaissé au profit d'Hibernate, puis de JPA, a été récemment remis en avant par le support Java de Google App Engine qui préconise l'utilisation de cette API pour assurer la persistance des données dans les applications qu'il héberge.

Andy Jefferson, co-fondateur du projet DataNucleus, vient de poster un tour d'horizon des nouveautés de JDO 2.3 dont l'API est actuellement disponible en early access. Ces nouveautés sont :

  • Metadata API : la définition des classes à persister pouvait jusqu'alors se faire par XML ou par annotations. Cette JDO 2.3 vient ajouter une troisième possibilité avec cette API permettant de définir dynamiquement des classes persistables.
  • Enhancer API : cette API vient en complément de la précédente. En effet dans la mesure où les implémentations de JDO s'appuient sur du bytecode enhancement des classes persistables, il est nécessaire d'offrir aux développeurs un moyen d'invoquer l'enhancer après avoir déclaré dynamiquement une nouvelle classes via la Metadata API.
  • Timeout et annulation de requêtes : dans le monde JPA, ces deux fonctionnalités ne sont pas supportées par la spécification mais seulement en tant qu'extensions propriétaires.
  • Contrôle des verrous en lecture des objets : permet un contrôle fin des objets qui doivent être verrouillés automatiquement lors de la lecture, évitant ainsi d'opérer un verrouillage global.
Répondant à des besoins modernes, ces changements devraient être appréciés par les développeurs. Reste que l'avenir de JDO est flou : ne pouvant rivaliser avec la popularité de JPA, JDO pourrait se maintenir dans des cas d'utilisation particuliers et ainsi perdurer dans les années à venir tout en restant marginal.


What's New in JDO 2.3
Java Data Objects (JDO) is a specification for Java persistence that started in 2000, with 2 major releases JDO1 (2002 under JSR0012) and JDO2 (2006 under JSR0243). It was placed under Apache in 2005 and is the rare example of a specification that has undergone continual improvement during its lifetime, for the last 4 years being developed totally in the open, accepting input from everyone. Most recently it was provided as an integral part of the Google AppEngine for Java [1] JDO 2.3 was started in October 2008, and encompasses additions to the specification in the areas of a metadata API, an enhancer API, addition of cancel/timeout control to queries, and addition of control to the locking of objects when read.



Java Persistence 2.0 Proposed Final Draft

The Java Persistence API (JPA) version 2.0, now in proposed final draft, is a significant update to the specification adding an API for criteria queries, a metamodel API, and support for Bean Validation [JSR 303].

vendredi 22 mai 2009

Veille technologique semaine 21

Pour le bulletin de la semaine 21, je vous propose les articles suivants :
  • La conception des API est un exercice difficile, qui doit être fait avec un certains nombres de règles.
  • JavaFX : technologie controversé ? Quel avenir ?
  • Un exemple d'utilisation de Java pour les applications interactives pour la TV
  • La sortie d'Androide 1.5 : la plate-forme de Google pour les téléphones portables ou autres PDA.
  • Un article sur le model driven : force et limitation ?
  • Un article sur Clojure, un langage qui aide la programmation concurrente. Une bonne inspiration pour Java.
  • Un compilateur pour le langage D pour la plate-forme DotNet. Le langage D est une proposition d'évolution du C++ (sans compatibilité).
  • La programmation par contacts bientôt en natif dans DotNet (C#).
  • Le projet Axum de Microsoft pour la programmation concurrente (parallel programming ) prise en charge par le langage C#.
  • La JVM et la gestion de la mémoire native.
  • Le look and feel Numbus, par défaut pour le JDK 7 ?
  • Un article au sujet des annotations de Spring 2.5 : comment simplifier l'utilisation de la configuration des objets.
Bonne lecture.


Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie et troisième partie) portant sur les bonnes pratiques de conception d'APIs. Il s'appuie sur un exemple d'API de configuration pour illustrer son propos. Les points qu'il met particulièrement en avant sont :

  • Il est important de sélectionner le niveau d'abstraction approprié et d'assurer l'uniformité de celui-ci sur l'ensemble de l'API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d'objets manipulés en entrée et en sortie, ainsi que la présence et le type d'exception éventuellement renvoyée.
  • N'offrir qu'une seule possibilité pour chaque besoin, afin d'éviter la confusion chez l'utilisateur de cette API.
  • S'appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d'une API.
  • L'API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l'utilisateur d'avoir à se plonger dans une documentation.
Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c'est souvent le cas dans l'énonciation de bonnes pratiques ou de pattern, tout l'intérêt réside ici dans la formalisation apportée par l'auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l'intéressant retour d'expérience d'un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).


JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d'elle car personne ne sait dire aujourd'hui ce qu'il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu'elle n'est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d'observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d'horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d'animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

  • la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux 'All the screens of your life') n'est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
  • les composants graphiques de haut niveau sont absents. Il s'agit pourtant d'un élément indispensable pour le développement d'applications RIA.
Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d'ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.


Creating Interactive TV Applications With the Tru2way Platform and OCAP

This article introduces the concept of interactive TV, provides an overview of Tru2way technology, and shows you how to get started with Tru2way application development.

Contents

  • Introducing the Tru2way Platform
  • Comparing OCAP and BD-J API
  • Understanding the Concepts of Interactive TV
  • Creating Your First Tru2way Application: Selecting a Service
  • How to Get Started
  • Summary

Android 1.5 Platform Highlights
The Android 1.5 platform introduces many new features for users and developers.
The list below provides an overview of the changes :
  • User Interface Refinements
  • Performance Improvements
  • New Features
  • New APIs and Manifest Elements

Model Driven Development Misperceptions and Challenges
After many years, it still seems that the level of adoption of MDD is not what would be expected. There are a number of inhibiting factors that limit the usage of MDD, such as the lack of awareness of practical MDD success stories, doubts on how it can be used on a daily basis, lack of funding model for up-front investment, or lack of focus for strategic initiatives.


Clojure: Challenge your Java assumptions
Clojure is a dynamic functional language for the JVM, recently released in version 1.0. Clojure offers a new set of programming techniques for robust code and rapid development. In particular, it has new solutions for multicore computing. Whether you make the shift to Clojure or stick to Java, learning about this new language will challenge your assumptions about the best way to design software.


Language D for the .NET platform.
D is a multi-paradigm language: it has object orientation support, it allows functional and template meta programming and even includes untamed features such as a goto keyword and inline assembly. I heard Walter Bright (the father of D) describing it as a language invented by a compiler implementer (not a language designer). That may be true, and indeed some of the most successful software projects came out of their authors' need to scratch an itch. However, Walter' s description may undersell D, because he definitely designed it with users in mind and not just with what syntax would make parsing easier to implement.


Details on Using Code Contracts
InfoQ informed on the availability of Code Contracts for .NET. This time we want to offer more details on using Code Contracts, an important addition to .NET.


Axum, Microsoft's Approach to Parallelism
Axum, previously known as Maestro, is a Microsoft incubation language project meant to provide a parallel programming model for .NET through isolation, actors and message passing. The language borrows many concepts from Erlang but with a C#-like syntax.
Axum is an imperative language with a C#-like syntax. While it is aware of objects, classes cannot be defined, because the language is domain and actor- oriented instead of being object-oriented. Axum is not a general purpose language being targeted at solving concurrency tasks and is built upon Concurrency and Coordination Runtime (CCR) from Microsoft Robotics. The idea is to make calls to Axum code from other .NET languages when parallelism is necessary.


La mémoire native en Java

Andrew Hall a publié deux articles très intéressants portant sur la gestion de la mémoire native dans la JVM, c'est-à-dire la mémoire consommée par la machine virtuelle mais ne faisant pas partie de la Java Heap et n'étant donc pas gérée par le garbage collector. Les systèmes d'exploitation couverts par ces articles sont Windows, Linux et AIX.

Après avoir fait un rappel sur la gestion de la mémoire par les systèmes d'exploitation, l'auteur explique en détail les différents composants Java susceptibles de consommer de la mémoire native non gérée au sein de la Heap Java. En font partie le bytecode des classes chargées par les classloaders, la mémoire allouée par le code JNI natif, les direct buffers NIO et les stacksde chaque thread. Le problème est que la mémoire totale adressable par un processus 32 bits est de 2 à 4 Go selon les cas. Des crashs de la JVM, dus à un manque de mémoire, peuvent donc parfois intervenir alors que la Java Heap n'est pas pleine.

Les solutions à cette problématique sont passées en revue, parmi lesquelles figurent : réduire la mémoire totale utilisée par la JVM en réduisant la taille de la Java Heap (via -Xmx), réduire l'utilisation de mémoire native non gérée par la Java Heap, repousser la taille limite de la mémoire adressable par le processus de la JVM en passant par exemple à un OS et une JVM 64 bits.

Au-delà des informations fournies par ces deux articles, les lecteurs intéressés par ce sujet pourront étudier le très complet, bien qu'ancien, livre de Bill Venners, 'Inside the Java Virtual Machine', partiellement disponible en ligne.


Activating Nimbus Look and Feel
There are three ways to activate the Nimbus Look and Feel.


Simplifiez votre configuration Spring 2.5 avec les annotations
Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l'annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).
Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?

vendredi 15 mai 2009

Veille technologique semaine 20

Pour le bulletin de la semaine 20, je vous propose les articles suivants :
  • les évolutions de HTML 5 et de JavaScript propose de faire de l'IHM web riche : interaction, drag and drop, rendu 2D, multimédia, application offline ...
  • La sortie de la version 1 de Clojure, un langage de programmation dont le compilateur génère du byte code pour les JVM. Un langage de plus pour les JVM, après Groovy, JRuby, Scala et autre Jython.
  • un article théorique sur le dispatch dynamique d'invocation de méthode (ou multi-dispatch ou multi-méthodes).
  • Les compléments du langage C# 3.0 sorti en 2006.
  • Quelque articles au sujet de la proposition faite par Google et Spring source de normaliser les annotations Java pour injection de dépendance : @Inject. L'annonce faite par Google et le texte de la proposition avec les différentes annotations : @Inject, @Qualifier, @Scope, @Name et @Singleton.
  • Un dernier article qui explique pourquoi cette proposition n'est pas bonne : les termes proposés (@Inject) sont des termes technique et non sémantique. L'auteur préfère du vocabulaire qui a du sens : @Service, @Uses. Quel est votre avis ? Préférez vous des annotations génériques ou des annotations qui ont un sens plus spécifiques.

Bonne lecture.


Evolution of JavaScript Frameworks for HTML 5
HTML 5 is the fifth major revision of the core language of the World Wide Web and was pioneered in 2004 by the Web Hypertext Application Technology Working Group (WHATWG). Although the specification is ongoing work, parts of HTML 5 are already implemented in browsers like Safari 4 beta.

Amongst the new features squarely targeted at application developers, HTML 5 introduces a number of new Javascript APIs. These can be used in conjunction with corresponding HTML elements and include:
  • A 2D drawing API which can be used with a new canvas element for rendering graphs, game graphics, or other visual images on the fly.
  • An API that allows a web application to register itself for certain protocols or MIME types.
  • An API that introduces a new caching mechanism to support off-line web applications.
  • An API for playing video and audio which can be used with the new video and audio elements.
  • A history API that exposes the browsing history and allows pages to add to it to facilitate better back-button support in AJAX applications.
  • Cross-document messaging which provides a means by which documents can communicate with each other regardless of their source domain, in a way designed to prevent cross-site scripting attacks.
  • A drag & drop API to use in combination with a draggable attribute.
  • An editing API to use in conjunction with a new global contenteditable attribute.
  • A new network API to enable web applications to communicate with each other on local area networks, and to maintain bidirectional communications with their originating server.
  • Client-side persistent storage with JavaScript APIs for key/value pairs and support for embedded SQL databases.
  • Server-sent events in combination with the new event-source element which will facilitate persistent connections to remote data sources and largely eliminate the need for polling in web applications.

Clojure
Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.



Multiple Dispatch: A Fix for the Problems of Single Dispatch Languages

Almost all well-known object oriented languages (Java, C#, JavaScript, Python, Ruby, ...) have single dispatch: Methods are chosen depending on the (single) receiver of a message. On the other hand, there is multiple dispatch which is an interesting mix of functional method selection with mutable state. It is used in less-known object-oriented languages such as Common Lisp. In this article, we'll first look at Java's single dispatch and Java's overloading and then use what we have learned to understand multiple dispatch and how it solves some design dilemmas that can't be solved with single dispatch.


Le langage C# 3 :
sorti en version final en 2006, voici un ancien article qui résume les nouveautés : typage implicite, méthode d'extension, expressions lambdas, initialisateurs d'objets, types anonymes. Cela devrait être une source d'inspiration pour Java.


@javax.inject.Inject
Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:
  • @Inject - Identifies injectable constructors, methods, and fields
  • @Qualifier - Identifies qualifier annotations
  • @Scope - Identifies scope annotations
  • @Named - String-based qualifier
  • @Singleton - Identifies a type that the injector only instantiates once


JSR ?: Annotations for Dependency Injection
We propose to specify annotations to enable the reuse of injectable classes across multiple dependency injection frameworks.


@Inject standardisation de l'injection de dépendances
Pas mal de bruit la semaine dernière dans la blogosphère Java avec l'annonce par Google et SpringSource d'une nouvelle proposition de JSR dédiée à l'injection de dépendances : @Inject ("Annotations for Dependency Injection").

Comme le souligne 'Crazy' Bob Lee, l'auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l'injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).

Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l'autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).

@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.


Google Guice 2 - Les bases de l'injection de dépendances
Guice (prononcez Juice) est le framework d'injection de dépendances de Google. La configuration des dépendances se fait par code, à l'aide d'annotations, et nécessite donc l'utilisation de Java 5. Google travaille actuellement sur la V2 de son framework. Cependant, une mise à jour régulière du Wiki du projet et la publication de snapshots permettent d'ores et déjà de se faire une bonne idée de cette alternative à l'injection de dépendance 'à la Spring'. Nous entamons aujourd'hui une série d'articles qui a pour but de vous faire toucher du doigt la grande liberté qu'offre l'injection de dépendance par code. Nous irons progressivement des concepts de base de Guice 2.0, vers une utilisation avancée du framework.


Why @Inject is a Bad Idea:
Recently the JSR for standardizing injection annotations was announced. I think the proposal is going in the wrong direction, and would like to outline why in this post.
One of the main insights we have had so far in the Qi4j project is that if "anything can mean anything" then that is the same as "nothing means anything". Specifically, if all you need is a POJO to implement entities, values and services, then it is really really hard to ensure that any meaningful semantics is applied. This is why we specifically separate between the notions of Transient Composite, Entity Composite, Value Composite and Service Composite. Because they're different, and it's important that they are different. Treating them differently, as opposed to "all is just the same", gives us advantages. You can easily parallel this with the problems with SOAP, where everything "is just a POST to a URL", which then totally removes all of the goodness of HTTP and URL's.

Similarly we have to come value having injection annotations that actually mean something. So instead of having something like a generic @Inject annotation, which can mean anything and therefore nothing, we have opted to use annotations which specify the scope of the target object. The main annotations we use are therefore @Service, @Uses and @This. @Service means that a service must be injected. @Uses means that an instance in an instance graph (e.g. the M in a MVC setup) will be injected. @This means that I want to get a reference to "myself" but cast to a
specific interface, which makes sense in a Composite consisting of a bunch of mixins.

Sometimes an interface injection for a specific type can be resolved both by @Service (="I want an external service") and @This(="I am a service and want to call this interface on myself"), so differentiating between them is essential.

jeudi 7 mai 2009

Veille technologique semaine 19

Pour cette deuxième semaine du mois de mai, je vous propose les articles suivants :
  • Vers la fin du modèle économique "software" : grand système, software, Open Source ou SaaS ?
  • Quelques remarques suite au rachat de SUN par ORACLE : quel est l'avenir des produits SUN ?
  • Le club Java de Paris propose une soirée "Grid Computing " le mardi 12 mai : il faut s'inscrire sur le site web car il y a un nombre de place limitées : www.parisjug.org
  • une synthèse des trois jours de conférence Spring 2009 : Tomcat, tcServer et dmServer, Spring 3.0 et Java EE, Groovy.
  • IBM propose une extension au modèle de composant SCA pour prendre en compte les évènements : la convergence SOA (Service Oriented Architecture) et EDA (Events Driven Architecture) et en cours. Il est temps que l'industrie (re-)découvre que n'importe quel système d'information a besoin des deux concepts avec le même niveau d'importance. Ces deux concepts, services et événements, doivent rester des concepts d'analyse fonctionnelle (et non pas de design). Le modèle de composant SCA d'IBM est pris en charge par l'organisation de normalisation OASIS et une implémentation de référence Tuscany est disponible en Java et C++ sur le site d'Apache.
  • un article technique sur les Annotation Java : c'est quoi, et à quoi cela peut-il servir ? L'industrie propose la notion de DSL : Domain Specifique Language qui permet de construire des dialectes adaptés à un problème spécifique. XML est un moyen de faire une sorte de DSL un peut verbeux, les annotations Java permettent de faire un DSL simple en faisant une extension au langage Java (pour la partie statique).
  • un article sur les collections HashMap et HashSet du JDK. La HashMap est assez connue mais le HashSet l'est moins.
  • Le remoting en DotNet (C#) versus les web services : explication et comparaison
  • L'intégration des fenêtres non rectangulaire et semie-transparentes dans les sources du JDK 7

Bonne lecture.



Vers la fin du modèle "software"?

Les approches des différents modèles logiciels :
  • le modèle "grand système" considère que seul le matériel a une valeur importante, et que le logiciel n'en a pas
  • le modèle "software" propose une licence payante pour l'utilisation d'un logiciel. Cette licence est en principe perpétuelle, mais il faut, dans la pratique, la racheter tous les 3 ans.
  • le modèle "Open Source" propose généralement un logiciel gratuit, avec parfois un support payant.
  • le modèle "SaaS" considère qu'on doit payer un service à valeur ajouté, et non du matériel ou du logiciel.


The setting Sun: responses to the acquisition
Oracle's acquisition of Sun raised a lot of questions about the future of Sun's core technologies. Oracle says that it is committed to Solaris and Java, but some open source advocates are concerned about the implications for OpenOffice.org and MySQL. Ars looks at how Oracle and members of the open source software community have responded to the acquisition.


Paris JUG : Soirée Grid Computing le 12 mai
La prochaine soirée du Paris JUG aura lieu le mardi 12 mai 2009 dans les locaux de l'ISEP.

Cette soirée est divisée en deux parties :
  • Grid Computing, durée 1h30, présenté Jean-Michel Bea (Fastconnect), Cyrille Le Clerc (Xebia) et Erwan Alliaume (Xebia)
  • JavaRebel, durée 30 minutes, présenté par Jevgeni Kabanov, fondateur de ZeroTurnaround Le Paris JUG est victime de son succès : le nombre de places est limité et l'inscription est maintenant obligatoire, avez-vous réservé la votre ?


SpringOne 2009 - Synthèse
SpringOne Europe 2009 terminé, il est temps de faire le bilan de ces 3 jours à Amsterdam : une ligne directrice, quelques annonces, de belles présentations menées par des spécialistes de renom, et surtout, beaucoup de belles rencontres et discussions off intéressantes (dont certaines ne sont pas avouables sur ce blog :))


SCA Extensions for Event Processing and Pub/Sub
A new SCA specification, Assembly Model Specification Extensions for Event Processing and Pub/Sub describes the Event Processing and Pub/Sub Extensions for the SCA Assembly Model, which deals with:

  • Publication and Subscription (often shortened to Pub/Sub), which is a particular style of organizing the components which produce and consume events in which the producing components are decoupled from the consuming components. Components that are interested in consuming events specify their interest through a subscription rather than an interface. The same event may be received by multiple subscribers.
  • Event Processing, which is computing that performs operations on events, including creating, reading, transforming, and deleting events or event objects/representations. Event Processing components interact by creating event messages which are then distributed to other Event Processing components. An Event Processing component can, in addition, interact with other SCA components using SCA's regular service invocation mechanisms.

With continuing convergence between SOA and EDA, the introduction of events support in SCA strengthens its position as a premier SOA programming model.



An Introduction to Java Annotations
The objective of changing older JDK versions to JDK5 largely centered on enhancing ease-ofdevelopment. In other words, the new features shift the responsibility for writing the boilerplate code from the programmer to the compiler. If the source code is boilerplate free, it becomes easier to maintain. The resulting codes are also less likely to be bug-prone. One of these new ease-of-development features in JDK5 are annotations. Annotations are like metatags that you can add to your code and apply them to package declarations, type declarations, constructors, methods, fields, parameters, and variables. As a result, you will have helpful ways to indicate whether your methods are dependent on other methods, whether they are incomplete, whether your classes have references to other classes, and so on.

Annotation-based development is certainly one of the latest Java development trends. Annotation-based development relieves Java developers from the pain of cumbersome configuration. Quoting from Sun's official site, "It (annotation-based development) lets us avoid writing boilerplate code under many circumstances by enabling tools to generate it from annotations in the source code. This leads to a declarative programming style where the programmer says what should be done and tools emit the code to do it." Simply speaking, annotation is a mechanism for associating a meta-tag with program elements and allowing the compiler or the VM to extract program behaviors from these annotated elements and generate interdependent codes when necessary. In the first part of this three-article series, I'll describe some basics of annotation, their benefits, as well as some example usages.


Java Hashed Collections
HashMap and HashSet
The HashMap and HashSet classes provide two different but similar ways to organize a set of objects using the same underlying data structure.

The HashSet class is used to manage a set of objects that have unique values. Passing an object to a HashSet object's add method will add the object to the HashSet unless there is already an object in the HashSet that equals the object passed to the add method. There is also a contains method to find an object in a set and a remove method to remove an object from a set.

The HashMap class organizes objects into pairs. There are two roles in each pair. These roles are key and value. A HashMap object organizes the pairs of objects so that no two pairs have equal keys. This means that, for each key in a HashMap, there is exactly one corresponding value.


.NET Remoting Versus Web Services
With the advent of .NET and the .NET Framework, Microsoft introduced a set of new technologies in the form of Web services and .NET remoting. .NET remoting and ASP.NET Web services are powerful technologies that provide a suitable framework for developing distributed applications. It is important to understand how both technologies work and then choose the one that is right for your application.
The Web services technology enables cross-platform integration by using HTTP, XML and SOAP for communication thereby enabling true business-to-business application integrations across firewalls. Because Web services rely on industry standards to expose application functionality on the Internet, they are independent of programming language, platform and device.
Remoting is a technology that allows programs and software components to interact across application domains, processes, and machine boundaries. This enables your applications to take advantage of remote resources in a networked environment.


Translucent and shaped windows in JDK 7
The latest weekly drop of JDK 7 (b57) has finally exposed the functionality of translucent and shaped windows as publicly supported APIs on the java.awt.Windowclass. Bug 6802853 has tracked the progress of exposing these APIs previously available in 6u10+ in the internal com.sun.awt.AWTUtilities class, and it's time to update the examples to use the new public APIs.

To recap, here are the previous entries that used the AWTUtilities class:

• Translucent and shaped windows in core Java talked about the AWTUtilitiesclass in 6u10 and support for modern top-level windows effects.
• Soft clipping and per-pixel translucency for Swing windows explored the translucent effects on top-level windows.
• More tricks with translucent Swing windows followed up with the different effects achievable with the new translucent window support.
All the source files referenced in these examples have been updated to use the newWindow APIs, and here is a brief overview of the relevant API signatures:
• AWTUtilities.isTranslucencySupported(Translucency) is nowGraphicsDevice.isWindowTranslucencySupported(WindowTranslucency).
• AWTUtilities.isTranslucencyCapable(GraphicsConfiguration) is nowGraphicsConfiguration.isTranslucencyCapable().
• AWTUtilities.setWindowShape(Window, Shape) is nowWindow.setShape(Shape).
• AWTUtilities.setWindowOpacity(Window, float) is now Window.setOpacity(float).
• AWTUtilities.setWindowOpaque(boolean) is superceded byWindow.setBackground(Color). Passing the new Color(0, 0, 0, 0) achieves the old effect of installing per-pixel translucency.

vendredi 1 mai 2009

Veille technologique semaine 18

En cette veille de week-end prolongé, je vous propose les sujets suivants :
  • quelles sont les conséquences du rachat de SUN par ORACLE ?
  • un article qui propose la réunion des architectures orientées services (SOA) et des architectures orientées événements (EDA). Cette réunion permet de décrire complètement l'architecture logique de nos systèmes d'une manière complètement indépendante du socle technique : l'industrie parle de séparation des préoccupations et propose le terme de middlware agnostique. Il est donc essentiel de capitaliser cette architecture logique de nos systèmes, au niveau de la phase d'analyse et non du design. BEA, ORACLE et IBM propose le terme de EDSOA pour réunir ces deux styles d'architectures, qui ne sont pas liées aux solutions technologiques (le middleware, ou socle technique par exemple).
  • La deuxième partie de l'interview de quelques guru dans le domaine du logiciel.
  • Un article technique sur les "extension méthodes" en C# 3.0.
  • Un résumé le l'évolution de l'asynchronisme dans les architecture Web.
  • La sortie de la version 1.0.12 de JFreeChart avec encore plus de graphique : il faut aller vous la démo.
  • Le top 10 des fonctionnalité les moins utilisé du JDK : on peut noter que CORBA est un candidat à sortir du JDK depuis plusieurs années.
  • La préparation de l'update 14 du JDK 6 propose des évolutions importante.
Bonne lecture


What will Oracle's Planned Acquisition of Sun Mean for Java
Whilst Sun Microsystems and Oracle are hailing Oracle's purchase of Sun as a huge boost for Java many in the community are not so sure, wondering what kind of control Oracle will seek to exert over the platform.


How EDA extends SOA and why it is important
Many people think of SOA as synchronous RPC (mostly over Web services). Others say EDA is SOA. And there are people who say that the best of EDA and SOA is combined in SOA 2.0. But an architectural distinction can be made between a request-and-reply pattern and a publish-and-subscribe pattern. Both patterns are an inverse of each other. Because of the completely different nature and use of the two patterns, it is necessary to be able to distinguish between the both and to name them. You might say making such a distinction is a universal architectural principle. Combining both of the patterns into an increment of the version number of one of them is not a very clever act. It is appropriate and desirable to use the acronyms SOA and EDA to make this distinction, because SOA and EDA are both positioned in the same architectural domain; SOA focusing on (the decomposition of) business functions and EDA focusing on business events. This article explains the differences between the two patterns, when to use the one or the other and how to combine them.


The Developer Insight Series, Part 2: Code Talk
Over the years, I've heard noted developers talk about their favorite code, funniest code, most beautiful code, how to write code, how not to write code, the obstacles to writing good code, what they love and hate about writing code, and so on. In Part One of the Developer Insight Series, three Java Champions responded favorably to Brian Goetz's advice to write "dumb" code.
In Part Two, we hear code advice from five distinguished developers: Joshua Bloch and Masood Mortazavi echo Goetz's advice to keep code simple. Jaron Lanier and Victoria Livschitz want to radically change the way code is created. And renowned bug fixer Brian Harry provides tips on bug fixing while emphasizing what the process can teach us.


Skinning with Extension Methods
One of the new language features introduced with C# 3.0 and Visual Basic.Net 9.0 is Extension Methods. Extension methods enable new behaviors to be invoked on otherwise closed types. One application of extension methods that will be discussed here is their use in class library development for enabling multiple styles of interfaces for components. This might be thought of as "skinning" an API.


What is the Asynchronous Web ?
Legacy web applications are synchronous in nature. The user interacts with the web interface presented in the browser, the browser makes requests back to the server based on that user interaction, and the server responds to those requests with new presentation for the user - fundamentally a synchronous process. This means that the presentation delivered to the user represents a snapshot in time of what is a dynamic system.


JFreeChart 1.0.12 :
Demo
http:​//​www.jfree.org/​jfreechart/​jfreechart-1.0.12-demo.jnlp


The Top 10 Unused Features in Java
5) CORBA
This API would probably win the vote among developers on "which API do you want to remove from Java?".


JDK 6u14 almost ready at b05; Making Java load faster and lighter