Discussion :

[tralloc]

D'accord on va dire que je suis bête,
mais je n'ai pas bien compris comment va fonctionner le try

Ce qu'on déclare, c'est les objets sur lesquels il peut y avoir une exception ?

Y aura-t-il quand même la possibilité d'avoir un catch ?
Merci de m'éclairer.
/////////////////////////////////////////////////
Le reste ça va j'ai compris...

Il y a des choses que j'aime bien d'autre pas. Ce qui me plait c'est le fait d'accéder aux indexes d'une collection comme à ceux d'un tableau, le switch qui comprend les string, les types numériques.

La syntaxe en losange me paraît non seulement inutile, mais apporte un certain flou. Je n'aime pas trop, mais on n'est pas obligé de l'utiliser ce n'est donc pas très grave.

Mais bon moi ce que j'aurais attendu et qui finalement n'est pas au rendez vous c'est une gestion à la C# des ascesseurs, avec possibilité donc de bloquer l'écriture.
Je pense que ça aurait bien simplifié le langage.

[adiGuba]

D'accord on va dire que je suis bête,
mais je n'ai pas bien compris comment va fonctionner le try

Ce qu'on déclare, c'est les objets sur lesquels il peut y avoir une exception ?

Non : ce sont les objets qui doivent être explicitement fermé à la fin du traitement, car ils ne sont pas gérer par le GC. Comme par exemple les InputStream, OutputStream, Reader, Writer, Channel, Socket, Connection, Statement, ResultSet...

Y aura-t-il quand même la possibilité d'avoir un catch ?

Oui... mais j'ignore si on pourra l'utiliser directement sur ce try ou via un nouveau bloc try/catch...

a++

[tralloc]

Oui... mais j'ignore si on pourra l'utiliser directement sur ce try ou via un nouveau bloc try/catch...

D'accord, me voilà moins bête.
J'imagine en effet que la portée de ces variables devrait être limitée au bloc try. Par contre il est peut-être inutile d'utiliser un autre try/catch, car les ressources seront fermées automatiquement, et si l'on souhaite traiter notre exception correctement pas besoin d'utiliser les ressources déclarées dans la parenthèse du try.
Finalement je pense que c'est une très bonne évolution qui nous simplifiera bien la vie

[r1-1024]

Youps youps ...
L'invocation dynamique c'est le seul truc que je retiendrai. Pour le reste, une bonne completion / indentation fait l'affaire.

Pour moi ces modifs sont assez médiocres. Sun nous dit :
"Ba les gars on a pas trop bossé sur java depuis 1.5 mais vous en faites pas on pense a vous. Sur ce voilà quelques cahouettes pour patienter."

On pourrait attendre mieux des créateurs d'un des meilleurs langage qui soit.

Si j'ai froissé qq'1, je m'en excuse.

[adiGuba]

Je viens de relire la proposition, et les blocs catch/finally pourront bien être utilisé directement, mais ils seront en fait remonter d'un niveau.

En clair :

Code :

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

1
2
3
4
5
6
7
try (InputStream in = new FileInputStream("file")) {
	// code
} catch (IOException e) {
	// traitement des exceptions
} finally {
	// ???
}

Sera équivalent à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
try {
	try (InputStream in = new FileInputStream("file")) {
		// code
	}
} catch (IOException e) {
	// traitement des exceptions
} finally {
	// ???
}

a++


[edit] r1-1024 : tu es un peu hors-sujet : le projet Coin ne concerne que des modifications mineures du langage, et est loin de couvrir toutes les évolutions de la plateforme

[r1-1024]

ya ya. C un p'tit coup de geul qui fait plaisir.
J'en ai marre que Sun claque autant de fric dans solaris et de trop nous oublier.

[r1-1024]

Ya une interface à implémenter pour libérer les ressources ?
par ex :

Code :

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

1
2
3
4
5
6
7
8
 
try
(
MaClasseQuiOuvre25Files pull=new ....
)
{
XXXX
}

Equivalent à

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
MaClasseQuiOuvre25Files pull=null;
try
{
pull=new ...
XXXX
}
finally
{
  if(pull!=null)
    pull.invokeBozo();
}

ici l'interface serait invokeBozo

[tchize_]

Pour moi ces modifs sont assez médiocres.

Je me serais aussi attendu a plus au vu des propositions

Je viens de relire la proposition, et les blocs catch/finally pourront bien être utilisé directement, mais ils seront en fait remonter d'un niveau.
Sera équivalent à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
try {
	try (InputStream in = new FileInputStream("file")) {
		// code
	}
} catch (IOException e) {
	// traitement des exceptions
} finally {
	// ???
}

Donc la finalisation se fera avant d'entrer dans les catch/finally?

le projet Coin ne concerne que des modifications mineures du langage, et est loin de couvrir toutes les évolutions de la plateforme

Ha ben je pensais que ca couvrait tout aussi tiens

[adiGuba]

Donc la finalisation se fera avant d'entrer dans les catch/finally?

Oui : cela permet de catcher toutes les exceptions, y compris celles qui pourraient éventuellement se produire lors de la fermeture.

[edit] C'est d'ailleurs ce qui est conseillé dans la FAQ sur la libération des ressources

De la même manière, si l'on souhaite gérer les exceptions dans la méthode, il est préférable d'utiliser un bloc try/catch en plus du bloc try/finally

Ha ben je pensais que ca couvrait tout aussi tiens

Et non
D'ailleurs j'ai un peu élargie la partie sur la JSR 292 pour une meilleure compréhension (certaines parties comme les MethodHandles était déjà prévu avant le projet Coin).

De même on devrait normalement avoir une nouvelle visibilité "module" via la JSR 277 (Java Module System).


a++

[benwit]

Faut-il comprendre que les modifications retenues dans le projet Coin seront dans Java 7 mais qu'il y aura également dans Java 7 d'autres modifications ?

Y a t'il une date de sortie de prévue ?

[adiGuba]

Faut-il comprendre que les modifications retenues dans le projet Coin seront dans Java 7

Oui : une JSR devrait être créée pour valider tout cela.

mais qu'il y aura également dans Java 7 d'autres modifications ?

Au niveau du langage on devrait avoir au moins deux autres modifications :

• La gestion des modules qui permettra une nouvelle visibilité et la gestion des dépendances.
• Les annotations qui pourront désormais être utilisés partout et non pas seulement à quelques emplacements.

Y a t'il une date de sortie de prévue ?

Pas à ma connaissance... mais tout semble s'activer ces derniers temps !

a++

[Baptiste Wicht]

Pour ceux qui veulent débattre des nouveautés de Java 7 dans son ensemble, de ce qu'ils auraient aimé avoir, etc...

C'est ici que ça se passe : JDK 7 : Que pensez-vous des nouveautés et qu'auriez-vous aimé avoir de nouveau ?

[adiGuba]

Pour en revenir à ARM et la libération des ressources. De prime abord cela peut paraitre anodin car les différences semblent minimes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// Nouveau code :
try (Ressource res = ...) {
    // CODE
}
 
 
// Ancien code :
Ressource res = ...;
try {
    // CODE
} finally {
    res.close();
}

Mais en fait cela apporte beaucoup d'avantage :

• On peut gérer simplement et de la même manière de multiples ressources, là où il aurait fallu imbriquer plusieurs niveaux de try/finally avec l'ancienne méthode. La différence est déjà plus sensible :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  // Nouveau code :
  try (Ressource res = ...;
        Ressource res2 = ...;
        Ressource res3 = ...) {
      // CODE
  }
   
   
  // Ancien code :
  Ressource res = ...;
  try {
      Ressource res2 = ...;
      try {
           Ressource res3 = ...;
           try {
               // CODE
           } finally {
               res3.close();
           }
      } finally {
          res2.close();
      }
  } finally {
      res.close();
  }

  
  
  
• La gestion des exceptions en est améliorée et clarifiée, puisqu'on n'a pas à doubler le niveau d'indentation :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  // Nouveau code :
  try (Ressource res = ...) {
      // CODE
  } catch (RessourceException e) {
      e.printStackTrace();
  }
   
   
  // Ancien code :
  try {
      Ressource res = ...;
      try {
          // CODE
      } finally {
          res.close();
      }
  } catch (RessourceException e) {
      e.printStackTrace();
  }

  
  
  
• La gestions des multiples exceptions sera géré. Actuellement avec ce modèle si une exception survient dans le "CODE", elle peut être caché par une autre dans le close() du finally, ce qui veut dire qu'on peut perdre des informations cruciale sur l'origine de l'erreur.
  
  Le problème c'est qu'actuellement cela demande un gros paquet de code. Par exemple pour UNE ressource :
  
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  Throwable previous = null;
  Ressource res = ...;
  try {
      try {
          // CODE
      } catch (RessourceException e) {
          // On conserve la référence de l'exception :
          previous = e;
          // Et on la laisse se propager :
          throws e;
      }
  } finally {
      try {
          res.close();
      } catch (RessourceException e) {
          // Si une exception a déjà eu lieu :
          if (previous) {
              // On recherche l'exception originale :
              Throwable t = e;
              while (t.getCause()!=null) {
                  t = t.getCause();
              }
              // On lui affecte l'exception précédente 
              t.initCause(previous);
          }
  	// Et on laisse l'exception se propager :
          throws e;
      }
  }

  Vu le code que cela demande, il est acceptable de se contenter du pattern try/finally tout simple... mais un problème de ce type survient on peut perdre un temps fou à trouver l'origine d'un problème qui aurait pu être résolu en deux-deux avec l'exception orginale !
  
  ARM gèrera cela en interne...

Le second gros problème c'est que la syntaxe du try/finally n'est pas toujours très respecté, et chacun le gère un peu comme il veut en l'adaptant à sa sauce... mais souvent cela donne quelque chose de pas forcément correct :

• 
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
   
  Ressource res = null;
  try {
      res = new ...;
      // CODE
  } finally {
      res.close(); // NPE possible !!!!
  }

  Ici dans le bloc finally "res" peut être null et renvoyé une NullPointerException, qui cacherait l'origine exact du problème !
  Par exemple en cas de FileNotFoundException la référence "res" reste null mais on passe dans le try, qui génèrera une NullPointerException pas pratique à traiter
  
  
  
  

• Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
   
  Ressource res = ...;
  Ressource res2 = ...;
  Ressource res3 = ...;
  try {
  	// CODE
  } finally {
  	res3.close();
  	res2.close();
  	res.close();
  }

  Ici on a deux grosses erreurs possible :
  
  • Si une exception survient dans les constructeurs, on ne rentre pas dans le try donc aucune ressource n'est libéré (même si elle était ouverte).
  • Si une exception survient dans les close(), les fermetures suivantes ne seront pas exécutées...
  
  
  Le bloc finally devrait uniquement contenir un close(), car d'autres instructions pourrait provoquer des exceptions avant que tout le code du finally ne soit exécuté...
  
  
• 
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
   
  Ressource res = ...;
  try {
      // CODE
  } catch (RessourceException e) {
      e.printStackTrace();
  } finally {
      try {
          res.close();
      } catch (RessourceException e) {
          e.printStackTrace();
      }
  }

  Ici on a une double gestion des exceptions. Même si ce n'est pas incorrect cela allourdit le code et amplifie le risque d'erreur... surtout si on doit gérer plusieurs ressources...

ARM a l'avantage de proposer un code simple qui prend en compte les problèmes rencontrées sans complexifier le code.
De même on pourrait imaginer que les compilateurs/EDIs puissent générer un warning/message lorsqu'on utilise une ressource en dehors d'ARM...


a++

[adiGuba]

Juste pour info : le path des améliorations des valeurs numériques (syntaxe binaire et underscore dans les nombres) a été soumis au projet JDK7 et devrait être intégré dans les futures builds...

a++

[_skip]

Perso je suis un peu déçu...

Je plussoie complètement les blocs ARM, c'est ce qui est fait déjà en .Net avec la directive using et ça amène en effet une syntaxe légère et très sûre (rien n'est plus moche qu'un catch vide dans un finally).

Par contre, l'un de ces gourous de java (Miller?), dans son blog, avait plus ou moins annoncé que la simplification des try/catch aurait lieu. Grosse déception on continuera avec ce genre de daube encore quelques années :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
    try
    {
      Class clazz = Class.forName("org.berkeley.Database");
      Constructor constructor =
        clazz.getConstructor(String.class, String.class, String.class);
      return constructor.newInstance(url, username, password);
    }
    catch (InstantiationException e)
    {
      throw new PluginException(e);
    }
    catch (IllegalAccessException e)
    {
      throw new PluginException(e);
    }
    catch (IllegalArgumentException e)
    {
      throw new PluginException(e);
    }
    catch (InvocationTargetException e)
    {
      throw new PluginException(e);
    }
    catch (NoSuchMethodException e)
    {
      throw new PluginException(e);
    }
    catch (SecurityException e)
    {
      throw new PluginException(e);
    }
    catch (ClassNotFoundException e)
    {
      throw new PluginException(e);
    }

Pour ce qui est de la syntaxe en diamant, pourquoi pas c'est déjà bien même si j'aurai préféré une pseudo inférence de type des variables locales (comme avec "var" en c#), surtout dans les itérations de HashMap avec for( Entry<x,y> : ...).


Bref bilan mitigé donc, quelques bonnes nouvelles (ARM, Filesystem), quelques modifications gadgets (switch(String)). Au final ce qui est bien lourd (getter/setter, catch multiple de checked exception etc...) reste bien lourd...

[professeur shadoko]

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]

@_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]

[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]

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]

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.