Catégories: Java, 5.0 (Tiger), 6 (Mustang), 7 (Dolphin), 8, Closure/Lambda, 9, @Annotations, Android, Exercices, GUI, Java EE, Perfs

Petite astuce suite à une discussion twitter avec Guillaume Laforge concernant une fonctionnalité de l'API tierce JRegex : l'incomplete matching.
Le tout à fini dans un billet de son blog anglophone : Incomplete string regex matching, et j'en profite pour faire de même en français !

Mais d'abord qu'est-ce que l'incomplete matching ? Cela permet simplement de valider partiellement une expression régulière.
Quel intérêt ? Cela permet par exemple de vérifier une saisie en cours sans générer d'erreur (par exemple lorsque la saisie n'est pas terminé).

Par exemple si l'on souhaite faire saisir à l'utilisateur une heure au format habituelle HH:MM, on utilise une expression régulière de la forme suivante : \d\d:\d\d (soit deux blocs de deux chiffres séparés par deux-points).

Une fois la saisie terminée, on peut la vérifier très facilement via notre expression régulière et la méthode matches(). Mais cette méthode renverra une valeur négative pour toutes les saisies intermédiaires, puisqu'elles ne respectent pas le pattern.

Ainsi si je veux saisir "18:15", les chaines intermédiaires "", "1", "18", "18:" et "18:1" ne pourront pas être validées par matches() et génèreront des "faux-négatifs", empêchant toute validation à la volée...

C'est là qu'entre en jeu l'incomplete matching de JRegex. Elle propose une méthode matchesPrefix() permettant de vérifier si la chaine correspond entièrement ou partiellement à l'expression régulière, ce qui permet de ne pas générer de faux-négatif pour toutes les chaines intermédiaires, tout en permettant de détecter une saisie incorrecte au plus tôt...

Pourtant, il n'y a pas besoin de passer par une librairie externe pour faire cela, puisque c'est intégré dans l'API standard depuis Java 5.0...

» Lire la suite!

Il semblerait que la conférence Devoxx nous ait apporté quelques informations concernant les lignes directives de Java 9.

On devrait y retrouver les reified generics et l'unification des primitives.

» Lire la suite!

Comme pour le JDK7, les premiers builds en "Developer Preview" du JDK8 sont disponible depuis quelques temps à l'adresse habituelle : http://jdk8.java.net/download.html

Mais pour l'instant, ces builds s'avèrent peu intéressant pour le commun des développeurs, du fait qu'ils se contentent principalement d'intégrer des correctifs sans "grosses" nouvelles fonctions ou APIs. Mais le projet Lambda a publié une autre "Developer Preview" plus intéressante : elle ne prend pas le dernier build du JDK8 mais elle y intègre le support des expressions lambda et des fonctionnalités qui y sont apparentées : http://jdk8.java.net/lambda/

En clair, c'est ce qu'il vous faut si vous voulez jouer avec les expressions Lambda...

» Lire la suite!

Le groupe de travail du projet Lambda a pris une décision concernant la syntaxe des lambdas de Java SE 8 : Syntax decision (en anglais dans le texte).

C'est donc la syntaxe de C# qui sera reprise (dans les grandes lignes - des détails pourraient encore être modifiés).

Cette syntaxe se décompose en deux parties, séparées par une flèche =>

• La partie gauche comporte la signature de la méthode, avec le nom des différents paramètres (et éventuellement leurs types).
• La partie droite comporte soit une simple expression, soit un bloc de code des plus standard (entre accolades donc)

Exemples :

  x => x + 1 
  (x) => x + 1 
  (int x) => x + 1 
  (int x, int y) => x + y 
  (x, y) => x + y 
  (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); } 
  () => { System.out.println("I am a Runnable"); }

Un choix "par défaut" car aucune autre proposition ne s'est vraiment imposée. Il est donc préférable d'opter pour une syntaxe existante et connue...

Ce n'est pas nouveau, mais je n'ai pas eu le temps d'en parler (il faut dire que ça faisait longtemps que je n'avais plus bloggé).

[edit 14/11/2011] Il semblerait que la flèche double ( => ) ait été abandonné au profit de la flèche simple ( -> )

Les JSRs sont des documents primordiaux du Java Community Process, puisqu'il s'agit des documents de travail qui seront soumis aux votes de la part des membres du-dit JCP.

Longtemps attendu, la JSR de Java 7 est enfin là, et elle n'est pas seule, puisqu'on y retrouve en tout quatre nouvelles JSRs :

• JSR 334: Small Enhancements to the Java™ Programming Language (Le projet Coin pour Java 7)
• JSR 335: Lambda Expressions for the Java™ Programming Language (le projet Lambda pour Java 8)
• JSR 336: Java™ SE 7 Release Contents
• JSR 337: Java™ SE 8 Release Contents

» Lire la suite!

Il y a quelques temps, j'étais tombé sur une série de billet anglophone proposant un SwingWorker amélioré, tel que celui-ci sur le blog de Baptiste Wicht : A better SwingWorker without exception swallowing

Pour rappel cette classe permet d'exécuter des tâches en arrière-plan (via la méthode doInBackground()) afin de ne pas bloquer l'EDT (le thread gérant l'affichage graphique). Et à la fin du traitement, la méthode done() nous permet de mettre à jour l'interface graphique.

Le problème vient du fait que par défaut, les exceptions remontées par la méthode doInBackground() sont "perdu". En fait il faut les récupérer et les traiter explicitement via l'appel de la méthode get() une fois la tâche terminée.

Bien sûr le code correspondant n'est pas bien méchant :

 
@Override 
protected void done() { 
  try { 
    get(); 
  } catch (InterruptedException e) { 
    e.printStackTrace(); 
  } catch (ExecutionException e) { 
    e.getCause().printStackTrace(); 
  } 
}

Mais cela peut se révéler assez lourd et fastidieux... surtout que l'on n'a pas forcément besoin d'implémenter la méthode done().

Pour pallier à cela, la proposition du "BetterSwingWorker" encapsule en fait le vrai SwingWorker, afin d'en proposer une version simplifié.

Un peu trop simplifié à mon goût...

» Lire la suite!

Le langage Java va bientôt fêter ses 15 ans d'existence (sa version initiale datant du 23 janvier 1996). On pourrait même remonter à une vingtaine d'année si on prend en compte sa conception via le Green Project et le langage Oak.

Bien sûr le langage et l'API ont évolués entre temps, tout en respectant au mieux la sacro-sainte règle de la compatibilité ascendante.

Pour rappel il y a deux niveaux de compatibilité ascendante :

• La compatibilité binaire, qui veut qu'un programme compilé avec une version plus ancienne du JDK puisse fonctionner de la même manière sur une JVM plus récente.
• La compatibilité des sources, qui veut qu'un programme compilable avec une version plus ancienne du JDK puisse être compiler sans erreur sur un JDK plus récent, tout en produisant une application qui fonctionne de la même manière.

Tout au long de son évolution, la plateforme Java a toujours fait de son mieux pour respecter ces deux niveaux de compatibilité, même si quelques sacrifices ont pu être consentis, en particulier sur la compatibilités des sources en imposant quelques légères adaptations du code dans certains cas.

Toutefois, ceci n'est pas sans défaut puisque cela implique un grand nombre de limitations. Il est temps de songer à produire une version incompatible, ou tout du moins en partie...

» Lire la suite!

On se dirige donc vers un JDK7 "amoindri" qui sortirait mi-2011, suivi par un JDK8 un an plus tard. En effet Oracle a mis à jour la page des fonctionnalités prévus pour le JDK7, et il semblerait bien que le "plan B" ait été adopté.

On a donc la confirmation des principales nouveautés de Java 7 :

• Le support des langages dynamiques via la JSR 292 (InvokeDynamic).
• L'évolution du langage via le projet Coin, qui est uniquement amputé du support des collections.
• L'API de Concurrence (JSR 166).
• L'API NIO.2 qui apporte entre autre un meilleur accès au système de fichier et des channels asynchrones.
• La standardisation des modifications apportées par Java 6 upadate 10 (LnF Nimbus, JLayer, fenêtres transparentes non-rectangulaire).

» Lire la suite!

Mark Reinhold, qui dirige les travaux sur la plateforme Java chez Oracle, vient de publier sur son blog personnel un billet intéressant quand à la prochaine version de Java : Re-thinking JDK 7.

Comme on s'en doutait un peu, suite au rachat de Sun par Oracle et à l'ajout de nouveaux projets (Lambda, Jigsaw et Coin), le planning originel n'a pas été respecté (Le JDK7 aurait dû sortir demain !) alors que la version actuellement en développement n'a même pas encore atteint le status de "feature-complete", et qu'il manque toujours plusieurs JSRs...

Et dans ces cas là, il y a toujours une bonne et une mauvaise nouvelle...

» Lire la suite!

J'essaye de suivre régulièrement les mailing-lists concernant l'évolution du langage Java. En particulier celle des projets Coin et Lambda, traitant principalement de l'évolution du langage. Il est intéressant de voir à quel point chaque petit détail peut prendre une importance capitale, que ce soit pour des raisons de compatibilités et voir même philosophique...

Bien que ce soit des langages orientées objets, j'ai toujours dit que les C++, Java et C# offrait chacun une approche différente de la POO.

J'avais déjà bien constaté cela il y a quelques années en ce qui concerne les Templates/Generics. Il en est de même aujourd'hui avec la proposition de "Defender Methods" de Java 7 en comparaison des "Extension Methods" de C# 3.0. Car si prime abord cela semble très proche, cela implique en fait des concepts très différents !

Pourtant on part d'une même problématique dans les deux cas : l'ajout de nouvelles méthodes dans une interface existante implique forcément des incompatibilités avec toutes les classes qui l'implémente. Bien sûr dans un petit projet cela n'a pas vraiment d'importance, mais dès qu'on touche à des librairies standard ou très répandus ces changements s'avère impossible !

Pourtant, les interfaces sont utilisées massivement et ne possèdent malheureusement pas toujours une API complète dès leurs créations. La solution consiste alors à utiliser des méthodes static dans une classe utilitaire pour faire le travail, ce qui n'est pas sans défaut et surtout assez éloigné de l'approche "orienté objet"...

» Lire la suite!

En fin d'année dernière, le report de Java 7 laissait envisager l'intégration des closures. Cela a donné naissance au projet Lambda dont l'objectif était de regrouper les différents travaux afin d'en sortir une spécification claire et fonctionnelle quitte à se passer de certain "power-concept".

Il en ressort une proposition d'expressions Lambda relativement allégée vis à vis des multiples et très complètes propositions de closures qui ont pu être proposées par le passé. Mais cela s'accompagne également de nouveaux concepts fort intéressants (Exception Transparency, Method References, Defender Methods).

Voyons voir de quoi il en retourne...

» Lire la suite!

Après le multi-catch/rethrow et depuis la version b105, les derniers builds du JDK 7 intègrent désormais le support des try-with-resources (bloc ARM), ce qui permettra enfin de pouvoir gérer proprement la fermeture des ressources de manière simple et efficace.

Voilà enfin une syntaxe claire et précise pour libérer les ressources proprement et sans erreur...

» Lire la suite!