Pour le bulletin de la semaine 32, je vous propose les sujets suivants :
- le site web Last.fm a basé la communication sur le standard JMS : Java Message Service. L'implémentation utilise le produit open source HornetQ de JBoss.
- Le pattern d'architecture CQRS (Command Query Request Segregation) expliqué par son auteur.
- Le JSR 308 : annotation type. Prévu pour le JDK 7, un certain nombre de vérification faite à la compilation et à l'exécution comme le @Readonly (alias const) que l'on attend depuis 15 ans en Java, le @Notnull, @Notempty, ... Extrait de la documentation.
- L'injection de dépendance : la version du framework Spring et la version de Google Guice : les différences et les similitudes
- Une fiche technique qui résume la technologie de Microsoft pour DotNet : WPF - Windows Presentation Foundation.
- Les NIO 2 du JDK 7 : les notifications du système de fichiers enfin dans le JDK.
- Une présentation des langages disponible pour la JVM : Fantom : un résumé et un petit tour de ce langage pas très connu.
- Trois articles sur les expressions lambda ou closure pour Java 7. L'état des propositions et leur conséquence pour la langage et les API.
Bonne lecture.
L'architecture de Last.fm basée sur le standard JMS (Java Messaging Service) implémenté par HornetQ
Tout le monde connaît Last.fm, le service de streaming et de recommandation de musique. La compagnie a récemment changé son infrastructure de streaming et en a profité pour adopter JBoss HornetQ comme serveur de messaging, au détriment « d'un autre serveur open-source » (mais nous ne saurons pas lequel !). Jeff Mesnil publie sur DZone un article expliquant les raisons de ce changement et la façon dont Last.fm se sert d'HornetQ.
Pour résumer simplement, les messages JMS sont générés principalement par les streamers pour:
- notifier la fin de l'écoute d'un morceau et donc faire mettre à jour la base.
- permettre la déconnexion automatique d'un utilisateur connecté à un flux si un message généré par un second streamerindique qu'il vient de se connecter à un autre flux.
- la persistance a été désactivée. Comme rapporté par nos lecteurs dans les commentaires d'un précédant article celle-ci est connue pour être consommatrice.
- messages déclarés comme pré-acquittés, permettant d'éliminer des accès réseau supplémentaires.
Pour continuer sur HornetQ, notons que la tant attendue interface REST vient d'être annoncée par Bill Burke, son développeur principal, sur le forum du broker. Cette interface n'est pas encore disponible dans une version officielle de HornetQ, mais sa documentation permet d'ores et déjà de se faire une idée. Basée directement sur HTTP, elle évite de forcer l'utilisation d'une quelconque encapsulation (autre qu'applicative) des messages. Et bien sûr, on peut l'utiliser avec n'importe quel langage: REST est interopérable. La documentation spécifique à la création de messages permet de se faire une idée rapidement. Basée surRestEasy, qui fera aussi partie du futur JBoss AS 6, il y a fort à parier que cette interface fera parler d'elle et ouvrira la voie à de nouvelles utilisations du broker.
Axon, une implémentation Java du pattern CQRS
Le Command Query Request Segregation (CQRS) est un pattern architectural qui a été formalisé fin 2009 par Greg Young et Udi Dahan. Il repose sur l'idée de séparer le code métier selon qu'il s'appuie sur des opérations d'écriture (command) ou de consultation de données (query), plutôt que par découpage fonctionnel. Le but recherché ici est d'offrir une grande scalabilité en permettant aux lectures de s'effectuer de manière synchrone dans un cache, tandis que les requêtes d'écritures sont effectuées de manière asynchrone en mettant à jour à la fois le cache et la base de données sous-jacente.
Les développeurs Java disposent d'une implémentation Open Source de ce pattern, il s'agit du framework Axon (anciennement CQRS4J). Le projet est très actif et vient diffuser une version 0.6 dont la maturité mérite de s'y attarder : gestion et persistance des évènements, intégration à Spring et gestion des transactions.
Ce framework reste modeste pour l'instant et ne couvre qu'un nombre limité d'environnements techniques mais à défaut de répondre à votre besoin il constituera un exemple d'implémentation intéressant à étudier.
Clarified CQRS
After listening how the community has interpreted Command-Query Responsibility Segregation I think that the time has come for some clarification. Some have been tying it together to Event Sourcing. Most have been overlaying their previous layered architecture assumptions on it. Here I hope to identify CQRS itself, and describe in which places it can connect to other patterns.
Type Annotations Specification (JSR 308)
JSR 308 extends Java's annotation system so that annotations may appear on nearly any use of a type. (By contrast, Java SE 6 permits annotations only on declarations; JSR 308 is backward-compatible and continues to permit those annotations.) Such a generalization removes limitations of Java's annotation system, and it enables new uses of annotations. This proposal also notes a few other possible extensions to annotations.
Examples of type qualifiers
The ability to place annotations on arbitrary occurrences of a type improves the expressiveness of annotations, which
has many benefits for Java programmers. Here we mention just one use that is enabled by extended annotations, namely
the creation of type qualifiers. (Figure 3 gives an example of the use of type qualifiers.)
1 @DefaultQualifier("NonNull")
2 class DAG {
3
4 Set<Edge> edges;
5
6 // ...
7
8 List<Vertex> getNeighbors(@Interned @Readonly Vertex v) @Readonly {
9 List<Vertex> neighbors = new LinkedList<Vertex>();
10 for (Edge e : edges)
11 if (e.from() == v)
12 neighbors.add(e.to());
13 return neighbors;
14 }
15 }
The DAG class, which represents a directed acyclic graph, illustrates how type qualifiers might be written by a programmer and checked by a type-checking plug-in in order to detect or prevent errors.
(1) The @DefaultQualifier("NonNull") annotation indicates that no reference in the DAG class may be null (unless otherwise annotated). It is equivalent to writing as "@NonNull Set<@NonNull Edge>edges;", for example. This guarantees that the uses of edges, cannot cause a null pointer exception. Similarly, the (implicit) @NonNull return type of getNeighbors() enables its clients to depend on the fact that it will always return a List, even if v has no neighbors.
(2) The two @Readonly annotations on method getNeighbors guarantee to clients that the method does not modify, respectively, its Vertex argument or its DAG receiver (including its edges set or any edge in that set).
The lack of a @Readonly annotation on the return value indicates that clients are free to modify the returned List.
(3) The @Interned annotation (along with an @Interned annotation on the return type in the
declaration of Edge.from(), not shown) indicates that the use of object equality (==) is a valid optimization. In the absence of such annotations, use of the equals method is preferred to ==.
Spring vs. Guice: The Clash of the IOC Containers
Spring and Google Guice are two powerful dependency injection frameworks in use today. Both frameworks fully embrace the concepts of dependency injection, but each has its own way of implementing them. Although Spring provides many benefits, it was created in a pre-Java-5 world. The Guice framework takes DI to the next level, leveraging the full power of Java typing, especially annotations and generics. Discover how Guice can make your code more modular, easier to write, and less error prone to maintain.
- Living in XML Hell
- Eliminating reliance on String identifiers
- Preferring Constructor Injection
- Nullifying NullPointerExceptions
- Intruding into the domain
- Replacing Spring verbosity with Guicey compactness
- Considering other advantages
Windows Presentation Foundation
Windows Presentation Foundation or WPF is a next generation UI framework for creating desktop applications on the Windows Platform. It brings together a number of features and concepts such as a declarative language for constructing interfaces, rich media support, scalable vector graphics, timeline-based animations, sophisticated data binding, and much more.
WPF is a very large topic. The intent of this Refcard is to help you understand the basics of WPF. After we're done you should be able to look at the source of a WPF application and understand what you are seeing. However, in order to effectively use WPF, you will need to continue to learn more though additional and more extensive resources.
Introducing NIO.2 (JSR 203) Part 5: Watch Service and Change Notification
For a long time Java developers used in-house developed solutions to monitor the file system for changes. Some developed general purpose libraries to ease the task for others who deal with the same requirement. Commercial and free/ open source libraries like notify.sourceforge.net, jpathwatch.wordpress.com and www.teamdev.com/jxfilewatcher among others. Java 7 comes with NIO.2 or JSR 203 which provides a native file system watch service.
The Next Big JVM Language talk JavaOne
I'm talking at JavaOne 2010 on the subject of the "Next Big JVM language". I suspect that it might cause some controversey!
Talk
Before writing the talk, I wanted to get some feedback from the community. So, I've got some basic topics and questions I'm looking for feedback on.
1) What makes a language big and popular?
Lots of people have drawn up lists - Steve Yegge has one (take a look!). But what criteria do you believe make a language big and popular? Static or dynamic? Fast or just fast enough? Lots of features or few? Simple or complex? Does syntax matter? etc. etc.
2) What might be different between a big JVM language and a big language in general (without the JVM restriction)?
Dot NET has several new languages, but they can't be considered. However, if you've seen an interesting idea then thats interesting here.
3) Is it important to reuse existing Java libraries?
Java has a big ecosystem. How important is reusing all those libraries. Or would a fresh start with a new higher quality (less cruft) core library be preferred.
4) What languages should I consider?
I've got Groovy, Scala, Fantom and Clojure on the list, but what else? I'd love to see blog posts by language authors tackling the question of why their language matches the session title.
5) If its none of the above, why not? What are you looking for?
While a random wish list of features is interesting, remember that this is about the next big JVM language. Does your idea fit that?
6) Can Java reinvent itself?
What about java itself - could a reinvigorated Java retain its crown.
Summary
Feedback is definitely wanted, by comment, email or new blog posts. Its a broad topic, but the more feedback the better (or more controversial) the talk will be! (And I'll be starting writing this weekend...
Why Fantom
Overview
Do we really need another programming language? Well obviously we thought so, or we wouldn't have built Fantom! Fantom is designed as a practical programming language to make it easy and fun to get real work done. It is not an academic language to explore bleeding edge
theories, but based on solid real world experience. During its design we set out to solve what we perceived were some real problems with Java and C#. Our background is heavily Java, but many of Java's problems are shared by C# and .NET also.
Fantom Tour
Hello World
We start our whirlwind tour of Fantom's features, with the quintessential hello world:
class HelloWorld {
static Void main() {
echo("hello world")
}
}
Lambdas in Java Preview - Part 1: The Basics
As announced at Devoxx last year, closures (or better lambda expressions) will (probably) be added to JDK7. The team of project lambda has checked in initial parts of the implementation into the OpenJDK repositories. This is the first part (see part 2) in a series of blog posts giving some practical examples of lambdas, how functional programming in Java could look like and how lambdas could affect some of the well known libraries in Java land. Although most of the examples will work with the current prototype implementation, keep in mind, that this is just a preview, which is based on the straw-man proposal, the specification draft, the discussions on the project lambda mailing list and the current state of the prototype. There might/will be both semantical and syntactical differences to the final version of lambdas in Java. Also some details are left out, e.g. exception handling will probably be out of scope.
Lambdas in Java Preview - Part 2: Functional Java
This is the second part in a series of blog posts (read part I) giving some practical examples of lambdas, how functional programming in Java could look like and how lambdas could affect some of the well known libraries in Java land. This part focusses on general functional programming techniques, which will be available through the addition of lambdas. Functional programming (although I still wouldn't consider Java a functional programming language) will make Java code more concise, more expressive and more readable in certain kinds of problem situations.
Lambdas in Java Preview - Part 3: Collections API
This is the third part in a series of blog posts (read part 1, part 2 and part 4) giving some practical examples of lambdas, how functional programming in Java could look like and how lambdas could affect some of the well known libraries in Java land. In this part I'll focus on how the addition of lambdas could affect one of the most used standard APIs - the Collections API.
Lambdas in Java Preview - Part 4: Proposal UpdateThis is the fourth part in a series of blog posts (read part 1, part 2 and part 3) giving some practical examples of lambdas, how functional programming in Java could look like and how lambdas could affect some of the well known libraries in Java land. This part describes shortly the changes of a new proposal, that has been published while writing this series, and how it changes some of the examples in this series.
