je modifie une application qui contient plusieurs classes à la racine de
l'arborescence de développement, et je voudrais en déplacer certaines dans
un package.
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources
:
Classe1.java
Classe2.java
et je voudrais arriver à:
Classe1.java
<répertoire du package>
Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment
faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un
sait comment faire ?
Quelques explications plus détaillées : Classe1 est une Applet, je souhaite
la laisser à la racine pour qu'on puisse y faire référence directement dans
une page HTML <applet code="Classe1" ...> pour que les pages HTML existantes
continuent à fonctionner. Par contre, je trouve que ce serait quand même
plus propre qu'il y ait le minimum de classes à la racine.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cédric Chabanois
Salut,
je modifie une application qui contient plusieurs classes à la racine de l'arborescence de développement, et je voudrais en déplacer certaines dans un package.
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources : Classe1.java Classe2.java et je voudrais arriver à: Classe1.java <répertoire du package> Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un sait comment faire ?
Quelques explications plus détaillées : Classe1 est une Applet, je souhaite la laisser à la racine pour qu'on puisse y faire référence directement dans une page HTML <applet code="Classe1" ...> pour que les pages HTML existantes continuent à fonctionner. Par contre, je trouve que ce serait quand même plus propre qu'il y ait le minimum de classes à la racine.
Merci d'avance
Il n'est plus possible d'importer une classe du package par défaut à
partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la spec du JDK 1.4
Certains compilateurs ne l'acceptaient déjà pas avant.
Un conseil : évite absolument le package par défaut ...
Cédric
Salut,
je modifie une application qui contient plusieurs classes à la racine de
l'arborescence de développement, et je voudrais en déplacer certaines dans
un package.
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources
:
Classe1.java
Classe2.java
et je voudrais arriver à:
Classe1.java
<répertoire du package>
Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment
faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un
sait comment faire ?
Quelques explications plus détaillées : Classe1 est une Applet, je souhaite
la laisser à la racine pour qu'on puisse y faire référence directement dans
une page HTML <applet code="Classe1" ...> pour que les pages HTML existantes
continuent à fonctionner. Par contre, je trouve que ce serait quand même
plus propre qu'il y ait le minimum de classes à la racine.
Merci d'avance
Il n'est plus possible d'importer une classe du package par défaut à
partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la
spec du JDK 1.4
Certains compilateurs ne l'acceptaient déjà pas avant.
je modifie une application qui contient plusieurs classes à la racine de l'arborescence de développement, et je voudrais en déplacer certaines dans un package.
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources : Classe1.java Classe2.java et je voudrais arriver à: Classe1.java <répertoire du package> Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un sait comment faire ?
Quelques explications plus détaillées : Classe1 est une Applet, je souhaite la laisser à la racine pour qu'on puisse y faire référence directement dans une page HTML <applet code="Classe1" ...> pour que les pages HTML existantes continuent à fonctionner. Par contre, je trouve que ce serait quand même plus propre qu'il y ait le minimum de classes à la racine.
Merci d'avance
Il n'est plus possible d'importer une classe du package par défaut à
partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la spec du JDK 1.4
Certains compilateurs ne l'acceptaient déjà pas avant.
Un conseil : évite absolument le package par défaut ...
Cédric
Olivier Thomann
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources : Classe1.java Classe2.java et je voudrais arriver à: Classe1.java <répertoire du package> Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un sait comment faire ? La réponse est simple. L'import de classes dans la default package est
interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur. -- Olivier
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources
:
Classe1.java
Classe2.java
et je voudrais arriver à:
Classe1.java
<répertoire du package>
Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment
faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un
sait comment faire ?
La réponse est simple. L'import de classes dans la default package est
interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour
la démarrer:
<applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
--
Olivier
En clair, j'ai actuellement au niveau arborescence dans les fichiers sources : Classe1.java Classe2.java et je voudrais arriver à: Classe1.java <répertoire du package> Classe2.java
Le problème c'est que Classe2 utilise Classe1 et je ne vois pas comment faire un import de Classe1 qui ne fait pas partie d'un package. Quelqu'un sait comment faire ? La réponse est simple. L'import de classes dans la default package est
interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur. -- Olivier
Nico
"Cédric Chabanois" a écrit
Il n'est plus possible d'importer une classe du package par défaut à partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la spec du JDK 1.4
Ok, merci.
Certains compilateurs ne l'acceptaient déjà pas avant.
Je vois que la modification ne fait pas l'unanimité chez les développeurs Java.
Un conseil : évite absolument le package par défaut ...
C'est ce que je fais habituellement, mais là je voulais modifier une application que je n'ai pas faite en virant le maximum de classes du package par défaut. Avec cette restriction, je me retrouve obligé de conserver toutes les classes qui s'y trouvent. Je vais donc laisser cette partie du code en l'état.
En tout cas, merci pour les explications
"Cédric Chabanois" <cchabanois@ifrance.com> a écrit
Il n'est plus possible d'importer une classe du package par défaut à
partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la
spec du JDK 1.4
Ok, merci.
Certains compilateurs ne l'acceptaient déjà pas avant.
Je vois que la modification ne fait pas l'unanimité chez les développeurs
Java.
Un conseil : évite absolument le package par défaut ...
C'est ce que je fais habituellement, mais là je voulais modifier une
application que je n'ai pas faite en virant le maximum de classes du package
par défaut.
Avec cette restriction, je me retrouve obligé de conserver toutes les
classes qui s'y trouvent.
Je vais donc laisser cette partie du code en l'état.
Il n'est plus possible d'importer une classe du package par défaut à partir du JDK 1.4. La spec n'était pas très clair à ce niveau avant la spec du JDK 1.4
Ok, merci.
Certains compilateurs ne l'acceptaient déjà pas avant.
Je vois que la modification ne fait pas l'unanimité chez les développeurs Java.
Un conseil : évite absolument le package par défaut ...
C'est ce que je fais habituellement, mais là je voulais modifier une application que je n'ai pas faite en virant le maximum de classes du package par défaut. Avec cette restriction, je me retrouve obligé de conserver toutes les classes qui s'y trouvent. Je vais donc laisser cette partie du code en l'état.
En tout cas, merci pour les explications
Nico
"Olivier Thomann"
La réponse est simple. L'import de classes dans la default package est interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant : l'applet est utilisée par pas mal de monde et dans beaucoup de cas les pages html utilisent <applet code="Classe1" ...>. Et là je ne me vois pas faire une version qui oblige tous ceux qui se servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes dans le package par défaut.
La réponse est simple. L'import de classes dans la default package est
interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour
la démarrer:
<applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant : l'applet
est utilisée par pas mal de monde et dans beaucoup de cas les pages html
utilisent <applet code="Classe1" ...>.
Et là je ne me vois pas faire une version qui oblige tous ceux qui se
servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes dans
le package par défaut.
La réponse est simple. L'import de classes dans la default package est interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant : l'applet est utilisée par pas mal de monde et dans beaucoup de cas les pages html utilisent <applet code="Classe1" ...>. Et là je ne me vois pas faire une version qui oblige tous ceux qui se servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes dans le package par défaut.
Merci pour les réponses.
fg
"Nico" a écrit dans le message de news:41a0c633$0$5990$
"Olivier Thomann"
La réponse est simple. L'import de classes dans la default package est interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant : l'applet
est utilisée par pas mal de monde et dans beaucoup de cas les pages html utilisent <applet code="Classe1" ...>. Et là je ne me vois pas faire une version qui oblige tous ceux qui se servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes dans
le package par défaut.
Merci pour les réponses.
Pas forcément, il y a a quand même une solution : tu modifies Classe1 : Classe1 extends package.Classe1bis Tu copies tout le code de Classe1 dans Classe1bis, et tu ne laisses dans Classe1 que des référence à Classe1bis (éventuellement, passe certains champs ou certaines méthodes en protected, pour pouvoir y accéder de Classe1) Du coup, toutes les anciennes pages peuvent faire référence à Classe1, et pour ce qui est des nouvelles que tu crées à partir de maintenant, c'est quand même plus propre de mettre package.Classe1bis (sauf si pour un soucis d'uniformité....) Et plus aucune classe n'a à faire de référérence à Classe1 (les objets de type CLasse1 sont aussi de type package.Classe1bis, donc ils ont les mêmes méthodes...)
Voilà ma solution... si quelqu'un voit autre chose...
Frédéric
"Nico" <nvervell@club-internet.fr> a écrit dans le message de
news:41a0c633$0$5990$7a628cd7@news.club-internet.fr...
La réponse est simple. L'import de classes dans la default package est
interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour
la démarrer:
<applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant :
l'applet
est utilisée par pas mal de monde et dans beaucoup de cas les pages html
utilisent <applet code="Classe1" ...>.
Et là je ne me vois pas faire une version qui oblige tous ceux qui se
servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes
dans
le package par défaut.
Merci pour les réponses.
Pas forcément, il y a a quand même une solution :
tu modifies Classe1 :
Classe1 extends package.Classe1bis
Tu copies tout le code de Classe1 dans Classe1bis, et tu ne laisses dans
Classe1 que des référence à Classe1bis (éventuellement, passe certains
champs ou certaines méthodes en protected, pour pouvoir y accéder de
Classe1)
Du coup, toutes les anciennes pages peuvent faire référence à Classe1, et
pour ce qui est des nouvelles que tu crées à partir de maintenant, c'est
quand même plus propre de mettre package.Classe1bis (sauf si pour un soucis
d'uniformité....)
Et plus aucune classe n'a à faire de référérence à Classe1 (les objets de
type CLasse1 sont aussi de type package.Classe1bis, donc ils ont les mêmes
méthodes...)
Voilà ma solution... si quelqu'un voit autre chose...
"Nico" a écrit dans le message de news:41a0c633$0$5990$
"Olivier Thomann"
La réponse est simple. L'import de classes dans la default package est interdit depuis le JDK1.4. Donc fortement non recommandée!
Tu mets ton applet dans un package et tu utilises son nom qualifié pour la démarrer: <applet code="momPackage.Classe1" ...
C'est l'unique solution portable dans le futur.
Oui d'accord mais ce n'est pas portable par rapport à l'existant : l'applet
est utilisée par pas mal de monde et dans beaucoup de cas les pages html utilisent <applet code="Classe1" ...>. Et là je ne me vois pas faire une version qui oblige tous ceux qui se servent de l'applet à modier leurs pages HTML.
Conclusion, le code va rester dans l'état actuel avec plusieurs classes dans
le package par défaut.
Merci pour les réponses.
Pas forcément, il y a a quand même une solution : tu modifies Classe1 : Classe1 extends package.Classe1bis Tu copies tout le code de Classe1 dans Classe1bis, et tu ne laisses dans Classe1 que des référence à Classe1bis (éventuellement, passe certains champs ou certaines méthodes en protected, pour pouvoir y accéder de Classe1) Du coup, toutes les anciennes pages peuvent faire référence à Classe1, et pour ce qui est des nouvelles que tu crées à partir de maintenant, c'est quand même plus propre de mettre package.Classe1bis (sauf si pour un soucis d'uniformité....) Et plus aucune classe n'a à faire de référérence à Classe1 (les objets de type CLasse1 sont aussi de type package.Classe1bis, donc ils ont les mêmes méthodes...)
Voilà ma solution... si quelqu'un voit autre chose...
