Discussion :

[Janitrix]

Salut à tous ! Voilà j'ai 2 probleme d'optimisation.
Le premier est simple mais ça me fait refléchir et je trouve pas la reponse ^^ : est ce que ça prend plus de memoire ou de ressource d'importer toutes les classes d'un package ? Par exemple si j'ai besoin de la classe file et file reader, vaut mieux faire import java.io.*; ou import java.io.File; import java.io.FileReader;

2eme probleme : j'aimerai convertir un vector en matrcice de string, mais il n'existe pas de methods a proprement parler alors je fait :

Code :

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

1
2
3
4
5
6
7
 
//vec = un vector
Object [] all = vec.toArray();
string[] allString = new String[all.length];
for(int i = 0; i < all.length; i++) {
       allString[i] = (string)all[i]:
}

Ce code me suffit mais je le trouve lourd et je me demander si il n'y aurais pas une méthode plus "direct" et incluant moins de variable. Merci

[pk960]

Première question :
Importer toutes les classes d'un package n'est pas pénalisant à l'exécution. Par contre, c'est moins lisible et cela oblige à résoudre les conflits qui apparaissent s'il existe des classes de même nom dans deux packages différents.

Seconde question :

Code :

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

1
2
string[] allString = new String[vec.size()];
vec.toArray(allString);

[SEMPERE Benjamin]

Si tu n'est pas en environnement multithreadé et que tu souhaite optimiser ton code, n'utilise pas la classe Vector mais ArrayList.

En effet, la classe vector est threadSafe et donc plus couteuse en temps. De plus cette classe devrait disparaitre dans les prochaines versions du jdk

http://java.developpez.com/faq/java/...IONS_info_list

[Gfx]

Non la classe Vector ne disparaitra pas. En outre les blocs synchronized ne sont pas aussi lents que beaucoup trop de gens le disent. Referez-vous a ce tres bon article d'IBM.

Cela dit il est preferable de passer par une ArrayList. Si tu as besoin d'une version thread safe il suffit de faire appel a la methode Collections.synchronizedList(List) qui renvoie une version thread safe de ta liste (que ce soit une ArrayList, une LinkedList, etc.)

[SEMPERE Benjamin]

Cela dit il est preferable de passer par une ArrayList. Si tu as besoin d'une version thread safe il suffit de faire appel a la methode Collections.synchronizedList(List) qui renvoie une version thread safe de ta liste (que ce soit une ArrayList, une LinkedList, etc.)

Nous sommes donc d'accord..., si nous ne sommes pas en environnement multithreadé, plutôt utiliser l'ArrayList plutôt que son vis à vis Vector.
En ce qui concerne la disparition de Vector, tu dois avoir raison, en effet cette classe n'est pas annoncée comme deprecated (une petite erreur dans la faq java alors???)

[Gfx]

Et puis meme, les methodes deprecated ne sont pas pres de s'en aller. On fait tellement attention a la retro compatibilite que je doute que ca arrive avant un bon moment.

[bouye]

Code :

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

Importer toutes les classes d'un package n'est pas pénalisant à l'exécution.

En effet ca n'a strictement rien à voir avec l'intruction de pré-processeur C/C++ #include qui elle copie vraiment l'entête/header désignée dans le code (ca va surtout faire un exe plus gros que plus lent d'ailleurs si on inclue tout et n'importe quoi). Le import java se rapproche plus du using namespace C++. Bref le compilateur va remplacer les noms courts par des nons longs lors de la compilation.

Par contre, c'est moins lisible

Non ou alors c'est pour les débutant qui ne connaissent pas l'API JAva ou les libs qu'ils utilisent.
De tout facon avec les IDE récent ca importe peu (ex: dans JBuilder on fait control + click gauche sur le nom d'une classe pour afficher son code).

et cela oblige à résoudre les conflits qui apparaissent s'il existe des classes de même nom dans deux packages différents.

Ce qui est super-rare sauf si on nomme mal ses classes. Le seul conflit récurrent qui m'oblige à régulèrement mettre le nom long d'une classe concerne java.util.List et java.awt.List. Les autres conflits sont plutot annecdotiques.

[pk960]

Quand je fait une revue de code, je n'ai pas toujours l'assistance d'un IDE pour me dire à quel package appartient une classe. Donc j'aime bien avoir un import explicite.

Par ailleurs, j'ai développé un générateur de code Java qui nomme les classes selon des noms imposés par une description de données. Ces classes n'utilisent pas l'import multiple pour éviter des conflits imprévisibles chez les clients qui utilisent le générateur.

Je reconnais que ce sont deux cas qui ne sont pas rencontrés tous les jours. Mais ils expliquent pourquoi je préfère importer mes classes une à une plutôt qu'en bloc. Un IDE récent permet également de faire cela facilement.