Discussion :

[yotta]

Bonjour,
Je rencontre une difficult� avec la m�thode mkdir() de la classe java.io.File.
J'utilise naturellement une instance de File avec le chemin complet vers mon nouveau dossier, puis je sollicite sa m�thode mkdir() si le dossier n'existe pas.
Le dossier est bien cr��, mais il m'est impossible de le supprimer depuis l'explorateur de Windows tant que je n'ai pas quitt� mon programme ?!
Bien que dans ce dernier, l'instance de File utilis�e pour cr�er le dossier n'est plus utilis�e, mon programme ne lib�re pas le dossier qu'il a cr��. Je ne comprends pas pourquoi ?
Donc, encore moins comment �viter cela. En effet, j'aimerai pouvoir supprimer ce dossier m�me si mon programme vient de le cr�er et ce sans �tre oblig� de le quitter mais je ne vois pas comment faire ?...

[jeffray03]

salut,
essaies cette commande depuis ton ecran de commande WINDOWS:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

RD /S /Q chemin_de_vers_ton_repertoire

Eric

[yotta]

Salut jeffray03,
Merci pour ton intervention. Malheureusement, m�me punition, la commande n'aboutit pas et affiche en ligne de commande la m�me erreur, � savoir que la suppression est impossible parce que ce dernier est actuellement ouvert dans une application ???
Identique pour les fichiers contenus dans ce dossier. Le seul moyen de reprendre la main sur ces fichiers ou le dossier depuis Windows est de quitter la machine virtuelle Java ???
Pourtant, je ne sollicite aucun flux directement, je me contente d'utiliser la m�thode mkdir de la classe File pour cr�er un dossier de destination dans lequel ensuite je copies des fichiers via la m�thode copy de la classe Files.
Comment puis-je faire pour l�cher la main sur ces dossiers et fichiers sans �tre oblig� de quitter la JVM ?

[fr1man]

Montre nous un peu de code.
Tu ne laisses pas un flux ouvert sur un fichier de ce r�pertoire, par hasard ?

[yotta]

C'est tout ce que je m�rite....

�a c'�tait avant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Files.copy(fichierSource.toPath(), new FileOutputStream(fichierDestination));

Ca c'est maintenant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
FileOutputStream fluxSortie = new FileOutputStream(fichierDestination);
Files.copy(fichierSource.toPath(), fluxSortie);
fluxSortie.close();

Et �a marche beaucoup mieux. Merci fr1man, ta remarque a fait Tilt !

[thelvin]

Pendant qu'on y est :

Toujours g�rer les flux avec un try-with-resource !

Tu n'as aucune garantie que ton code arrivera sans encombre jusqu'au fluxSortie.close(), l�. Un try-with-resource donnerait cette garantie, dont tu sais maintenant qu'elle est indispensable.

[yotta]

Merci pour cette pr�cision, thelvin.
Le pire, c'est que mon petit Netbeans me l'a propos� le try with ressource. Mais comme je n'avais pas encore regard� quelle diff�rence pr�sentait ce type de try, et que Netbeans me permet de passer outre la recommandation, j'avais conserv� un try standard. Si j'avais �cout� Netbeans et mis en place un try with ressource, j'aurais certainement vu passer une exception qui m'aurait fait comprendre mon erreur, je n'aurais alors emb�t� personne avec cette question stupide...
En tous cas, j'ai bien retenu la le�on.
Bonne continuation.

[adiGuba]

Salut,

Juste quelques remarques :

• Gros +1 pour le try-with-resource, qui permet de bien lib�rer les ressources quoi qu'il arrive.
  C'est m�me primordial dans une application serveur o� ce genre d'oubli peut entrainer des blocages li� � des limites syst�mes.
  
  
• J'ai remarqu� que tu utilises � la fois l'ancienne API (java.io.File) et la nouvelle API (Path et Files du package java.nio.file).
  Perso je te conseillerais d'utiliser uniquement la nouvelle API si c'est possible, c'est � dire grosso-modo de remplacer File file = new File("xxx") par Path path = Paths.get("xxx") et d'utiliser les m�thodes statiques de la classe Files.
  L'API est plus claire, mieux con�us et plus compl�te...
  
  
• Dans ton cas pr�cis, tu peux utiliser Files.copy(Path,Path) � la place de Files.copy(Path,OutputStream)...
  En lui passant deux "Path", non seulement tu te lib�res de la gestion des ressources, mais en plus cela permet � l'API d'optimiser la copie, notamment si les deux fichiers sont sur le m�me syst�me de fichier...

[yotta]

Effectivement Adigouba, c'est plus intelligent de n'utiliser que java.nio.file.Files et java.nio.file.Paths, et je ne me suis pas g�n� pour corriger � nouveau le tir. Cependant, dans ce cas, pas de throw with ressource ?!
throws with ressource n'accepte pas la classe Path.

R�sum� avec FileOutputStream :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
try (FileOutputStream fluxSortie = new FileOutputStream(fichierDestination)) {
    Files.copy(fichierSource.toPath(), fluxSortie);
    fluxSortie.close();
    }
catch (FileNotFoundException ex) {
    ...
    }
catch (IOException ex) {
    ...
    }

R�sum� avec java.nio.file.Path :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
Path source = Paths.get("..../source.truc");
Path destination = Paths.get("..../destination.truc");
try {
    Files.copy(source, destination);
    }
catch (IOException ex) {
    ...
    }

En effet, dans le second cas, je ne peux pas utiliser try with ressource...
Autre d�tail qui m'intrigue. Dans la documentation de l'API Java 8 utilis�e ici, il n'y a aucune trace d'une m�thode Files.copy(Path src, Path dst) ?!
Un oubli dans le javadoc ?
Seules trois m�thode copy sont document�es , l'une prenant un InputStream en source et un Path en cible, l'autre prenant l'inverse, un Path en source et un OutputStream en cible (celle que j'utilisais au d�part), et une derni�re avec trois param�tres, un Path en source, un Path en cible et des options de copie. Mais je n'ai trouv� aucune m�thode document�e avec un Path en source, un Path en cible et rien d'autre ???
C'est bien dommage, car si elle avait �t� document�e dans l'API Java 8, je l'aurai probablement utilis�e d�s le d�but. C'est surprenant qu'elle n'apparaisse pas dans la doc ???

[adiGuba]

La fermeture des ressources est � la charge de celui qui l'ouvre, donc tu n'as pas besoin d'utiliser un try-with-resource dans ce cas, tout comme tu ne l'utilisais pas pour le fichier d'entr�e...

Au passage tu n'as pas � appeler explicitement close() avec un try-with-resource. Le close() est automatique.

Quand � la m�thode copy() elle est bien document�e. C'est justement Files.copy(Path,Path,CopyOption...).
Mais le "troisi�me" param�tres �tant un varargs, il est variable et peut donc contenir z�ro, une ou plusieurs valeurs.

[yotta]

Merci Adiguba pour ces pr�cisions. J'avais fini par comprendre que ce param�tre pouvant �tre null pouvait aussi �tre omis. Dans mon esprit, il �tait n�cessaire de passer trois param�tres, quitte � mettre null en troisi�me param�tre. D'ailleurs, d'habitude, dans la doc. ils pr�cisent que le param�tre peut �tre null. L� c'est un peu le contraire. Mais bon, c'est un d�tail.
Maintenant j'ai compris deux choses suppl�mentaires : Bien ma�triser ses flux, et un param�tre null peut �tre omis.
Bonne continuation.

[adiGuba]

et un param�tre null peut �tre omis.

Non un param�tre null ne peut pas �tre omis.
C'est surtout qu'on a affaire � un vararg.

C'est juste que l'on a affaire a un param�tre varargs, c'est � dire d�fini comme cela :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
public static Path copy(Path source,
        Path target,
        CopyOption... options)

Les 3 points derri�re le nom du dernier param�tre indique que c'est un vararg, c'est � dire un param�tre qui peut prendre z�ro, une ou plusieurs valeur.
En r�alit� ce dernier param�tre CopyOption... est l'�quivalent d'un tableau, soit CopyOption[].
La diff�rence c'est que l'on n'a pas � g�rer le tableau manuellement, c'est le compilateur qui s'en charge :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
copy(source, target, StandardCopyOption.COPY_ATTRIBUTES, StandardCopyOption.REPLACE_EXISTING);
// équivaut à 
copy(source, target, new CopyOption[]{StandardCopyOption.COPY_ATTRIBUTES, StandardCopyOption.REPLACE_EXISTING});
 
 
copy(source, target, StandardCopyOption.REPLACE_EXISTING);
// équivaut à 
copy(source, target, new CopyOption[]{StandardCopyOption.REPLACE_EXISTING});
 
 
copy(source, target);
// équivaut à 
copy(source, target, new CopyOption[0]);

Donc du coup toutes les m�thodes qui utilisent un varargs peuvent �tre appel� sans aucune valeur pour ce dernier param�tres.


Les APIs "r�centes" utilisent beaucoup cela lorsqu'il faut passer diverses valeurs.

[yotta]

D'accord, le genre de truc que tu ne peux pas deviner si on ne te l'explique pas... (je suis autodidacte)
Tu as bien fait d'insister, je serai pass� compl�tement � c�t� de ce 'principe' vararg.
Jusque l�, je rangeais toujours les param�tres dans un conteneur quelconque (List, Set, Map, Vector, Object[], etc...) fourni en param�tre. Je ne savais pas que l'on pouvait faire autrement

Donc, si je voulais calculer une moyenne sans conna�tre � l'avance le nombre de termes, je pourrai faire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
public double calculMoyenne(double... valeurs) {
    double reponse=0.0d;
    for (double d:valeurs) reponse+=d;
    return reponse/valeurs.length;
    }

et ainsi calculer n'importe quelle moyenne en faisant par exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

System.out.println("Moyenne de 24,53,1,9,et 14 : " + calculMoyenne(24,53,1,9,et 14));

C'est juste g�nial, je d�couvre.
C'est sp�cifique � Java ou c'est un m�canisme standard dans tous les langages ?

[thelvin]

Le probl�me de ton exemple, c'est qu'un vararg peut repr�senter un ou deux ou vingt-cinq arguments, mais aussi z�ro argument.

Et la moyenne d'aucun nombre, bon...

Boh apr�s tout �a peut �tre NaN, pourquoi pas...

C'est sp�cifique � Java ou c'est un m�canisme standard dans tous les langages ?

Les varargs sont fr�quents dans les langages de programmation, par exemple en C ils sont n�cessaires pour fournir le fameux printf().

Mais bon, il y a des langages qui ne les ont pas... Tels que Java avant la version Java 1.5. Avant �a, on pouvait toujours prendre un tableau en param�tre, � la place.

[yotta]

Ok, j'ai bien tout compris.
Merci � vous.