Discussion :

[grunt2000]

Depuis plusieurs années, je suis agacé par ces classes dont la série de directives import trône comme une épitaphe au sommet de leur fichier source.

Leur intérêt documentaire me semble limité au regard de leur encombrement. Quant à leur nécessité pour rendre la compilation possible, je pense qu'aujourd'hui, les compilateurs ayant atteint des capacités impressionnantes que l'on sait (et qu'illustrent, par exemple, les annotations), les directives import font figure d'anachronisme.

Car après tout, la commande javac est toujours associée implicitement ou explicitement à un classpath. Il serait aisé au compilateur d'énumérer le contenu des jars* et de ne réclamer de directive import que dans le cas où une ambiguïté aurait lieu (Deux classes de même noms situés dans deux packages différents).


Cela épargnerait à mon sens un travail fastidieux et d'aspect relativement vieillot, maintenant.

Que pensez-vous de cela?


*il le fait, de toutes façons, étant obligé d'examiner au minimum les entêtes des jars/zips pour retrouver ses classes.

[NicoV]

Perso, je trouve çà très bien de préciser les import (en plus ce n'est pas fastidieux, avec n'importe quel IDE pas trop ancien, çà se fait tout seul en codant : sous Eclipse, tu commences à taper le nom de ta classe et Ctrl+Espace et çà complète et ajoute l'import). Je suis plutôt pour les langages qui obligent à tout déclarer et qui ne déterminent pas des trucs tout seul (genre VB qui te permet de ne pas déclarer tes variables).

La recherche dans le Classpath marcherait si tu développes tout seul, mais dès que tu partages ton code (genre sourceforge, ...) chaque personne à un classpath différent.

Mes 2 cts.

[adiGuba]

Salut,



Ne pas utiliser d'import, ou utiliser les " import * ", c'est la meilleure façons de risquer de perdre la compatibilité du code source, car rien ne garantit que les deux compilateurs utilisent le même classpath, ni que de nouvelles classes du même nom ne puissent apparaitre par la suite...

Un exemple, avec Java 1.3/1.4 il existe une seule classe nommé Proxy (java.lang.reflect.Proxy), or à partir de Java 5.0 il y en a une seconde (java.net.Proxy).
Ton code parfaitement compilable sous Java 1.3/1.4 te posera des soucis avec Java 5.0 ou plus récent...

Et cela peut même être pire si tu utilises des librairies externes...


Et je ne t'explique même pas comment faire pour retrouver à quelle librairie appartient une éventuelle classe nommé Tools


Je ne pense pas que la recherche d'import soit vraiment le rôle du compilateur : il doit compiler le code que tu lui donnes et non pas tenté d'interpréter ce que tu veux utiliser...

De plus le rejoint NicoV sur le fait que les EDI gère cela très bien (ne pas oublier le Ctrl+Shift+O sous eclipse qui génère tous les imports manquant).


a++

[millie]

Je rejoins l'avis d'adiGuba et je vais donner quelques autres classes ayant le même nom mais pouvant se trouvant dans plusieurs package :
Connection : com.sun.corba.se.pept.transport, com.sun.jndi.ldap, java.sql, sun.rmi.transport, com.sun.corba.se.spi.legacy.connection
List : java.awt, java.util
InputStream : java.io, org.omg.CORBA.portable
Array : java.lang.Reflect, java.sql
Policy : java.security, javax.security.auth, org.omg.CORBA

De plus, rien ne t'empeche d'avoir à créer des classes n'ayant aucun rapport avec les classes de la bibliothèque standard, mais portant le même nom, par exemple Image. Beaucoup de bibliothèques de traitement d'images redéfinissent une classe Image et n'ont pas de apport avec la classe java.awt.Image