Discussion :

[Baptiste Wicht]

Mise à jour du 01/12/09

Gestion des exceptions améliorée (multi-catch et rethrow)

Ca tombe bien le multi-catch et le rethrow sont réexaminés pour intégration dans Java 7 (apparemment le rethrow faciliterait l'implémentation des blocs ARM) : http://blog.developpez.com/adiguba/p...catch-rethrow/


J'ai vu passer des messages dans ce sens dans la mailling-list du projet Coin, où il évoquait la possibilité d'intégré cela au for étendus, voir de créer un "try-for" qui fermerait l'Iterator à la fin du traitement.

A suivre donc...


a++

Mise à jour du 25/11/09

Encore plus de nouvelles fonctionnalités dans Java 7
Elles viennent d'être dévoilées lors de la Java Community Conference d'Anvers

La conférence Devoxx (également baptisée la Java Community Conference) s'est achevée à Anvers la semaine dernière.
Parmi les participants on comptait IBM, Oracle et Adobe.

Un des sujets abordés les plus "chauds" a évidemment été les futures fonctionnalités de Java 7.

Et on y a appris quelques nouveautés.

Citons (en vo) l'arrivée du :

* Language support for collections
* Automatic Resource Management
* Improved Type Inference for Generic Instance Creation (diamond)
* Strings in switch
* Binary literals
* Simplified Varargs Method Invocation

On pourra également utiliser les caractères spéciaux dans les nombres :

Par exemple 123456789 pourra s'écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
123_456_789

Ce qui faciliter l'interaction avec les langages dynamiques qui sont plus souples dans la définition des nombres.

Plus de détails sur ces "nouvelles nouveautés" ici même dans le courant de la semaine.

Pour mémoire le Java Development Kit Software est prévu pour Septembre 2010. Le premier Build de la 6ème Milestones (la 77ème donc) devrait sortir elle le 3 Décembre prochain.

Source : Devoxx et la page officielle du projet de Java 7

Et vous ? :

Que pensez-vous de ces nouveautés introduites par Java 7 ?

Mise à jour de Gordon Fowler.



Septembre 2009


Bonjour,

adiGuba vient de présenter les modificaitons finales du langage Java 7 introduites par le projet Coin.

Vous pouvez avoir accès à cette liste sur son blog.

Qu'en pensez-vous ?

[Baptiste Wicht]

Personnellement, j'adore la déclaration en losange, la déclaration des collections et le nouveau switch, mais par contre, je suis pas trop pour la nouvelle façon de gérer les ressources...

Par ailleurs, je trouve super la partie "dynamique", c'est vraiment un grand pas en avant

Surtout si les performances sont au rendez-vous de la partie MethodHandle.

[hibour]

Je n'aime pas trop l'initialisation des liste avec un [], on se rapproche du langage PERL si je ne me trompe pas.
Il fallait laisser les {} pour l'initialisation de toutes les collections.
Une liste n'est qu'un tableau a la fin surtout avec l'introduction de l'indexation list[i]. Il y a une incohérence je trouve.
Les sucres syntaxiques je trouve que c'était inutil, qui va s'amuser à nommer une variable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String #"Hello the world" = "Hello the worl";

Le plus important c'est l'invocation dynamique j'y pensai depuis un temps à tel point que je voulai basculer vers groovy, ;-) pas mal en tout cas, j'espère question performance c'est mieux que son équivalent en réflection.

[adiGuba]

je suis pas trop pour la nouvelle façon de gérer les ressources...

L'avantage avec ARM, c'est qu'on a une syntaxe propre et clair pour la fermeture des ressources. C'est comme çà et puis c'est tout !

Alors qu'à l'inverse actuellement avec les try/finally il est possible de faire cela de multiples manières... et bien souvent cela se révèle en fait incorrect

Surtout si les performances sont au rendez-vous de la partie MethodHandle.

Par curiosité j'ai essayé de faire des tests de performances (avec le build 66), mais cela se finit toujours par un beau plantage

Je suis en train de récupérer le dernier build (70) pour voir si ca passe mieux...


a++

[Baptiste Wicht]

les sucre syntaxique je trouve que c'était inutil, qui va s'amuser à nommer une variable "Hell the world"!!

Personne et ce n'est justement pas le but. Le but est de pouvoir accéder à des variables/méthodes déclarées via un langage dynamique qui lui permet d'utiliser des caractères spéciaux dans ses déclarations.

Ce n'est aucunement à utiliser dans un programme Java de base, c'est réservé à une infime partie de programmes.

[hibour]

Personne et ce n'est justement pas le but. Le but est de pouvoir accéder à des variables/méthodes déclarées via un langage dynamique qui lui permet d'utiliser des caractères spéciaux dans ses déclarations.

Autant pour moi
La gestion auto des ressource je trouve que c'est intéréssant, Il ont pas copié ca de C# par hasard

[Uther]

Mes avis:

• Syntaxe en losange:
  Je suis pour le principe, mais je ne comprends pas pourquoi ajouter une nouvelle syntaxe pour cela.
  Vu que les type n'existent pas au runtime, Map<Integer, List<String>> map= new HashMap(); me parait tout a fait correct, plus simple et ne requiert rien de nouveau.
  
  
• Simplified Varargs Method Invocation
  C'est une évolution logique, mais en effet l'impact est plus que limité
  
  
• Amélioration des valeurs numériques
  De très bonnes évolutions.
  J'ai noté une petite erreur dans l'article qui parle de suffixes pour '0x' et '0' au lieu de préfixes.
  D'ailleurs à propos de suffixes, il me semble avoir lu que des suffixes seraient disponibles pour tous les types primitifs java. Actuellement seul les suffixes 'L' pour les long et 'F' pour les float sont gérés.
  Est-ce un oubli ou cette amélioration a été annulée?
  
  
• Support syntaxique des Collections
  La j'ai un avis plutôt partagé.
  Autant ca ajoute trop de nouvelles syntaxes a mon gout, autant c'est vrai que que ca risque d'être très pratique dans certain cas.
  
  
• Switch sur des chaines de caractères
  Une bonne petite évolution.
  Ça ne changera pas le monde, mais c'est toujours ça de pris
  
  
• Gestion automatique des ressources
  Très bonne évolution.
  Personnellement j'aurais préféré une syntaxe du type:
  with{ ... }
  try { ... }
  catch{ ... }
  car le try (...) devient moche si on a à déclarer plusieurs ressources dedans.
  Mais au final, ça ne change pas grand chose.
  Est ce que se sera réservé à quelque classes de l'API standard ou est-ce qu'il y aura moyen de permettra à n'importe qu'elle classe d'en profiter?
  
  
• Support de la JSR 292 dans le langage
  Là je suis nettement moins enthousiaste. Autant je comprend tout à fait la nécessité de invokedynamic pour des langages autre que java. Autant je n'aime pas vraiment voir ça arriver en Java.
  Je n'aimais déjà pas beaucoup l'introspection ...
  
• Identifiant "exotique"
  La encore, c'est une évolution nécessaire, mais vu le peu d'utilité de la chose, je pense qu'il aurait mieux valu ne pas utiliser le caractère # pour ça.
  Il pourrait servir à de futures évolutions de langages bien plus utiles (comme les closures pour le JDK8 peut-être, ...).

[benwit]

Il fallait laisser les {} pour l'initialisation de toutes les collections.

C'est vrai. Pourquoi un cas particulier ?
Uniquement pour différencier les Set des List ?
Selon moi, ils n'avaient qu'à pas faire de raccourcis pour les Set (Les List sont plus utilisées à mon avis)


Pour le diamond, je suis du même avis qu'Uther.

[hibour]

Le Set n'est pas une collection ordonnée
La syntaxe d'initialisation des Map je n'aime pas trop

[Uther]

Je rajoute que je suis également déçu de ne pas voir le catch multiple, et le rethrow.
D'autant plus que j'ai du mal à comprendre la justification avancée: trop complexe pour le moment parce que cela toucherait au fonctionnement des types en Java.

[vimtonic]

J'apprécie tout particulièrement les nouvelles syntaxes pour les collections. Qu'elles soient en [] ou {}, elles vont bien faciliter l'algorithmie. Et puis ça fait passer l'absence des closures

[tchize_]

Pas de catch multiples -> dommage, je le voulais vraiment celui là, j'ai écris des blocs de catch kilométriques
Pas de rethrow non plus du coup (Heureusement, on peux encore simuler avec de l'aop :p)
Syntaxe des collection. Autant j'apprécie, autant je sens qu'on glisse tout doucement vers une redéfinition des opérateurs mais limitée au compile-time.

au fait, on avais pas aussi parlé de permettre l'initialisation facile de toutes classe via ce genre de syntaxe à un moment donné?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse c = new MaClasse{champ1:"valeur1", champ2:69}

[tchize_]

je rajoute, pour les noms exotiques. Je trouvais déjà fun de pouvoir créer des noms de variables dans une langue prenant l'écriture droite -> gauche pour faire chier mes collègues, mais là ca va être bonheure intégral Fini les noms de variable en hébreux, bienvenu les variables numériques

[adiGuba]

Vu que les type n'existent pas au runtime, Map<Integer, List<String>> map= new HashMap(); me parait tout a fait correct, plus simple et ne requiert rien de nouveau.

Je pense que c'est pour faciliter une future "réification" des Generics, car dans ce cas là il y aurait une différence en new HashMap() (aucun paramétrage) et new HashMap<>() (paramétrage à déterminer selon le contexte).

J'ai noté une petite erreur dans l'article qui parle de suffixes pour '0x' et '0' au lieu de préfixes.

En effet c'est corrigé merci

D'ailleurs à propos de suffixes, il me semble avoir lu que des suffixes seraient disponibles pour tous les types primitifs java. Actuellement seul les suffixes 'L' pour les long et 'F' pour les float sont gérés.
Est-ce un oubli ou cette amélioration a été annulée?

Aucune idée : la proposition sur les numériques n'existe pas en fait, et correspondra à un regroupement de plusieurs proposition (dont au minimum les deux que j'ai cité).
Pour le reste c'est encore assez flou donc je n'en ai pas parlé...

Gestion automatique des ressources
(...)
Est ce que se sera réservé à quelque classes de l'API standard ou est-ce qu'il y aura moyen de permettra à n'importe qu'elle classe d'en profiter?

Une nouvelle interface Disposable<X> viendra marquer les types qui pourront être utilisé dans ce bloc. L'interface Closeable de Java 5.0 n'a pas pu être utilisé à cause de l'IOException, donc Disposeable<X> gère une exception via les Generics :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public interface Disposable<X extends Throwable> {
    public void close() throws E;
}

Bien sûr Closeable sera adapté en conséquence :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public interface Closeable extends Disposable<IOException> {
    public void close() throws IOException;
}

Et les autres types de ressources qui ne pouvaient pas implémenter Closeable implémenteront Disposeable (comme dans JDBC par exemple), et bien sûr on pourra implémenter cette interface si besoin (tout comme l'Iterable du for-each)


Au passage il y a même des discussions tardive pour intégrer également cela dans le for-each dans le cas d'Iterator-Disposeable...

Support de la JSR 292 dans le langage
Là je suis nettement moins enthousiaste. Autant je comprend tout à fait la nécessité de invokedynamic pour des langages autre que java. Autant je n'aime pas vraiment voir ça arriver en Java.

L'intérêt étant surtout de pouvoir développer un moteur de langage de script en pur-Java
C'est sûr qu'au niveau du développeur Java ce n'est pas vraiment très utile... quoique les MethodHandle pourront avantageusement remplacer la réflection



a++

[adiGuba]

Je rajoute que je suis également déçu de ne pas voir le catch multiple, et le rethrow.
D'autant plus que j'ai du mal à comprendre la justification avancée: trop complexe pour le moment parce que cela toucherait au fonctionnement des types en Java.

Je pense qu'ils ne veulent pas s'attaquer aux modifications du bytecode. En effet aucune des fonctionnalités présenté ici n'impactent le bytecode... mis à part pour l'invocation dynamique (mais pour cette dernière la modification du bytecode a été mise en place via la JSR 292 et non pas par le projet Coin).

a++

[tchize_]

le catch multiple n'aurai pas, je pense, nécessité de modif du bytecode. Dans le pire des cas, en cas de catch de N exception, le copilo aurait pu simuler une duplication du code java dans plusieurs catchs séparés :/

[Uther]

au fait, on avais pas aussi parlé de permettre l'initialisation facile de toutes classe via ce genre de syntaxe à un moment donné?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse c = new MaClasse{champ1:"valeur1", champ2:69}

Ca ne me dit rien. Par contre, il y a eu une proposition qui permettait de faire ça en faisant retourner implicitement this aux fonctions de type void.
Ainsi on aurait pu faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse c = new MaClasse().setChamp1("valeur1").setChamp2(69)

Cette proposition me plaisait a moité. Elle était certes pratique, mais se retrouver avec un void qui n'est pas vraiment vide me choque un peu.
De toute façon elle n'a pas été retenue

le catch multiple n'aurai pas, je pense, nécessité de modif du bytecode. Dans le pire des cas, en cas de catch de N exception, le copilo aurait pu simuler une duplication du code java dans plusieurs catchs séparés :/

En effet c'est ce que je voulais dire par mon "".
Pour le rethrow, j'ai de mal a bien me figurer l'impact, mais pour le catch multiple, l'évolution me parait triviale.

[tchize_]

Pour le rethrow, j'ai de mal a bien me figurer l'impact, mais pour le catch multiple, l'évolution me parait triviale.

Pour le rethrow, je pense pas qu'il y aie d'inpact non plus. Faire un rethrow X c'est finalemenr dire au compilo "ce catch n'arrete pas l'exception concerée -> un déclaration "throws" est obligatoire ou un catch à un niveau supérieur. Et finalement faire rethrow X n'est qu'un raccourci de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (ex de type machin)
   throw (type machin)ex
else if  ...

[adiGuba]

Oui c'est vrai j'ai jeté un coup d'œil aux dernières propositions et cela parlait bien de sucre syntaxique...

[joseph_p]

en tout cas, merci adiGuba pour ce billet bien instructif