Discussion :

[Cube*]

Bonjour,
J'aimerais savoir quelle serait la meilleure API pour développer une application avec GUI et dessin 2D (et éventuellement 3D).
JFace à l'air de pouvoir convenir pour le dessin mais peut-on l'utiliser pour une GUI au même titre que AWT/Swing ?


Autre question (mais qui n'a rien à voir avec le GUI), quelle API permet la programmation réseau ?

Merci

[lunatix]

tes questions sont tres vagues, pas facile de repondre.

Java2D est je pense beaucoup plus complet que ce que peut apporter SWT.
disons que le standard en java c'est de developper en Swing/Java2D voir Jogl pour la 3D : apres tu peux toujours utiliser d'autres apis (QT, Gnome etc...)

sinon, pour les reseaux : meme probleme. entre le package java.net et le framework apache mina il y a un monde

[Gfx]

Swing+Java2D pour la 2D et rajoute JOGL ou Java3D/JOGL pour la 3D.

[fdesfoges]

JFace à l'air de pouvoir convenir pour le dessin

JFace ne rajoute rien pour facilité le dessin, tu peux faire de la 2d à partir d'un canvas avec swt et utilisé de la 3d. Certaines fonctions 2d ne fonctionnent pas sur toute les platformes.
Si ce que tu cherche à faire est plus dans la veine d'un outils de modélisation regarde du coté de GEF/draw2d (c'est une api pour faire des éditeur graphiques).

[iohack]

Pour la question concernant la programmation réseau, faudrait que tu nous dises ce que tu qualifies de tel car s'il s'agit de manipuler des données en TCP ou UDP via des sockets, la librairie java.net incluse par défaut dans le JDK fera l'affaire.

[Cube*]

En fait je dois faire un jeu de reversi en java qui doit être jouable en réseau (client/serveur), il me faut donc une API réseau et une API GUI qui permet le dessin 2D, et j'ai précisé éventuellement 3D car certains membres de l'équipe envisage de le faire en 3D.

[iohack]

Pour la partie client-serveur java.net conviendra parfaitement. Ce package est inclus dans la JDK.
Faudra que tu te renseignes plus précisément sur les classes ServerSocket Socket et aussi les Threads si tu veux pouvoir gérér plusieurs clients simultanément.

[Cube*]

Merci pour les info iohack

[bouye]

Si tes clients et ton serveur sont tous en Java, tu peux voir du cote de RMI (inclus dans le JDK), ce qui t'eviteras de devoir trop taper dans la couche basse reseau et de pouvoir transferer/manipuler des objets a travers le reseau.

Si tes clients et ton serveur sont dans des languages differents, tu peux rester en communication socket basique ou utiliser un protocole/type de transfert connu (HTTP, XMLRPC...) ou encore utiliser CORBA (un ORB basique est inclus dans le JDK egalement et il est possible d'en utiliser des externes. comme pour RMI de maniere a transferer/manipuler des objets a travers le reseau plutot que de simple "messages"/"paquets de donnees").

Tout depent du temps que tu veux passer a develloper la couche reseau par rapport a la gestion du jeu et a l'affichage sur les 2 types de clients. Tout est de toute maniere faisable avec de simple sockets.

[fr1man]

Pas besoin d'utiliser RMI pour faire passer des objets sur le réseau.
Une simple sérialisation le permet.
C'est très facile à faire avec de simples socket.

[bouye]

Exact j'avais oublie de preciser cet options parmi tout ce qui est disponible. Apres le tout est de savoir si on aime ou pas taper dans les protocole de bas niveau*, mais la c'est un choix que lui et son equipe devront faire eux-meme.

*Dans le sens bas niveau : il faut ecrire soit-meme le protocole de transfert et gerer soi-meme les erreurs reseaux Vs. haut-niveau on se contente de laisser le framework existant le faire et on utilises des modeles se rapprochant plus de la programmation en local. Note que les deux cotes ont des avantages et des inconvenients et je n'essaie pas d'en mettre un en avant par rapport a l'autre.

[iohack]

Gérér les erreurs réseau ? avec UDP, je suis daccord, mais en TCP, la seule erreur qui puisse intervenir est une coupure de la liaison ? on m'aurait menti ?

[bouye]

[HS]
Les erreurs dans le protocole utilise par l'application, pas celles generees dans le cadre de l'utilisation de la socket brute (tu as vise un couche trop bas). Typiquement dans mes applications distribuee je me concentre sur les gestions d'erreurs d'utilisation "normales" (comme si je programmais en local) meme s'il faut un minimum de gestion des erreurs (l'initialisation de l'ORB et la localisation du serveur principalement) et de de deco quand meme (bien sur).

Mais je ne reimplemente pas toute la partie de gestion des les erreurs de recontruction de paquets, de serialisation/deserialisation, marshalling de l'objet, etc... ou sur a quel endroit du dialogue (et de la reconstruction du message/buffer) et dans quel etat on en etait quand ca a coupe. La creation d'un protocole maison j'ai deja donne (dialogue Java <-> PERL), non-merci (mais c'est juste mon avis a moi)...

Evidement dans le cote inconvenients de RMI/CORBA il y a le fait d'avoir a utiliser des services par forcement toujours utiles. Ex : quand on est pas dans une grande entreprise ou un reseau interne tres frequente on peut largement se passer du NamingService en CORBA et utiliser des URLs Corbaloc directes pour joindre le server mais la plupart des didacticiels/implementations ignorent ou sont tres discretes sur la mise en place de cette fonctionnalite. Question stupide d'un utilisateur lambda : "pourquoi il me faut installer/configurer/utiliser un troisieme programme pour utiliser ces deux-la (sous-entendu : le serveur et le client) ?".

Par contre cela fait longtemps que je n'ai pas fait de RMI et donc j'ignore si on peut se passer du NamingService, un concept tres boulet en soit (voir citation), donc dans le cas ou on ne peut pas le shunter, passer directement des objets serialises en socket s'avere une alternative TRES TRES interessante. De plus le fait d'utiliser RMI rend tout de suite le code moins "transposable" dans un autre language (au cas ou pour une X raison il faudrai creer une version du client dans un autre language - Le probleme se pose un peu moins en CORBA car il existe des ORBs multi-platformes dispo en Java, C++, ... et qu'avec IIOP ils sont capables de se parler entre eux). Evidement s'ils restent 100% Java il ne faut pas tenir compte de ce dernier argument.

[/HS]