Pour le bulletin de la semaine 20, je vous propose les articles suivants :
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:
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:
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.
- 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.
Aucun commentaire:
Enregistrer un commentaire