Problèmes rencontrés et évolutions du projet :

Chargement dynamique des classes et Entrée/Sorties sérialisées :

Problèmes à l'exécution quand on veut jouer du son sur une machine dont la carte son n'est pas configurée (Linux)

En fait les vrais problèmes (ceux qui demandent de faire usage de son cerveau) ont commencé quand il a fallu enregistrer puis charger des simulations.

Le premier problème venait d'un problème de conception dans une des classes et du fait que les threads et les images ne sont pas des objets sérialisables, or nos plugins qui étaient sérialisables, utilisaient des objets nécessitant des threads ou des images. Ce problème a pu être réglé en modifiant les classes incriminées (en particulier la classe utils.SoundPlayer qui est passée de l'état de classe implémentant Runnable à celui de sous-classe de Thread qui implémente Serialisable).

Le deuxième problème est que nous avions prévu que l'emplacement des plugins soit libre, ne nécessitant pas que leur emplacement se trouve dans le fameux CLASSPATH. Tout marchait très bien, on chargeait les classes, on les instanciait, on enregistrait la simulation qui était prête, mais, pas moyen de charge le fichier (pour être plus précis, une exception ClassNotFoundException était levée quelque part). Ce problème a donc été résolu en rajoutant le répertoire des plugins dans le CLASSPATH de l'application. Ce problème au chargement perdure un peu sous Windows (probablement le Write once, run everywhere, en fait c'est aléatoire, des fois ça marche, d'autres...).

Un autre problème rencontré sur les machines Linux de la fac : quand on utilise un Boid comme Homer (Simpson) et que la carte son n'est pas configurée, une exception est levée (on se souvient plus du nom) qui bloque le programme.

Problèmes inhérants à JBuilder :

JBuilder, même s'il offre beaucoup de fonctionnalités nous simplifiant la vie, à une forte tendance à bouffer (désolé, nous ne voyons pas d'autre mots) les ressources et la mémoire, tant et si bien qu'il fini par se planter souvent.

Ces plantages vont du curseur de texte qui disparait à la terminaison sale (en laissant plein de JVM tourner) en passant par l'impossibilité de modifier un fichier ouvert, en fait on en revient toujours à VIM ou Emacs

La conception d'interface graphique, même si le fait de tout faire (ou presque) en WYSIWYG, pose aussi des problèmes de portabilité du à l'inclusion de packages propriétaire de Borland dont on a pas besoin, et des problèmes de performances car le code génèré n'est pas particulièrement propre (en fait, il se contente de créer tous les objets nécessaires avec leurs propriétés, mais sans se soucier d'efficacité.

Problèmes d'organisation :

C'est tout dans le titre, nous nous y sommes pris comme des pieds : nous avons commencé pendant les révisions, nous avons perdus nos vacances avec, nous nous sommes mis d'accord sur l'architecture du projet qand déjà, nous en avions deux qui étaient relativements avancées, mauvaise communication malgré les techniques par mail...

Divers, problèmes qui n'en sont pas, brefs, les inclassables :

Le JFileChooser et le Look And Feel MacOS ne font pas très bon ménage (on ne peut pas revenir en arrière dans les répertoires).

Quand on veut changer le Look And Feel de l'application (au choix: MacOS, Metal, Motif ou Win32), la modification n'affecte pas les JFileChoosers.

La fenêtre du créateur d'entité n'est créée qu'une seule fois au démarrage de l'application, ensuite elle se contente de passer du premier au second plan, afin d'éviter de devoir recréer des instances de cette fenêtre et donc d'accroitre un peu la réactivité de l'application qui n'est pas une championne de vitesse.