2010-02-19 6 views
1

Quelqu'un peut-il s'il vous plaît expliquer la réponse à la question suivante:package Java et question classpath

Compte tenu d'une classe compilée correctement dont le code source est:

package com.sun.test; 
public class Commander { 
    public static void main(String[] args) { 
    } 
} 

On suppose que le fichier de classe est situé dans/foo/com/sun/test /, le répertoire courant est/foo /, et le classpath contient "." (répertoire actuel). Quelle ligne de commande exécute correctement Commander?

A. java Commander

B. java com.sun.test.Commander

C. java com/sun/test/Commander

D. java -cp com.sun.test Commander

E. java -cp Commander com/soleil/test

+2

Pourquoi ne pas simplement essayer tous? – sfussenegger

+0

Vous avez de la chance. Évidemment, certains gars répondent à n'importe quoi pour la réputation;) – sfussenegger

+0

Oui, il doit essayer de trouver la solution. Cependant, il peut ne pas comprendre pourquoi ils travaillent ou pas ... – romaintaz

Répondre

4

et la meilleure réponse serait B. C fonctionne également sur certaines plates-formes, mais ne sont pas recommandées et est très rare (au moins, je je ne l'ai pas vu depuis plus de 10 ans en programmation Java).


EDIT

Une idée fausse commune avec les débutants en Java est un nom de classe est quelque chose comme "MyClass". Mais ce n'est pas exact. la nomenclature "MyClass" comme vu dans la déclaration class MyClass est vraiment une commodité pour le programmeur que le compilateur combine avec la déclaration de package pour créer ce que Java appelle un nom de classe qualifié, que tous les noms de classe sont réellement à l'exécution. (En C#, ils utilisent des espaces de noms pour cela).

Cela devient évident dans de nombreux cas, tels que les traces de pile et les signatures de méthodes qui contiennent toujours, par exemple, java.lang.String. Parce que "String" est juste une forme courte qui est résolue en java.lang.String. Vous pouvez le prouver en créant votre propre chaîne dans votre propre paquet ... mais attention, vous devrez utiliser explicitement java.lang.String ou my.package.String partout où les deux packages ou classes sont importés. Une fois que vous avez assimilé le fait que tous les noms de classe sont entièrement qualifiés et que le compilateur vous aide à éviter le travail fastidieux en utilisant les importations pour résoudre les formulaires courts en formulaires complets, les choses deviennent plus claires.

Il est alors évident pourquoi:

java -cp com/soleil/test Commander

ne fonctionne pas. L'option cp place le répertoire ./com/sun/test (relatif au répertoire courant) sur le chemin de la classe, mais il n'y a pas de classe nommée Commander ... c'est com.sun.test.Commander. Cela implique deux choses: (a) la ligne de commande requiert com.sun.test.Commander et (b) le classpath doit contenir une entrée pour le répertoire contenant "com" afin de résoudre cette classe car une classe nommée xyMyClass doit être en x/y par rapport à un élément classpath.


PS: Vous ne devriez pas utiliser com.sun comme nom de package, sauf si vous êtes employé par Sun, puisque le nom de domaine sun.com appartient à Sun. Cette convention existe pour éviter les collisions de classes et de noms.


PPS: Il y a une chose telle que le package par défaut, qui est « spécifiée » en omettant la déclaration de paquet - mais il ne devrait presque jamais être utilisé. Le seul endroit que j'ai trouvé légitime est un « lanceur/Classloader » autonome où l'on souhaite pouvoir faire:

java -cp . Launcher com.xxx.yyy.TargetApp 

avec Launcher.class dans le répertoire courant ... et qui est seulement car les fichiers JAR sont bloqués pendant que l'application s'exécute alors que les fichiers de classe ne le sont pas, ce qui signifie que Launcher.class peut se mettre à jour automatiquement, tandis que Launcher.jar ne le peut pas.

+0

Merci logiciel singe. Pouvez-vous s'il vous plaît expliquer la raison. Je pense que E devrait aussi fonctionner. – Zacky112

+0

E ne fonctionne pas car la classe est "com.sun.test.Commander" et ne peut prétendre être dans le package par défaut (c'est-à-dire uniquement "Commander"). –

2

A. ne fonctionne pas, comme Java ne trouve pas la classe

Commander B. fonctionnera, comme Java ne sera pas trouvé la com.sun.test.Commander classe

C fonctionne, au moins sur une plateforme de Windows. C'est pourquoi vous devez utiliser . au lieu de /.

D et E. Ils ne fonctionnent pas parce que nous demandons encore Java pour rechercher la classe Commander et non com.sun.test.Commander

+3

C fonctionnera également au moins sur Windows – Lauri

+0

Vous avez totalement raison. J'ai édité ma réponse. – romaintaz

2

En supposant la variable d'environnement CLASSPATH est pas défini (et donc répertoire de travail courant est dans le chemin de classe par défaut) , les réponses sont les suivantes:

A. ne fonctionne pas, il n'y a pas de classe de commandant dans le package par défaut

B. celui-ci fonctionne

C. Thi s on travaille aussi, mais B est préféré

D. chemin classe est foo/com.sun.test où il n'y a pas de classe de commandant dans le package par défaut

chemin E. classe est foo/com/sun/test où il n'y a pas de classe Commander dans le paquet par défaut