Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Avenir de Java : Amélioration de la gestion des exceptions relancée pour Java 7
(multi-catch et rethrow), par Frédéric Martini

Le , par Baptiste Wicht

0PARTAGES

1  0 
Mise à jour du 01/12/09

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

Citation Envoyé par adiGuba Voir le message
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
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Baptiste Wicht
Expert éminent sénior https://www.developpez.com
Le 03/09/2009 à 16:42
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.
0  0 
Avatar de hibour
Membre averti https://www.developpez.com
Le 03/09/2009 à 17:05
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
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.
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 03/09/2009 à 17:09
Citation Envoyé par Baptiste Wicht Voir le message
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

Citation Envoyé par Baptiste Wicht Voir le message
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++
0  0 
Avatar de Baptiste Wicht
Expert éminent sénior https://www.developpez.com
Le 03/09/2009 à 17:09
Citation Envoyé par hibour Voir le message
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.
0  0 
Avatar de hibour
Membre averti https://www.developpez.com
Le 03/09/2009 à 17:17
Citation Envoyé par Baptiste Wicht Voir le message
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
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/09/2009 à 17:50
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, ...).
0  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 03/09/2009 à 17:54
Citation Envoyé par hibour Voir le message

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.
0  0 
Avatar de hibour
Membre averti https://www.developpez.com
Le 03/09/2009 à 18:01
Le Set n'est pas une collection ordonnée
La syntaxe d'initialisation des Map je n'aime pas trop
0  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/09/2009 à 18:36
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.
0  0 
Avatar de vimtonic
Membre à l'essai https://www.developpez.com
Le 03/09/2009 à 19:30
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
0  0