Présentation de Java SE 7

Voici un aperçu des principales nouveautés de Java SE 7, avec notamment :

• les évolutions du langage apporté par le projet Coin
• le support des langages dynamiques
• de nouvelles APIs d'entrées/sorties (NIO.2)
• et bien plus encore...

Bonne lecture : http://adiguba.developpez.com/tutoriels/java/7/

Et vous ? Avez-vous migrer vers Java 7 ? Pensez-vous le faire ?
Que vous inspire cette nouvelle version de la plateforme Java ?

a++

Je sent que mon après midi productive va être remplacée par une petite lecture ...

Merci pour l'article.

*Sifflement admiratif*

Eh ben t'a pas fait les choses à moitié, ça c'est une présentation de nouveaux features, claire, précise, abordant tous les sujets à ma connaissance, et en français.

Que dire ? Bon boulot. Vraiment bon boulot.

Exactement ce que je cherchais... Une bonne synthèse exhaustive et en plus accessible au béotien...

Un seul mot : Merci ! :ccool:

Excellent article. Merci pour le travail de synthèse.

Merci pour ce bon article, avec une super présentation.

Très bon article. Merci.

Merci beaucoup :)
J'ai bien apprécié la partie java.nio.file qui va me faciliter l'existence
(l'encodage de caractères avec la classe FileWriter est une vraie purge)

La transparence va mettre un coup de neuf à mes écrans

Vraiment une bonne présentation

Merci pour ce superbe article de qualité !

Enfin de l'améliorer encore, j'ai noté quelques coquilles :

• Paragraphe "FileAttributeView : accès aux attributs", exemple "Accès aux attributs par leurs noms" :
  
  Code:

  ---

  // Pour la vue basiqueClaude Leloup2012-03-01T17:08:06Sauf si c'est un terme de syntaxe, le nom de la vue peut être omis :

  ---

  => pb de coller malheureux ?
  
  Code:

  ---

  long size = (Long) Files.getAttribute(path, size); // basic:size

  ---

  => il manque des "" autour du second paramètre de la méthode "getAttribute"
  
• Paragraphe "WatchService : détecter les changements dans un répertoire", exemple "Surveiller les modifications d'un répertoire" :
  
  Code:

  ---

  if (event.king()==StandardWatchEventKinds.OVERFLOW)

  ---

  => méthode "kind", pas "king" ;)
  
• Paragraphe "ZIP FileSystem : gérer les archives Jar/Zip simplement !"
  
  • Exemple "Exemple de traitements à l'intérieur d'un fichier ZIP" :
    
    Code:

    ---

    try (DirectoryStream<Path> stream = Files.newDirectoryStream(zipFS.getPath(/))) {

    ---

    => manque des "" autour du "/" dans la méthode "getPath"
  • Juste avant l'exemple "Décompression d'une archive ZIP" :
    
    Code:

    ---

    On utilise pour cela la méthode Fils.walkFileTree()

    ---

    => manque un "e" à "Files"
  
  
• Paragraphe "Les tout petits plus..."
  
  • Exemple "Exécution de programme externe" :
    
    Code:

    ---

    Process process = new ProcessBuilder(ls)

    ---

    => manque des "" autour du "ls"
  • Exemple "Exemple d'utilisation de Objects dans une classe simple" :
    
    Code:

    ---

    this.date = Objects.requireNonNull(date, date is null);

    ---

    => manque des "" autour de "date is null"

Bonjour,

Je viens de lire une partie de votre article et vous remercie de cette initiative qui permet de nous immerger rapidement dans cette version 7.

Dans la partie "try-with-resources", j'ai noté le fait qu'

Citation:

---

Il faut malgré tout continuer de se méfier des encapsulations de flux. En effet si l'un des flux génère une exception, le flux qu'il encapsule ne sera pas visible par le try-with-resources et il ne pourra donc pas être fermé correctement

---

et vous prenez pour exemple le code suivant :

Citation:

---

try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("file")))

---

Or ObjectInputStream est un décorateur, sa méthode close() a aussi la responsabilité de fermer les flux qu'elle décore.

J'ai regardé rapidement le code de ces méthodes et il me semble bien que cela soit le cas.

Dans cette exemple, le try-with-resources ferme bien toutes les ressources. A moins que je fasse fausse route ?

Salut,

Citation:

---

Envoyé par zann12

Or ObjectInputStream est un décorateur, sa méthode close() a aussi la responsabilité de fermer les flux qu'elle décore.

---

C'est tout à fait vrai, et le code suivant est correct la plupart du temps :

Code:

---

1 2 3

try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("file"))) {   }

---

Mais pour que la méthode close() soit exécutée, il faut que l'objet ObjectInputStream soit créé correctement.
Or le constructeur d'ObjectInputStream effectue une opération de lecture afin de lire le header propre à la sérialisation Java.
Du coup lorsque le fichier n'est pas au bon format, on a une exception StreamCorruptedException qui est remontée à la création de l'ObjectInputStream.

Mais si l'instance de ObjectInputStream n'a pas pu être créé, elle ne pourra pas être fermée par le try-with-ressource, et le FileInputStream sera alors perdu...

En séparant les deux flux, tu es sûr de bien les fermer quoi qu'il arrive :

Code:

---

1 2 3 4

try (FileInputStream fs = new FileInputStream("file"); ObjectInputStream ois = new ObjectInputStream(fs)) {   }

---

:arrow: Si "ois" ne peut pas être créé, "fs" sera quand même fermé.



Cela semble anodin mais ca peut être très problématique dans une appli serveur destiné à traiter de grosse quantité de données...


a++


PS : @loicdvi Merci de vos remarques. Je vais modifier l'article dès que possible.

Je vous remercie pour vos précisions :)
Je prends note.

Bonne soirée

Super présentation,

juste une remarque :
j'ai essayé l'exemple du Phaser avec un nombre super grand de Thread. Genre 2000 (ouai, je suis un ouf malade).
(adiguba.developpez.com/tutoriels/java/7/#IdTitreCode-d0e10163)

Du coup, l'ordre des étapes n'est plus bon :calim2:

Avec un nombre de thread connu, il vaut mieux faire tous les register avant de les lancer.

Hello Akhlo,

ou alors, on s'inspire de la JavaDoc de Phaser : le thread qui crée les autres threads s'enregistre lui aussi, et chaque thread créé commence par appeler arriveAndAwaitAdvance(), ce qui fait donc que tous les threads créés attendent que le thread créateur l'appelle aussi.
Quand le thread créateur a fini de créer tous les threads, il appelle arriveAndDeregister(), ce qui libère tous les autres, et fait en sorte qu'ils ne l'attendent plus.

Cela marche, qu'on connaisse ou non le nombre de threads.