Alors, y a t-il de nouveaux avis maintenant que vous pouvez tester un programme qui "normalement" marche avec la JDBC réparée ?

Je te le dis de suite : je vais le tester et te faire un retour sur le code, mais pas forcément ce week-end, vu que je suis charrette de ce côté-là ;)

charrette ?

Je passe mon inspection => 218 warnings (si j'enlève mes warning relatif à la typo et à la JavaDoc).

Tu as pas mal d'import inutilisés. Sous eclipse, ctrl + maj + o est ton ami (optimize import). Tu peux même faire en sorte qu'ils soient optimisés à la sauvegarde (ce qui n'est PAS une bonne idée dans une fat class).

Tu as aussi pas mal d'attributs inutilisées, donc autant les supprimer

Tu es en CP1252. Je te conseils très fortement de passer ton Eclipse, et tout tes projets, en UTF-8. Cela facilite le travail en équipe, et évite d'avoir des caractères inconnus inutiles faisant planter la compil'.

Comprend le mot-clé "static", et n'utilise PLUS (sauf si tu sais ce que tu fais) le fix automatique d'Eclipse pour l'erreur "Cannot use a non-static reference in a static context".

Il est tout à fait inutile de passer des arguments à la chaîne pour initialiser.
Le constructeur de "Joueurs" prend 6 arguments, toujours les mêmes, et ceux-ci étant "i, null, null, null, null, null, 0".
"i" est variant, le reste non. Il est donc inutile de les passer.
Ton constructeur ne devrait avoir qu'un argument.
Deux en fait, car il faut leur passer le JTextArea pour qu'ils y écrivent, histoire d'enlever le static de Fenetre#textprog, qui n'a pas de raison d'exister (ce JTextArea n'a aucune existence sans Fenetre, donc ne doit pas être static).

Concernant "this", il y a 2 écoles : ceux qui ne le mettent jamais sauf quand il est nécessaire. Ceux qui le mettent toujours, pour bien voir que c'est un attribut qui est manipulé. Comme tu le sens.

Pour les cascade de if pour des tests d'égalité entre 2 entiers, préfère un switch

Suit la convention Java :
- Nom de classe en UpperCamelCase
- Nom de méthode en lowerCamelCase (exception faite du constructeur).
- tout le reste en lowerCamelCase
- en différenciant les constantes aussi (souvent en MAJUSCULE_AVEC_SEPARATEUR).

Prend l'habitude de coder en anglais. Ca te facilite la compréhension de la logique du langage, et améliore ton anglais.

Évite les noms de variables styles : "maVariable1", "maVariable2" (c'est le 1 et le 2 qui est important dans cette exemple).

setVisible(), toujours en dernier appel.
Un appel à "pack()" est aussi une bonne idée.

Évite le plus possible de faire des tailles absolues en pixel.

Évite les méthode inutiles aussi (que tu sais qui ne seront jamais utilisées). Faire de telles méthodes, pour une bibliothèque est plus ou moins normal : tu ne peux pas savoir à l'avance et doit permettre un certain degrés de paramétrage, mais pour ce type d'application, c'est inutile (je pense notamment à setVisible).

Fait en sorte que les noms de méthodes soient explicites, de même que les noms de variables : "setProgram()", pour une méthode qui ajoute le texte de départ, ce n'est pas un bon nom.
"showBeginning", "showRules", "appendRules" ...

Personnellement, je considère comme mauvaise pratique, les Frame implémentant ActionListener pour faire les actions de leurs boutons.
Préfère nettement créer une classe Listener par action de bouton. Cela te permet de scinder le code, de le réutiliser sur plusieurs boutons ayant la même logique, et de le raffiner en étendant la classe du Listener.

Pour equals avec des string, préfère CONSTANTE.equals(maVariable) (ex : "Oui".equals(rep)).
Cela te permet d'éviter de faire un premier test de nullité.

Évite les fat method, sauf si c'est strictement obligatoire.
Préfère découper en plus petite méthode, dans lesquelles il est plus facile de traquer les bugs.

Pour les requêtes SQL, préfère utiliser des PreparedStatement.

N'oublie pas les modificateurs de visibilité devant les méthodes et attributs (ou utilise à bon escient la visibilité package).

La classe "Lire" est-elle de ton crû ?
Je ne ferai aucune remarque dessus sans avoir ce retour

Tu en es où au niveau de ce projet ? Rendu ?

Houlà sacré compte rendu

La classe "Lire" est-elle de ton crû ?
Je ne ferai aucune remarque dessus sans avoir ce retour

C'est de ma prof, elle nous l'avait passé au début pour qu'on puisse rentrer des caractères dans la console pour communiquer avec l'application.

Tu es en CP1252. Je te conseils très fortement de passer ton Eclipse, et tout tes projets, en UTF-8. Cela facilite le travail en équipe, et évite d'avoir des caractères inconnus inutiles faisant planter la compil'.

Je ne connais aucun des deux termes, je n'ai jamais vu ça Faudra que je me renseigne.

Concernant "this", il y a 2 écoles : ceux qui ne le mettent jamais sauf quand il est nécessaire. Ceux qui le mettent toujours, pour bien voir que c'est un attribut qui est manipulé. Comme tu le sens.

Ma prof me conseil de mettre this car par la suite on apprendra le php orienté objet il me semble.

Prend l'habitude de coder en anglais. Ca te facilite la compréhension de la logique du langage, et améliore ton anglais.

A vrai dire c'est ma prof qui nous faisait plein d'exemple en français...faudra que je perde cette habitude alors.

Tu en es où au niveau de ce projet ? Rendu ?

Mon tuteur n'était pas là à la fin de mon stage, je n'ai rien rendu encore, j'irai le voir en août surement.

Concernant la classe "Lire", tu pourras donner ce lien à ta prof : http://blog.developpez.com/ddelbecq/p9862/java/java-standard/supplique-aux-enseignants/

J'espère que tu sais t'en passer, et utiliser la classe Java prévue pour (Scanner).

Pour le CP1252 et l'UTF-8, ce sont des encodages (mot important), et ces deux-là, tu risques d'en entendre souvent parler
Enfin ... le premier, tu l'entendras rarement si tu ne bosses pas sous Windows ...

Pour le this, je vois l'utilité au niveau enseignement. Mais sache qu'a part ça, il n'y en a pas.
Dis-toi qu'un langage ne doit pas dicter les bonnes pratiques d'un autre, et fais comme tu le sens.

Ok pour la fin du stage.

Encore merci mille fois Bunyan, t'es super

Tu penses que je dois modifier mon programme pour corriger les erreurs ou bien jouer le jeu et le laisser tel pour rester dans le vrai de ce que j'ai fait pendant les 6 semaines ?

Je dirai : quoi tu fasses, soit honnête.
Si tu continues le développement, mentionnes-le. Fais aussi une copie "travail réalisé au bout de 6 semaines", copie que tu ne toucheras plus. Ainsi, les personnes pourront juger la différence (je pense surtout aux professeurs), et que tu ne sois pas mal jugé car tu as utilisé plus de temps qu'allouer sans prévenir.

Si tu ne le continues pas, je ne pense pas qu'on te tapes sur les doigts ou autre, mais il est possible que l'on te fasse la remarque (je ne sais pas dans quel contexte tu te trouves), donc pouvoir répondre à la question.

Bah vu que je bosse cet été je ne pense pas qu'ils me feront la remarque, je suis déjà assez occupé comme ça...

Enfin bref, je ne pense pas y toucher cet été, j'ai réussi à créer un programme qui répond aux exigences, j'en suis bien content, tout n'est pas parfait loin de là, mais vu mon niveau c'est quand même plutôt bien je trouve

Bon, merci en tout cas à vous tous qui m'avez aidé, c'est grâce à vous que j'ai pu finir ce projet dans les temps !

j'ai une question qui me trotte dans la tête. quand on developpe un programme comme j'ai fait, il vaut mieux commencer par l'interface graphique en premier temps ou non ? vu que je lai fait à la fin je me demande si j'aurai été plus efficace en la faisant au début...

Ça dépend.

Logiquement et idéalement l'interface graphique n'est que la partie visible de l'application.
Tu vas me dire que ça parait logique, sauf que ce qui l'est moins c'est de réussir à développer un programme en faisant bien la séparation UI/Core, autrement dit entre la partie graphique et la partie fonctionnelle de ton appli.

Donc le coeur de ton programme, ce qui fait les calculs etc... devrait pouvoir fonctionner avec ou sans fenêtres, boutons...
Si tu arrives à bien structurer ton code et à bien séparer les 2, que tu fasses l'interface graphique au début ou à la fin ne change rien. Après pour tester certaines fonctionnalités c'est peut-être plus facile avec un bouton ou un champ de texte c'est sûr, mais ça demande aussi plus de travail.

Personnellement, je préfère commencer par l'UI et ensuite faire la logique, en tentant de la coupler un minimum à l'UI.
Ca prends plus de temps pour avoir d'avoir des fonctionnalités, mais ça me permet d'envisager certains cas auxquels je n'aurais pas forcément pensé en faisant la fonctionnalité seule.

On peut faire sans problème la fonctionnalité, et ensuite l'UI, puis la plugger sur l'UI.

C'est plus comme toi tu vois les choses, ainsi que comment ton patron/responsable t'oblige à le faire.

Plop à tous

J'ai malheureusement besoin d'avis sur un problème auquel je ne pensais pas être confronté suite à mon programme.
J'ai voulu tester mon programme sur mon pc fixe, je l'ai donc transféré par clé usb, puis en double cliquant sur le jar, j'ai eu un message d'erreur plutôt étrange

"could not find the main class : MonPack.Fenetre. Program will exit"

J'ai donc effectué mes recherches, de ce que j'ai pu comprendre, certains éléments contenu dans le main ne serai pas reconnu...
Pourtant certains sur le forum ont pu télécharger mon programme pour le tester et aucun problème n'était à signaler
Donc quelque chose m'échappe, pourquoi chez ceux qui on testé le programme aucun problème n'a été signalé alors que chez moi sur mon pc fixe j'ai ce message d'erreur ?

(ahahah, je me marre, qui est ce qui disait que java c'est top moumoutte portable?)

megatotor, tu as certainement oublier d'inserer certaines classes dans ton fichier jar. Ils etaient probablement dans ton classpath sur ta machine de test.

Ah ça ... c'est toujours plus marrant avec les jar
Surtout dans le cadre d'un premier logiciel ("pourquoi mes images s'affichent pas ? Hein, mais pourquoi elles sont pas dans le jar alors qu'elles sont dans le projet ?").

Ouvre ton jar en tant qu'archive avec 7zip, winrar, n'importe quoi et regarde le fichier manifest, ainsi que le contenu de ton jar.
Il y a peut-être eu simplement un souci au moment de la création du jar.

Ps : je l'ai utilisé en tant que projet moi, pas en tant que jar.

Bah c'est vrai que ça m'avait signalé un problème quand j'ai créé le jar...
Je vais vous dire comment j'ai procédé, peut-être ai-je oublié une étape ?

-J'ouvre eclipse, File > Export... > Java puis Runnable JAR file > NEXT > Laucn configuration je choisi la class ayant le main, donc dans mon cas c'est "Fenetre.java" contenue dans le projet "SNCF". Export destination là je choisi l'emplacement sur le bureau par exemple. Ensuite Library handling, je garde la sélection par défaut "Package required librairies into generated JAR > Finish.

Le JAR est ensuite sur mon bureau, et il s'exécute sur mon netbook, mais quand je le test sur mon pc fixe, il manque des choses Je vois pas à quel moment je loupe une étape

Bunyan Alors j'ai regardé le fichier manifest.mf, il contient les lignes suivantes :
Manifest-Version : 1.0
Class-Path : .
Main-Class : monPack.Fenetre

Name : common
Implementation-Vendor : Oracle
Implementation-Title : MySQL Connector/J
Implementation-Version : 5.1.20
Implementation-Vendor-Id : com.mysql
Specification-Vendor : Sun Microsystems Inc.
Specification-Title : JDBC
Specification-Version 4.0

Je sais pas si il y a quelque chose à déduire de ces infos...

Sinon mon jar contient les dossiers suivant : com, META-INF, monPack, org. Il manque qqch peut-être ?

Ah et j'ai oublié de préciser dans mon post précédant, quand je créé le jar depuis eclipse, quand je fais finish, il y a une erreur "JAR export finished with warnings : Exported with compile warnings ...Joueurs.java, Questions.java et Fenetre.java" 3 erreurs de compilation sur les 3 class ? A quoi cela peut-être dû ?

Regarde les erreurs/warning généré par l'export (donc refait l'export) et résous les.

Normalement, dans ton jar, tu devrais avoir un fichier Fenetre.class dans le dossier monPack. Ca, c'est le cas normal.
Au vu de ton message d'erreur, ce fichier est absent.

Si j'ai bien le fichier Fenetre.class qui se trouve dans le dossier monPack, il y a même les 4 autres class que j'ai utilisé dans mon programme (Joueurs etc...).