La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Jenkins : The Definitive Guide
• Java, Kotlin, Ceylon… Que d’îles !

Le coin de la technique

• Springsource: des nouveautés en pagaille
• Java en entretien technique
• Fork/Join: le multithread facile en Java 7
• Sortie de Groovy 1.8.1 et 1.9 beta 1
• Sortie de Google App Engine SDK 1.5.2
• Scala : vers une version « classique » 2.9.1 et une version .Net
• ClojureScript

Actualité éditeurs / SSII

Jenkins : The Definitive Guide

Wakaleo Consulting sort un ebook gratuitement téléchargeable : Jenkins The Definitive Guide. Comme son nom l’indique c’est un guide très complet sur le serveur d’intégration continue, ex-Hudson. Le guide couvre :

• installation et configuration
• sécurisation
• notifications email, IRC, Jabber, SMS et autres
• structuration des jobs
• promotions de bonnes pratiques de développement, via Checkstyle, PMD, FindBugs et autres plugins

Il est bien écrit (en anglais) et mérite d’y jeter un œil, que ce soit pour apprendre, approfondir ou réviser.

Java, Kotlin, Ceylon… Que d’îles !

Ces derniers temps furent très mouvementés dans le monde des langages alternatifs de la JVM.

On sait maintenant que Kotlin n’est plus seulement connu pour être une île perdue en Russie. C’est aussi un nouveau langage proposé par l’équipe de JetBrains censé tourner sur JVM (et encore un de plus, diront certains). Dans les particularités remarquables du langage, nous trouvons :

• les closures et les fonctions d’ordre supérieur,

fun  filter(Iterable items, predicate : fun(T) : boolean) : Iterable { … }
filteredPersons = filter(persons, { it.getAge() >= 18 });

• les fonctions d’extension qui permettent d’ajouter de nouvelles méthodes à des classes,
• le pattern matching,

when (x) {
  is Int => print(x)
  is List => print(x.sum())
  !is Number => print("Not even a number")
  else => print("can't do anything")
}

• La notion de tuple,
• La couche objet habituelle avec des classes finale par défaut,
• La réification des generics permettant de conserver les informations sur le type des arguments d’un type générique au runtime.

Ce langage, vous ne pouvez pas encore l’utiliser car il n’est actuellement disponible qu’à l’état de spécification. Un peu comme Ceylon, en fait, qui est aussi une île. Et d’ailleurs, comme Ceylon, il se veut être une simplification de Scala. Bien sûr, ce nouveau langage à créé le buzz auprès de la communauté des développeurs Java et Scala.

D’ailleurs Gavin King en a profité pour nous donner un rapport d’avancement sur Ceylon. Et bien… Il avance dans le travail de son compilateur. Mais il semble qu’après l’annonce de Kotlin, Gavin s’est malheureusement attiré à lui le buzz et la guerre pseudo-fratricide qui l’accompagne. La situation lui ayant échappé, Gavin a décidé de fermer les commentaires de son post.

Tous ces nouveaux langages ont donné envie à Stephen Colebourne d’écrire un essai (au sens littéraire du terme) sur deux notations utilisées dans la déclaration de type : la déclaration de type classique (comme en Java ou C) et la déclaration de type inversée (comme en Scala ou en Pascal). Stephen réalise sa démonstration au travers de différents langages : Java, Java avec les lambdas expressions en utilisant la proposition strawman, Java avec les lambdas expressions en utilisant la proposition BGGA, Ceylon, Fantom, Gosu, Kotlin et Scala. Nous vous laissons lire l’article et en tirer vos propre conclusions.

Le coin de la technique

Springsource: des nouveautés en pagaille

SpringSource nous fait le plein de nouveautés avec plusieurs sorties:

Spring Data JPA 1.0

Le projet Spring Data vise à faciliter les accès aux bases de données et à gagner encore et toujours en productivité. Au travers de cette API, il est possible d’utiliser aussi bien des bases NoSQL que des bases relationnelles.

L’API est pour l’instant relativement succincte. Il est possible de faire du CRUD et de l’interrogation sans écrire une seule requête grâce à un système de convention de nommage des méthodes.

L’interface de base se nomme Repository. Si votre interface UserRepository étend Repository et définit une méthode findByName(String name), vous pouvez directement l’utiliser pour rechercher vos éléments. Le framework, en fonction de l’environnement que vous avez, construira une requête sur l’entité User en cherchant celle qui a le nom donné en paramètre. Vous définissez le contrat, le framework s’occupe de l’implémentation.

Avec Spring Data JPA 1.0 qui arrive en release finale, il est possible d’utiliser JPA 2.0 au travers de l’abstraction fournie par Spring Data. En plus du CRUD, l’API Criteria de JPA a été portée avec son lot de prédicats. Il est aussi possible d’utiliser des Queries en JPQL et de les associer aux méthodes du Repository pour des implémentations personnalisées de certaines méthodes. Cette première version reste verbeuse, mais Spring assure vouloir réduire le code technique avec la maturité à venir de son nouveau produit.

Spring Data 1.1.0.M2

Spring Data Graph 1.1.0.M2 en version minestrone ajoute de nouvelles fonctionnalités sur la gestion de la base de données orientée graphe Neo4J. En plus de la correction de quelques bugs, l’API supporte maintenant la version 1.4. Tant que nous y sommes, si vous choisissez d’étudier les bases de données graphe, essayez Gephi pour la visualisation et l’exploration des données: c’est visuellement intéressant !

Spring Gemfire 1.1.0.M1

Spring Gemfire est arrivé en version 1.1.0.M1 la semaine dernière.

Les applications propulsées par Spring peuvent déjà se préparer à utiliser la version 6.6 du système de gestion de données réparti de VMWare. Il permet aussi d’utiliser l’abstraction de cache apportée par Spring 3.1. La connexion aux Cache Server de GemFire est rendue disponible (pour la réplication de session HTTP par exemple). Enfin, pour la création de requête, dites au revoir à la génération par chaînes de caractères (avec inclusion des paramètres), et bonjour au templating avec l’utilisation des paramètres variables.

Java en entretien technique

Ah les questions techniques lors d’un recrutement… Quel développeur n’a jamais eu peur de faire face à ces questions alors même qu’il estime bien connaître les méandres de la spec Java. Mais les points flous et d’incompréhension peuvent être nombreux !
Dans un récent post, Peter Lawrey revient sur certains de ces points et nous livre son analyse. Nous ne reparlerons pas (zut, trop tard !) de l’éternel « pass by value VS pass by reference » qui génère toujours beaucoup de commentaires, mais nous pourrons citer par exemple:

• Les modificateurs transient et volatile
• Overriding, overloading: lequel fait quoi ?
• que retourne boolean.class.getSuperclass() ?
• Rappelez moi la définition d’un Java Bean ?

Ainsi que quelques autres questions. Rien de bien nouveau mais une petite piqûre de rappel fait toujours du bien, même aux plus calés.

Tant que nous sommes sur les questions lors d’une entretien, n’oubliez pas que si vous avez à réaliser un bout de code mais pas vraiment l’envie de le faire, il est toujours possible de s’en sortir en utilisant la technique suivante. Dans celle-ci, l’auteur pousse l’exagération jusqu’à la mauvaise fois en demandant des spécification extrêmes sur ce qui lui est demandé de réaliser, une simple copie de fichiers. Notez qu’il est formellement déconseillé d’utiliser cette technique lors d’un entretien chez Xebia

Fork/Join: le multithread facile en Java 7

Alors que le nombre de core par CPU ne cesse de croître, il serait peut être temps que nous utilisions à bon escient les ressources disponibles sur nos serveurs, non ? Java sait depuis toujours faire du multi-threading (encore heureux !) mais il est généralement très compliqué de faire du code multi-threadé efficace et maintenable. Notamment, la synchronisation entre les différent Thread a toujours été source de problèmes. Java 5 puis 6 apportèrent d’importantes innovations, sous la forme du package java.util.concurrent qui fournit:

• les Executors, qui abstraient des pools de threads, ainsi que les Future et Callable
• des queues et Collections thread-safe
• le support de la déclaration de timeout sur les opérations
• des classes implémentant des patterns de synchronisation et d’exclusion mutuelle, comme les Barrier ou Countdown Latch (plus de détails chez O’Reilly)
• le package java.util.concurrent.atomic fournissant des wrappers pour des variables simples permettant des opérations de modification atomiques sur ces variables

Ces apports au langage étaient les bienvenus. Néanmoins, certains type de tâche, et notamment les algorithmes de type « diviser pour régner » ou « map/reduce », requièrent des fonctionnalités qui n’étaient pas offertes .

Julien Ponge nous gratifie d’un article sur Oracle Tech. Network avec l’exemple d’utilisation suivant: on désire compter le nombre d’occurrences d’un mot donné dans des fichiers répartis dans une arborescence du filesystem. Et ca tombe bien, Java 7 fournit justement une implémentation du principe fork/join au travers de la classe abstraite ForkJoinTask et de ses sous-classes. Le filesystem est parcouru grâce à des tâches récursives, mais parallèles. Initialement on a une tâche de type FolderSearchTask qui étend RecursiveTask et crée:

• pour chaque répertoire, une nouvelle tâche FolderSearchTask
• pour chaque document, une DocumentSearchTask qui étend aussi RecursiveTask et compte le nombre d’occurrences du mot recherché

Au final l’algorithme est rendu quasi-trivial avec l’utilisation du nouveau Framework, alors qu’il n’en aurait pas été de même avant Java 7. En effet celui-ci permet de résoudre des problèmes récursifs dont ne ne connaît à priori pas la taille. Dans le cas exposé le comptage débute alors qu’on ne sait pas quelle sera la profondeur du système de fichiers ni le nombre de documents qui sera rencontré.

Une image valant mieux qu’un long discours, voici une illustration assez explicite accompagnant l’article dont nous vous conseillons fortement la lecture:

Sortie de Groovy 1.8.1 et 1.9 beta 1

Le projet Groovy continue à avancer et sort la première version corrective de la branche 1.8 et sa nouvelle beta de la 1.9.

Au menu pour la 1.8.1 :

• plus de 40 bugfixes.
• amélioration du JSonBuilder avec un mode streaming.
• la suite du chantier sur les performances des opérations arithmétiques sur type primitifs.

Pour la 1.9 beta 1 :

• plus de 20 bugfixes
• intégration des nouveautés Java 7 liées au Project Coin

Pour le détail complet, voir l’annonce sur DZone ou les release notes JIRA des versions 1.8.1 et 1.9 beta 1.

Sortie de Google App Engine SDK 1.5.2

Une nouvelle version 1.5.2 du SDK de Google App Engine vient de sortir. Pour rappel, GAE est une plateforme as a service (PaaS) permettant d’héberger dans le cloud des applications web Java et Python ( et prochainement Go, le nouveau langage développé par Google).

En plus de quelques bogues corrigés, cette release apporte quelques nouveautés intéressantes, comme :

• Des paramètres pour ajuster le ratio coût/performance de l’application: Possibilité de définir le nombre minimale d’instances au repos, et la latence minimale d’attente, qui permet d’ajuster le temps minimum qu’une requête doit attendre dans la queue avant d’être traitée par une instance.
• Suppression de la contrainte de créer des index explosés pour « les big entities » et réduction des index personnalisés.
• Les statistiques du Datastore peuvent être regroupées par espace de nom.
• Des informations supplémentaires ont été ajoutés à la page d’administration des Task Queue.
• La limitation de la taille de la Pull Task est passée à 1MB.

Pour plus d’infos, voir la release note.

Force est de constater que la plateforme de Google s’enrichit de release en release. De nombreuses limitations se réduisent voire disparaissent au fur et à mesure. Les possibilités de monitoring, de tuning, et d’administration des backends commencent à bien s’étoffer.

Scala : vers une version « classique » 2.9.1 et une version .Net

Scala va bientôt une version 2.9.1 qui est maintenant disponible en première Release Candidate. Cette version devrait corriger un certain nombre de bug et mettre en place des améliorations en particulier au niveau de l’interpréteur.

Par ailleurs, Miguel Garcia, de l’équipe Scala à l’EPFL, vient d’annoncer une avancée majeure dans l’adaptation du langage de Martin Odersky à la plateforme .NET. Dans ce projet financé par Microsoft, l’adaptation a été rendue possible grâce au projet IKVM.NET. IKVM est un projet mature et toujours en activité qui implémente un framework Java dédié aux plateformes Mono et .NET. On y trouve :

• la JVM compilée pour .NET,
• une implémentation .NET de bibliothèques Java,
• et un convertisseur JAR vers DLL.

Miguel a mis en place un plugin apppelé jdk2ikvm pour le compilateur Scala qui permet de convertir un programme Scala pour JDK en programme Scala pour IKVM et donc .NET. Les développements ne sont actuellement pas complètement stabilisés, mais ils sont utilisables aux dires de l’auteur. Parmi les développements futurs, Miguel prévoit de développer un plugin Scala pour l’IDE Visual Studio et l’adaptation des collections concurrentes aux modèle de gestion de thread de .NET.

ClojureScript

Du côté de Clojure, l’annonce a été faite par Rich Hickey en personne (le créateur de Clojure) lors du Clojure NYC Meetup de juillet. Rich nous a appris la sortie de ClojureScript (voir la vidéo). ClojureScript est une adaptation de Clojure non pas à la plateforme .NET, mais à la plateforme JavaScript. Vous écrivez vos programmes en Clojure et ça vous le compile en JavaScript. La motivation derrière ce projet vient du fait que JavaScript est un langage donnant un accès un scope d’applications de plus en plus large, allant du client au service. Cependant, les développeurs de ClojureScript considèrent que la langage JavaScript possède un certain nombre de faiblesses, notamment pour la construction d’applications robustes qui nécessite de la discipline et le respect de conventions. C’est sur ce point que ClojureScript compte apporter des solutions. Il est possible récupérer une version depuis GitHub.