Version imprimable
Bonsoir,
je souhaite utiliser une lib externe (commons-io-2.11.0 de org.apache). J'utilise notepad++ et cmd sur windows 10
J'ai mis à jour le CLASSPATH avec le dossier contenant mes libs (H:\javaPackages).
j'ai fais l'import (import commons-io-2.11.0;)
etme renvoit:Code:javac mon.java
qu'ai je fais d'incorrect ?Code:
2
Hello,
il faut pas. C'est le CLASSPATH qui s'en charge.Citation:
Envoyé par run(F) jkldc
ok, merci pour votre réponse.
Il m'est quand même étrange de constater que je dois spécifier par des "import" qu'elles classes j'utilise, d'autant plus que n'importe quel IDE fait ces résolutions de manière automatique, alors que java ne le fait pas (on pourrait dire la même chose à propos du C). En revanche spécifier un JAR/ZIP contenant un ensemble de classes ne lui pose pas de problème.
J'avais cherché, il y a peu, pour quelle raison je ne pouvais pas faireLa réponse en a été que:Code:import java.*
"S'il existe une classe Foo dans java*bar et une autre classe Foo dans java .qux.corge il y aurait des problèmes de liaisons."
Mais rien ne contredis que dans un JAR/ZIP il y ait cette structure de deux classes ayant le même nom, ou que j'utilise, du langage java, 2 classes ayant le même nom et donc que je doive faire un import des 2 classes.
Comment javac fait-il pour la résolution de ce type de conflit, sans espace de nom ?
Hello,
il utilise des espaces de noms. Tu crois que c'est quoi, java.truc.bidule ?
import c'est du sucre syntaxique qui permet d'utiliser le nom court de la classe au lieu de de voir écrire son nom pleinement qualifie a chaque fois. C'est essentiellement exactement la même chose que using namespace dans d'autres langages.
Effectivement, pour distinguer 2 classes ayant le même nom court dans le même code (au hasard java.util.Date et java.sql.Date), on peut importer celle utilisée le plus souvent dans le code pour utiliser son nom court partout et pour les quelques instances de l'autre, on utilisera le nom pleinement qualifié.