Projet Coin : Les nouveautés dévoilées à la Java Community Conference d'Anvers

**Baptiste Wicht** · 03/09/2009, 16h37

Mise à jour du 01/12/09

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

Envoyé par adiGuba

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** · 03/09/2009, 16h42

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.

**adiGuba** · 03/09/2009, 17h09

Envoyé par Baptiste Wicht

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

Envoyé par Baptiste Wicht

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++

**hibour** · 03/09/2009, 17h05

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.

**Baptiste Wicht** · 03/09/2009, 17h09

Envoyé par hibour

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** · 03/09/2009, 17h17

Envoyé par Baptiste Wicht

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** · 03/09/2009, 17h50

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, ...).

**adiGuba** · 03/09/2009, 20h48

Envoyé par Uther

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).

Envoyé par Uther

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

Envoyé par Uther

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é...

Envoyé par Uther

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...

Envoyé par Uther

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++

**benwit** · 03/09/2009, 17h54

Envoyé par hibour

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** · 03/09/2009, 18h01

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

**Uther** · 03/09/2009, 18h36

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** · 03/09/2009, 19h30

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

**adiGuba** · 03/09/2009, 21h20

Envoyé par 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.

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++

**fanprog1** · 27/11/2009, 12h49

Envoyé par Uther

Je rajoute que je suis également déçu de ne pas voir le catch multiple, et le rethrow.

Tout à fait d'accord avec toi, j'aurai bien voulu egalement que cette fonctionnalité soit ajoutée....

**professeur shadoko** · 12/10/2009, 13h40

j'ai pas suivi le film en ce qui concerne les "super-packages" (et pourtant ça m'intéresse bigrement

). ça devrait concerner la syntaxe de quelques directives de compilation non?

Oops : edit: je suis idiot je n'avais pas lu l'ensemble de la discussion sur le portée du projet Coin ... milexcuses.

**adiGuba** · 12/10/2009, 14h02

@_skip : oui le report des améliorations des exceptions est préjudiciable

Surtout que si je ne me trompe pas, il y avait également des propositions pour remonter silencieusement un checked-exception !

@professeur shadoko : Que veux-tu dire par "directive de compilation" exactement ?
Sinon au niveau des "super-packages" et de "Java Module System" ca a beaucoup bougé et les deux concept ont été regroupé. De même on parle d'intégration avec http://fr.wikipedia.org/wiki/OSGi

C'est assez complexe et je n'ai plus trop suivi tout cela... mais on devrait normalement avoir une nouvelle visibilité (module).

a++

**professeur shadoko** · 12/10/2009, 14h17

Envoyé par adiGuba

[B]
@professeur shadoko : Que veux-tu dire par "directive de compilation" exactement ?

des choses comme :

Code :

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

1
2
3
 
  package com.mapetiteentreprise.bizness ;
  import org.truc.Machinchose ;

ne sont pas, à mon sens, des instructions mais des directives de compilation. (mais bon ça m'est venu sans réflechir et à ce stade c'est des distinctions oiseuses)

**adiGuba** · 12/10/2009, 14h53

Ah ok

On devrais avoir l'instruction module qui permettra de définir le module d'un package :

Code :

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

module nom.du.module;

Et ce même mot-clef module devrait pouvoir être utilisé comme visibilité pour les classes/méthodes/attributs, ce qui lui confèrerait alors une visibilité restreinte au module.

Après cela concerne beaucoup plus de chose (versionning, dépendances, etc.), mais ca a beaucoup bougé et je n'ai pas trop suivi l'affaire...

a++

**Gordon Fowler** · 25/11/2009, 10h06

Mise à jour du 25/11/09

Encore plus de nouvelles fonctionnalités de 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.

**pseudocode** · 25/11/2009, 12h14

Envoyé par Gordon Fowler

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

Est-ce à dire que le package "java.dyn" est abandonné (ce qui ne serait pas un mal, de mon point de vue) ?