Question sur l'inclusion de ibrairies C...

Sylvain

28/01/2007 à 20:47

Jano wrote on 28/01/2007 16:06:

Bon, en gros, l'application est un SIG spécialisé.

Cependant, il y a 2 différences fondamentales par rapport aux SIG
existants (MapInfo etc..) :

je ne suis ni géomaticien, ni utilisateur de MapInfo, mais je vais
essayer de comprendre comme un développeur C++/Java :) quitte à
emprunter qlq mots des SIG.

a) les données échangées sont de vraies données, et non des symboles.
Le tracé symbolique vient en dernier, ce qui veut dire que dans le code
(les librairies C), les objets sont des données (double, entier, byte,
chaînes).

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre grosse
partie en C et ne sera pas non plus portée.

b) Afin de permettre la portabilité sur plusieurs GUI de manière la
plus facile possible, la FONCTIONALITE d'affichage est à l'EXTERIEUR du
GUI, et l'IHM est bien ce que son nom indique, une INTERFACE.

je comprends donc qu'une partie importante de l'abstraction (comment
représenter un ??) est fourni par le C et bien sur coder de manière
indépendante au host / à son système graphique. ici se situe
principalement la passerelle entre le C et le Java, pour finalement
permettre l'affichage.

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un portage
Java; ceci signifie bien qu'elle serait codée de manière originale à
votre existant.

à ce point, on peut revenir sur vos motivations (celle de votre client
qui demande un solution Java); selon la "forme" de cette solution, les
éléments à développer seront différents; je pense que ce point est
important pour comprendre votre besoin et ambition: on voit de plus en
plus des mini-SIG web-based dont le moteur de rendu se contente juste de
générer un GIF, des commandes flash, ..., qui seront affichés de manière
statique (jusqu'au prochain refresh et donc prochain recalcul complet ou
non).

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu (renderer)
dynamique en Java ?

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

Je vais prendre un exemple (en paraphrasant le modèle objet) :

La fenêtre d'affichage contient un bouton : "Boucle avec le temps"
Ce bouton a une méthode (callback) qui ne fait qu'appeler une routine C
indépendante du GUI (Make_Loop). Cette routine fait donc une boucle sur
le temps, et donc passe à travers les objets (récupérés via un
protocole à partir de bases de données réparties), en appelant pour
chaque objet une méthode "Draw_Objet" (là aussi en C). Cette méthode,
suivant le type d'objet, appelle par exemple la méthode "Draw_Square"
(là aussi en C). Cette méthode enfin appelle une routine dépendante du
GUI , mais dont l'interface en est indépendante (par exemple
"Draw_Line").

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin final
à partir de ses primitives (drawObject, drawSquare, ...).

si cette interface n'est pas dispo, on pourra transmettre directement un
java.awt.Graphics aux routines C mais celles-ci seront alors marquées
par le modèle d'abstraction graphique choisi coté Java (donc sûrement
moins pérenne).

package sig;

public interface GraphicsDrawer {
public abstract void drawLine(int xs, int ys, int xe, int ye);
public abstract void selectFont(String name, int size, ....);
// autres selon besoin
}

on définit ensuite une classe d'interface entre le C et la Java - selon
les considérations clients légers, interactions attendues entre ces 2
parties, cette ou ces classes pourront être fortement différentes.
prenons un cas interactif simple:

package sig;

public class SigGui {

public SigGui(){
// ...
initialize_http_SGDB_etc();
}
public void paint(GraphicsDrawer gd){
render(gd);
}

// selon besoins

// déclarations des méthodes natives
private native int initialize_http_SGDB_etc();
private native int render(GraphicsDrawer gd);

// chargement de la librairie externe lors du premier
// accès à cette class par le Java class loader.
static {
// load sig_native.dll ou sig_native.o ou ?...
System.loadLibrary("sig_native");
}
}

où "initialize_http_SGDB_etc" initialiserait ce qui doit l'être coté C.
et "render" fournirait la callback "Make_Loop".

l'interface des natives est alors créé avec le tool javah à partir de
cette classe SigGui:

% javah -jni -classpath %classRoot% sig.SigGui

on obtient un fichier sig_SigGui.h, il ne reste plus qu'à coder les
fonctions en respectant les prototypes - et en s'aidant de jni.h pour
convertir les types, appeler les méthodes Java, etc:

soit par exemple en C++ (le pendant exact existe en C, Cf jni.h)

JNIEXPORT jint JNICALL Java_sig_SigGui_render
(JNIEnv* env, jobject instance, jobject drawer)
{
// get class of drawer instance
jclass gdClass = env->GetObjectClass(drawer);
// gain acces to the drawLine (IIII)V method of the interface
jmethodID methodID = env->GetMethodID(
gdClass, "drawLine", "(IIII)V");

// selon représentation interne:
// for each item to be drawn
// - get it, update it position, etc

// - get actual geometry or used dedicated C callbacks
long xs, ys, xe, ye; // si x86, ie sizeof(long) == 4

// finally call 'drawLine' of 'drawer'
env->CallVoidMethod(drawer, methodID, xs, ys, xe, ye);
// end for
}

Donc le GUI est utilisé pour :
1) présenter les choix accessibles à l'utilisateur

à implémenter (dessiner) en AWT ou Swing ou ...

2) appeler la fonctionalité requise (en C)

définir les méthodes requises et implémenter les wrappers d'appels (à
l'image de 'initialize_http_SGDB_etc'

3) tracer le graphisme à l'écran, à l'intérieur de la fenêtre du GUI
utilisé (sous forme de bibliothèque de fonctions élémentaires du style
"Set_Font", "Draw_Line", "Draw_bitmap", "Set_Color", etc..).

selon un modèle AWT, le composant target rendant le tracé complet peut
être une classe dérivée java.awt.Component (ou une autre si Swing, ...)
on utilise dans tous les cas l'interface (sens Java) d'interface (sens
commun) GraphicsDrawer pour s'affranchir de ce point, par exemple:

public class AwtGraphicsDrawer implements GraphicsDrawer {
// données membres et initialisation interne
protected java.awt.Graphics g;
public AwtGraphicsDrawer(java.awt.Graphics g){
this.g = g;
}
// implement GraphicsDrawer
public void drawLine(int xs, int ys, int xe, int ye){
g.drawLine(xs, ys, xe, ye);
}
}

permettrait:

public class SigComponent extends java.awt.Component {
// connexion au moteur C
protected SigGui sigGui;
public void setSigGui(SigGui gui){ sigGui = gui; }

// rendu du composant
public paint(Graphics g){
GraphicsDrawer gd = new GraphicsDrawer(g);
sigGui.render(gd);
}
}

AUCUN code de fonctionalité ne figure à l'intérieur du code du GUI.

ceci peut être conservé.

ce que je voulais dire, c'est que du coup, il y a des allers-retours
entre la fonctionalité C et le GUI. Et donc, si il faut dynamiquement
charger un DLL régulièrement, possibilité d'overhead excessif.

le chargement est fait une seule fois, l'overhead est insignifiant pour
l'appel, les accès additionnels (conversion de types, appels croisés,
...) fait depuis le C dépendent de ce que ces routines devront utilisés;
à l'époque de trucs managés le marshalling de Java / JNI est loin d'être
le pire (il est concrètement non pénalisant).

le GUI Java interrogera les structures C++ ou le code C++ trigerra
des méthodes Java destinés à rafraichir la représentation.

Voir remarque ci-dessus. Je pense effectvement à cette solution, mais
je me pose la question de l'overhead.

les problèmes liés aux perfs s'adresseront via soit un codage avec les
API UI Java existantes (certaines sont critiqués pour leur lenteur comme
Swing, d'autres un peu buggée comme AWT; ces critiques sont soit
partisanes, soit trop génériques), soit via un driver OpenGL ou DirectX
impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non significatif,
dans le second cas on ne parle plus d'un projet Java (ou si peu).

notez que vous pouvez également faire communiquer ces 2 parties
(moteur faceless C++ et GUI Java via un socket idoine, vous vous
épargnerez alors les classes Java avec natives et le wrapper JNI au
prix d'un format d'échanges de trames.

Très intéressant. J'aimerais si possible avoir plus de précisions..
Comment pourrais-t-on faire ? Auriez-vous un exemple, ou un lien
expliquant ?

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

b) si par contre la gestion même du GUI est le goulot d'étranglement,
Java peut (selon API d'abstraction, CPU, ...) ne pas offrir les
performances voulues, [...] un portage C++ de votre code sous
windows est donc surement également possible

Oui aujourdh'hui j'utilise un serveur X et librairies X/Motif sur
Unix/Linux. J'ai également pensé à C++. Cela semble effectivement
possible (par exemple avec cygwin pour la partie C). Cependant, dans ce
cas, les compilateurs que j'ai regardé à l'heure actuelle (DevC++,
CodeBlocks, VS Express) ne contiennent pas tout (en particulier les
signaux, les timers et les sockets) qui sont la base de la
communication de données entre les serveurs et les applications.

cygwin est sûrement le meilleur environnement pour reprendre un projet
unix, il permettra de faire la librairie externe contenant les natives
Java; comme un serveur d'images prêtes-à-afficher si c'est l'option.

(puisque par exemple sous cygwin il existe un serveur X mais pas Motif).

depuis que les UI se multiplient sous linux, j'ai l'impression que les
approches non propriétaires sont moins supportés / vivantes ... autre
débat pour lequel je suis ni pertinent, ni compétent.

Donc une question subsidiaire est : est-il possible d'attacher à un
projet Java (puisque nous sommes dans le groupe Java, mais la question
est aussi valable pour Visual Express) une librairie statique
(éventuellement dynamique) compilée pour Windows mais créée par exemple
avec cygwin ?

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Sylvain.

Jano wrote on 28/01/2007 16:06:

Bon, en gros, l'application est un SIG spécialisé.

Cependant, il y a 2 différences fondamentales par rapport aux SIG
existants (MapInfo etc..) :

je ne suis ni géomaticien, ni utilisateur de MapInfo, mais je vais
essayer de comprendre comme un développeur C++/Java :) quitte à
emprunter qlq mots des SIG.

a) les données échangées sont de vraies données, et non des symboles.
Le tracé symbolique vient en dernier, ce qui veut dire que dans le code
(les librairies C), les objets sont des données (double, entier, byte,
chaînes).

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre grosse
partie en C et ne sera pas non plus portée.

b) Afin de permettre la portabilité sur plusieurs GUI de manière la
plus facile possible, la FONCTIONALITE d'affichage est à l'EXTERIEUR du
GUI, et l'IHM est bien ce que son nom indique, une INTERFACE.

je comprends donc qu'une partie importante de l'abstraction (comment
représenter un ??) est fourni par le C et bien sur coder de manière
indépendante au host / à son système graphique. ici se situe
principalement la passerelle entre le C et le Java, pour finalement
permettre l'affichage.

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un portage
Java; ceci signifie bien qu'elle serait codée de manière originale à
votre existant.

à ce point, on peut revenir sur vos motivations (celle de votre client
qui demande un solution Java); selon la "forme" de cette solution, les
éléments à développer seront différents; je pense que ce point est
important pour comprendre votre besoin et ambition: on voit de plus en
plus des mini-SIG web-based dont le moteur de rendu se contente juste de
générer un GIF, des commandes flash, ..., qui seront affichés de manière
statique (jusqu'au prochain refresh et donc prochain recalcul complet ou
non).

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu (renderer)
dynamique en Java ?

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

Je vais prendre un exemple (en paraphrasant le modèle objet) :

La fenêtre d'affichage contient un bouton : "Boucle avec le temps"
Ce bouton a une méthode (callback) qui ne fait qu'appeler une routine C
indépendante du GUI (Make_Loop). Cette routine fait donc une boucle sur
le temps, et donc passe à travers les objets (récupérés via un
protocole à partir de bases de données réparties), en appelant pour
chaque objet une méthode "Draw_Objet" (là aussi en C). Cette méthode,
suivant le type d'objet, appelle par exemple la méthode "Draw_Square"
(là aussi en C). Cette méthode enfin appelle une routine dépendante du
GUI , mais dont l'interface en est indépendante (par exemple
"Draw_Line").

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin final
à partir de ses primitives (drawObject, drawSquare, ...).

si cette interface n'est pas dispo, on pourra transmettre directement un
java.awt.Graphics aux routines C mais celles-ci seront alors marquées
par le modèle d'abstraction graphique choisi coté Java (donc sûrement
moins pérenne).

package sig;

public interface GraphicsDrawer {
public abstract void drawLine(int xs, int ys, int xe, int ye);
public abstract void selectFont(String name, int size, ....);
// autres selon besoin
}

on définit ensuite une classe d'interface entre le C et la Java - selon
les considérations clients légers, interactions attendues entre ces 2
parties, cette ou ces classes pourront être fortement différentes.
prenons un cas interactif simple:

package sig;

public class SigGui {

public SigGui(){
// ...
initialize_http_SGDB_etc();
}
public void paint(GraphicsDrawer gd){
render(gd);
}

// selon besoins

// déclarations des méthodes natives
private native int initialize_http_SGDB_etc();
private native int render(GraphicsDrawer gd);

// chargement de la librairie externe lors du premier
// accès à cette class par le Java class loader.
static {
// load sig_native.dll ou sig_native.o ou ?...
System.loadLibrary("sig_native");
}
}

où "initialize_http_SGDB_etc" initialiserait ce qui doit l'être coté C.
et "render" fournirait la callback "Make_Loop".

l'interface des natives est alors créé avec le tool javah à partir de
cette classe SigGui:

% javah -jni -classpath %classRoot% sig.SigGui

on obtient un fichier sig_SigGui.h, il ne reste plus qu'à coder les
fonctions en respectant les prototypes - et en s'aidant de jni.h pour
convertir les types, appeler les méthodes Java, etc:

soit par exemple en C++ (le pendant exact existe en C, Cf jni.h)

JNIEXPORT jint JNICALL Java_sig_SigGui_render
(JNIEnv* env, jobject instance, jobject drawer)
{
// get class of drawer instance
jclass gdClass = env->GetObjectClass(drawer);
// gain acces to the drawLine (IIII)V method of the interface
jmethodID methodID = env->GetMethodID(
gdClass, "drawLine", "(IIII)V");

// selon représentation interne:
// for each item to be drawn
// - get it, update it position, etc

// - get actual geometry or used dedicated C callbacks
long xs, ys, xe, ye; // si x86, ie sizeof(long) == 4

// finally call 'drawLine' of 'drawer'
env->CallVoidMethod(drawer, methodID, xs, ys, xe, ye);
// end for
}

Donc le GUI est utilisé pour :
1) présenter les choix accessibles à l'utilisateur

à implémenter (dessiner) en AWT ou Swing ou ...

2) appeler la fonctionalité requise (en C)

définir les méthodes requises et implémenter les wrappers d'appels (à
l'image de 'initialize_http_SGDB_etc'

3) tracer le graphisme à l'écran, à l'intérieur de la fenêtre du GUI
utilisé (sous forme de bibliothèque de fonctions élémentaires du style
"Set_Font", "Draw_Line", "Draw_bitmap", "Set_Color", etc..).

selon un modèle AWT, le composant target rendant le tracé complet peut
être une classe dérivée java.awt.Component (ou une autre si Swing, ...)
on utilise dans tous les cas l'interface (sens Java) d'interface (sens
commun) GraphicsDrawer pour s'affranchir de ce point, par exemple:

public class AwtGraphicsDrawer implements GraphicsDrawer {
// données membres et initialisation interne
protected java.awt.Graphics g;
public AwtGraphicsDrawer(java.awt.Graphics g){
this.g = g;
}
// implement GraphicsDrawer
public void drawLine(int xs, int ys, int xe, int ye){
g.drawLine(xs, ys, xe, ye);
}
}

permettrait:

public class SigComponent extends java.awt.Component {
// connexion au moteur C
protected SigGui sigGui;
public void setSigGui(SigGui gui){ sigGui = gui; }

// rendu du composant
public paint(Graphics g){
GraphicsDrawer gd = new GraphicsDrawer(g);
sigGui.render(gd);
}
}

AUCUN code de fonctionalité ne figure à l'intérieur du code du GUI.

ceci peut être conservé.

ce que je voulais dire, c'est que du coup, il y a des allers-retours
entre la fonctionalité C et le GUI. Et donc, si il faut dynamiquement
charger un DLL régulièrement, possibilité d'overhead excessif.

le chargement est fait une seule fois, l'overhead est insignifiant pour
l'appel, les accès additionnels (conversion de types, appels croisés,
...) fait depuis le C dépendent de ce que ces routines devront utilisés;
à l'époque de trucs managés le marshalling de Java / JNI est loin d'être
le pire (il est concrètement non pénalisant).

le GUI Java interrogera les structures C++ ou le code C++ trigerra
des méthodes Java destinés à rafraichir la représentation.

Voir remarque ci-dessus. Je pense effectvement à cette solution, mais
je me pose la question de l'overhead.

les problèmes liés aux perfs s'adresseront via soit un codage avec les
API UI Java existantes (certaines sont critiqués pour leur lenteur comme
Swing, d'autres un peu buggée comme AWT; ces critiques sont soit
partisanes, soit trop génériques), soit via un driver OpenGL ou DirectX
impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non significatif,
dans le second cas on ne parle plus d'un projet Java (ou si peu).

notez que vous pouvez également faire communiquer ces 2 parties
(moteur faceless C++ et GUI Java via un socket idoine, vous vous
épargnerez alors les classes Java avec natives et le wrapper JNI au
prix d'un format d'échanges de trames.

Très intéressant. J'aimerais si possible avoir plus de précisions..
Comment pourrais-t-on faire ? Auriez-vous un exemple, ou un lien
expliquant ?

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

b) si par contre la gestion même du GUI est le goulot d'étranglement,
Java peut (selon API d'abstraction, CPU, ...) ne pas offrir les
performances voulues, [...] un portage C++ de votre code sous
windows est donc surement également possible

Oui aujourdh'hui j'utilise un serveur X et librairies X/Motif sur
Unix/Linux. J'ai également pensé à C++. Cela semble effectivement
possible (par exemple avec cygwin pour la partie C). Cependant, dans ce
cas, les compilateurs que j'ai regardé à l'heure actuelle (DevC++,
CodeBlocks, VS Express) ne contiennent pas tout (en particulier les
signaux, les timers et les sockets) qui sont la base de la
communication de données entre les serveurs et les applications.

cygwin est sûrement le meilleur environnement pour reprendre un projet
unix, il permettra de faire la librairie externe contenant les natives
Java; comme un serveur d'images prêtes-à-afficher si c'est l'option.

(puisque par exemple sous cygwin il existe un serveur X mais pas Motif).

depuis que les UI se multiplient sous linux, j'ai l'impression que les
approches non propriétaires sont moins supportés / vivantes ... autre
débat pour lequel je suis ni pertinent, ni compétent.

Donc une question subsidiaire est : est-il possible d'attacher à un
projet Java (puisque nous sommes dans le groupe Java, mais la question
est aussi valable pour Visual Express) une librairie statique
(éventuellement dynamique) compilée pour Windows mais créée par exemple
avec cygwin ?

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

Jano wrote on 28/01/2007 16:06:

Bon, en gros, l'application est un SIG spécialisé.

Cependant, il y a 2 différences fondamentales par rapport aux SIG
existants (MapInfo etc..) :

je ne suis ni géomaticien, ni utilisateur de MapInfo, mais je vais
essayer de comprendre comme un développeur C++/Java :) quitte à
emprunter qlq mots des SIG.

a) les données échangées sont de vraies données, et non des symboles.
Le tracé symbolique vient en dernier, ce qui veut dire que dans le code
(les librairies C), les objets sont des données (double, entier, byte,
chaînes).

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre grosse
partie en C et ne sera pas non plus portée.

b) Afin de permettre la portabilité sur plusieurs GUI de manière la
plus facile possible, la FONCTIONALITE d'affichage est à l'EXTERIEUR du
GUI, et l'IHM est bien ce que son nom indique, une INTERFACE.

je comprends donc qu'une partie importante de l'abstraction (comment
représenter un ??) est fourni par le C et bien sur coder de manière
indépendante au host / à son système graphique. ici se situe
principalement la passerelle entre le C et le Java, pour finalement
permettre l'affichage.

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un portage
Java; ceci signifie bien qu'elle serait codée de manière originale à
votre existant.

à ce point, on peut revenir sur vos motivations (celle de votre client
qui demande un solution Java); selon la "forme" de cette solution, les
éléments à développer seront différents; je pense que ce point est
important pour comprendre votre besoin et ambition: on voit de plus en
plus des mini-SIG web-based dont le moteur de rendu se contente juste de
générer un GIF, des commandes flash, ..., qui seront affichés de manière
statique (jusqu'au prochain refresh et donc prochain recalcul complet ou
non).

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu (renderer)
dynamique en Java ?

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

Je vais prendre un exemple (en paraphrasant le modèle objet) :

La fenêtre d'affichage contient un bouton : "Boucle avec le temps"
Ce bouton a une méthode (callback) qui ne fait qu'appeler une routine C
indépendante du GUI (Make_Loop). Cette routine fait donc une boucle sur
le temps, et donc passe à travers les objets (récupérés via un
protocole à partir de bases de données réparties), en appelant pour
chaque objet une méthode "Draw_Objet" (là aussi en C). Cette méthode,
suivant le type d'objet, appelle par exemple la méthode "Draw_Square"
(là aussi en C). Cette méthode enfin appelle une routine dépendante du
GUI , mais dont l'interface en est indépendante (par exemple
"Draw_Line").

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin final
à partir de ses primitives (drawObject, drawSquare, ...).

si cette interface n'est pas dispo, on pourra transmettre directement un
java.awt.Graphics aux routines C mais celles-ci seront alors marquées
par le modèle d'abstraction graphique choisi coté Java (donc sûrement
moins pérenne).

package sig;

public interface GraphicsDrawer {
public abstract void drawLine(int xs, int ys, int xe, int ye);
public abstract void selectFont(String name, int size, ....);
// autres selon besoin
}

on définit ensuite une classe d'interface entre le C et la Java - selon
les considérations clients légers, interactions attendues entre ces 2
parties, cette ou ces classes pourront être fortement différentes.
prenons un cas interactif simple:

package sig;

public class SigGui {

public SigGui(){
// ...
initialize_http_SGDB_etc();
}
public void paint(GraphicsDrawer gd){
render(gd);
}

// selon besoins

// déclarations des méthodes natives
private native int initialize_http_SGDB_etc();
private native int render(GraphicsDrawer gd);

// chargement de la librairie externe lors du premier
// accès à cette class par le Java class loader.
static {
// load sig_native.dll ou sig_native.o ou ?...
System.loadLibrary("sig_native");
}
}

où "initialize_http_SGDB_etc" initialiserait ce qui doit l'être coté C.
et "render" fournirait la callback "Make_Loop".

l'interface des natives est alors créé avec le tool javah à partir de
cette classe SigGui:

% javah -jni -classpath %classRoot% sig.SigGui

on obtient un fichier sig_SigGui.h, il ne reste plus qu'à coder les
fonctions en respectant les prototypes - et en s'aidant de jni.h pour
convertir les types, appeler les méthodes Java, etc:

soit par exemple en C++ (le pendant exact existe en C, Cf jni.h)

JNIEXPORT jint JNICALL Java_sig_SigGui_render
(JNIEnv* env, jobject instance, jobject drawer)
{
// get class of drawer instance
jclass gdClass = env->GetObjectClass(drawer);
// gain acces to the drawLine (IIII)V method of the interface
jmethodID methodID = env->GetMethodID(
gdClass, "drawLine", "(IIII)V");

// selon représentation interne:
// for each item to be drawn
// - get it, update it position, etc

// - get actual geometry or used dedicated C callbacks
long xs, ys, xe, ye; // si x86, ie sizeof(long) == 4

// finally call 'drawLine' of 'drawer'
env->CallVoidMethod(drawer, methodID, xs, ys, xe, ye);
// end for
}

Donc le GUI est utilisé pour :
1) présenter les choix accessibles à l'utilisateur

à implémenter (dessiner) en AWT ou Swing ou ...

2) appeler la fonctionalité requise (en C)

définir les méthodes requises et implémenter les wrappers d'appels (à
l'image de 'initialize_http_SGDB_etc'

3) tracer le graphisme à l'écran, à l'intérieur de la fenêtre du GUI
utilisé (sous forme de bibliothèque de fonctions élémentaires du style
"Set_Font", "Draw_Line", "Draw_bitmap", "Set_Color", etc..).

selon un modèle AWT, le composant target rendant le tracé complet peut
être une classe dérivée java.awt.Component (ou une autre si Swing, ...)
on utilise dans tous les cas l'interface (sens Java) d'interface (sens
commun) GraphicsDrawer pour s'affranchir de ce point, par exemple:

public class AwtGraphicsDrawer implements GraphicsDrawer {
// données membres et initialisation interne
protected java.awt.Graphics g;
public AwtGraphicsDrawer(java.awt.Graphics g){
this.g = g;
}
// implement GraphicsDrawer
public void drawLine(int xs, int ys, int xe, int ye){
g.drawLine(xs, ys, xe, ye);
}
}

permettrait:

public class SigComponent extends java.awt.Component {
// connexion au moteur C
protected SigGui sigGui;
public void setSigGui(SigGui gui){ sigGui = gui; }

// rendu du composant
public paint(Graphics g){
GraphicsDrawer gd = new GraphicsDrawer(g);
sigGui.render(gd);
}
}

AUCUN code de fonctionalité ne figure à l'intérieur du code du GUI.

ceci peut être conservé.

ce que je voulais dire, c'est que du coup, il y a des allers-retours
entre la fonctionalité C et le GUI. Et donc, si il faut dynamiquement
charger un DLL régulièrement, possibilité d'overhead excessif.

le chargement est fait une seule fois, l'overhead est insignifiant pour
l'appel, les accès additionnels (conversion de types, appels croisés,
...) fait depuis le C dépendent de ce que ces routines devront utilisés;
à l'époque de trucs managés le marshalling de Java / JNI est loin d'être
le pire (il est concrètement non pénalisant).

le GUI Java interrogera les structures C++ ou le code C++ trigerra
des méthodes Java destinés à rafraichir la représentation.

Voir remarque ci-dessus. Je pense effectvement à cette solution, mais
je me pose la question de l'overhead.

les problèmes liés aux perfs s'adresseront via soit un codage avec les
API UI Java existantes (certaines sont critiqués pour leur lenteur comme
Swing, d'autres un peu buggée comme AWT; ces critiques sont soit
partisanes, soit trop génériques), soit via un driver OpenGL ou DirectX
impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non significatif,
dans le second cas on ne parle plus d'un projet Java (ou si peu).

notez que vous pouvez également faire communiquer ces 2 parties
(moteur faceless C++ et GUI Java via un socket idoine, vous vous
épargnerez alors les classes Java avec natives et le wrapper JNI au
prix d'un format d'échanges de trames.

Très intéressant. J'aimerais si possible avoir plus de précisions..
Comment pourrais-t-on faire ? Auriez-vous un exemple, ou un lien
expliquant ?

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

b) si par contre la gestion même du GUI est le goulot d'étranglement,
Java peut (selon API d'abstraction, CPU, ...) ne pas offrir les
performances voulues, [...] un portage C++ de votre code sous
windows est donc surement également possible

Oui aujourdh'hui j'utilise un serveur X et librairies X/Motif sur
Unix/Linux. J'ai également pensé à C++. Cela semble effectivement
possible (par exemple avec cygwin pour la partie C). Cependant, dans ce
cas, les compilateurs que j'ai regardé à l'heure actuelle (DevC++,
CodeBlocks, VS Express) ne contiennent pas tout (en particulier les
signaux, les timers et les sockets) qui sont la base de la
communication de données entre les serveurs et les applications.

cygwin est sûrement le meilleur environnement pour reprendre un projet
unix, il permettra de faire la librairie externe contenant les natives
Java; comme un serveur d'images prêtes-à-afficher si c'est l'option.

(puisque par exemple sous cygwin il existe un serveur X mais pas Motif).

depuis que les UI se multiplient sous linux, j'ai l'impression que les
approches non propriétaires sont moins supportés / vivantes ... autre
débat pour lequel je suis ni pertinent, ni compétent.

Donc une question subsidiaire est : est-il possible d'attacher à un
projet Java (puisque nous sommes dans le groupe Java, mais la question
est aussi valable pour Visual Express) une librairie statique
(éventuellement dynamique) compilée pour Windows mais créée par exemple
avec cygwin ?

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Sylvain.

Jano

29/01/2007 à 11:41

Bon je n'ai pas tout compris techniquement (puisque je n'a que 3 jours
de "frottement" avec Java, mais je comprend l'esprit... et je garde
précieusement votre exemple...

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, mais un
ensemble, et pour reprendre le langage objet, on peut dire qu'elles
dérivent d'une classe "appli sig", dont une méthode ("Cree_IHM")
possède une API indépendante de l'outil utilisé, et vu la structure
utilisée pour la construction de l'IHM exposée ci-dessus, permet
effectivement de construire des applications dont la fonctionalité est
commune, même la fonctionalité d'IHM, mais dont l'implantation est
déterminée à l'édition de liens uniquement.

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe :

en temps réel c'est une fois par seconde
en boucle, l'idéal est > 120 par seconde (une heure de temps
devrait boucler au moins en 30 secondes). Sur mon portable avec
Linux/Motif je monte à environ 900 fois par seconde (1 heure met 4
secondes à défiler).

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.
Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.
(C'est une organisation gouvernementale civile, mais avec une
liaison directe avec la sécurité civile (ce que je disais au début,
fermetures d'aéroports, évacuation d'usines, etc..)).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

Sylvain wrote:

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

OUI

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre
grosse partie en C et ne sera pas non plus portée.

OUI

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un
portage Java; ceci signifie bien qu'elle serait codée de manière
originale à votre existant.

OUI

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu
(renderer) dynamique en Java ?

2ième solution..

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin
final à partir de ses primitives (drawObject, drawSquare, ...).

OUI

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

le chargement est fait une seule fois, l'overhead est insignifiant
pour l'appel, les accès additionnels (conversion de types, appels
croisés, ...) fait depuis le C dépendent de ce que ces routines
devront utilisés; à l'époque de trucs managés le marshalling de Java
/ JNI est loin d'être le pire (il est concrètement non pénalisant).

OK

les problèmes liés aux perfs s'adresseront via soit un codage avec
les API UI Java existantes (certaines sont critiqués pour leur
lenteur comme Swing, d'autres un peu buggée comme AWT; ces critiques
sont soit partisanes, soit trop génériques), soit via un driver
OpenGL ou DirectX impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non
significatif, dans le second cas on ne parle plus d'un projet Java
(ou si peu).

OUI et comme j'ai déjà assez de travail et de langages comme ça, je
ne prendrait qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd... Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?
A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

Jano

Bon je n'ai pas tout compris techniquement (puisque je n'a que 3 jours
de "frottement" avec Java, mais je comprend l'esprit... et je garde
précieusement votre exemple...

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, mais un
ensemble, et pour reprendre le langage objet, on peut dire qu'elles
dérivent d'une classe "appli sig", dont une méthode ("Cree_IHM")
possède une API indépendante de l'outil utilisé, et vu la structure
utilisée pour la construction de l'IHM exposée ci-dessus, permet
effectivement de construire des applications dont la fonctionalité est
commune, même la fonctionalité d'IHM, mais dont l'implantation est
déterminée à l'édition de liens uniquement.

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe :

en temps réel c'est une fois par seconde
en boucle, l'idéal est > 120 par seconde (une heure de temps
devrait boucler au moins en 30 secondes). Sur mon portable avec
Linux/Motif je monte à environ 900 fois par seconde (1 heure met 4
secondes à défiler).

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.
Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.
(C'est une organisation gouvernementale civile, mais avec une
liaison directe avec la sécurité civile (ce que je disais au début,
fermetures d'aéroports, évacuation d'usines, etc..)).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

Sylvain wrote:

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

OUI

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre
grosse partie en C et ne sera pas non plus portée.

OUI

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un
portage Java; ceci signifie bien qu'elle serait codée de manière
originale à votre existant.

OUI

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu
(renderer) dynamique en Java ?

2ième solution..

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin
final à partir de ses primitives (drawObject, drawSquare, ...).

OUI

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

le chargement est fait une seule fois, l'overhead est insignifiant
pour l'appel, les accès additionnels (conversion de types, appels
croisés, ...) fait depuis le C dépendent de ce que ces routines
devront utilisés; à l'époque de trucs managés le marshalling de Java
/ JNI est loin d'être le pire (il est concrètement non pénalisant).

OK

les problèmes liés aux perfs s'adresseront via soit un codage avec
les API UI Java existantes (certaines sont critiqués pour leur
lenteur comme Swing, d'autres un peu buggée comme AWT; ces critiques
sont soit partisanes, soit trop génériques), soit via un driver
OpenGL ou DirectX impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non
significatif, dans le second cas on ne parle plus d'un projet Java
(ou si peu).

OUI et comme j'ai déjà assez de travail et de langages comme ça, je
ne prendrait qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd... Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?
A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

Jano

Vous avez filtré cet utilisateur ! Consultez son message

Bon je n'ai pas tout compris techniquement (puisque je n'a que 3 jours
de "frottement" avec Java, mais je comprend l'esprit... et je garde
précieusement votre exemple...

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, mais un
ensemble, et pour reprendre le langage objet, on peut dire qu'elles
dérivent d'une classe "appli sig", dont une méthode ("Cree_IHM")
possède une API indépendante de l'outil utilisé, et vu la structure
utilisée pour la construction de l'IHM exposée ci-dessus, permet
effectivement de construire des applications dont la fonctionalité est
commune, même la fonctionalité d'IHM, mais dont l'implantation est
déterminée à l'édition de liens uniquement.

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe :

en temps réel c'est une fois par seconde
en boucle, l'idéal est > 120 par seconde (une heure de temps
devrait boucler au moins en 30 secondes). Sur mon portable avec
Linux/Motif je monte à environ 900 fois par seconde (1 heure met 4
secondes à défiler).

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.
Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.
(C'est une organisation gouvernementale civile, mais avec une
liaison directe avec la sécurité civile (ce que je disais au début,
fermetures d'aéroports, évacuation d'usines, etc..)).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

Sylvain wrote:

j'imagine - vous l'avez présenté comme cela - que l'acquisition et
l'archivage sont gérés par une des couches C, sa recompilation C sous
env. win32/64 devra être réglée mais on ne parle pas de portage Java.

OUI

l'analyse des évènements en cours (temps qui passe) et des events
induits par l'utilisateur ("et si ...") occupe sûrement une autre
grosse partie en C et ne sera pas non plus portée.

OUI

l'interface utilisateur elle-même (boutons de contrôles, saisies de
paramètres) serait sûrement 100% pure Java, dans le cadre d'un
portage Java; ceci signifie bien qu'elle serait codée de manière
originale à votre existant.

OUI

exprimé autrement: est-ce que votre client cherche une solution de
visualisation en Java pour la déployer sur N consoles / terminaux /
clients légers Java ? ou parle-t-on d'un vrai moteur de rendu
(renderer) dynamique en Java ?

2ième solution..

dans le premier cas, le C exportera peu de choses, qlq statiques pour
paramétrer et récupérer le nouveau dessin; dans le second cas vous
devrez manipuler depuis Java les grands items du moteur (accès aux
collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

dans une variante partagée entre C et Java cela pourrait donner:

une interface optionelle de tracé en Java qui sera construite et/ou
initialisé avec une instance de Graphics (l'exemple vaut pour un code
AWT, il sera différent pour Swing mais la logique sera la même)

cette interface sera communiquée au C pour qu'il réalise le dessin
final à partir de ses primitives (drawObject, drawSquare, ...).

OUI

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

le chargement est fait une seule fois, l'overhead est insignifiant
pour l'appel, les accès additionnels (conversion de types, appels
croisés, ...) fait depuis le C dépendent de ce que ces routines
devront utilisés; à l'époque de trucs managés le marshalling de Java
/ JNI est loin d'être le pire (il est concrètement non pénalisant).

OK

les problèmes liés aux perfs s'adresseront via soit un codage avec
les API UI Java existantes (certaines sont critiqués pour leur
lenteur comme Swing, d'autres un peu buggée comme AWT; ces critiques
sont soit partisanes, soit trop génériques), soit via un driver
OpenGL ou DirectX impliquant un hard (carte graphique) spéciale.

dans le premier cas, l'overhead d'appel Java<->C est non
significatif, dans le second cas on ne parle plus d'un projet Java
(ou si peu).

OUI et comme j'ai déjà assez de travail et de langages comme ça, je
ne prendrait qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd... Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?
A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

Jano

Jano

29/01/2007 à 11:43

denebet wrote:

Qt est pas mal pour la compatibilité Linux et Windows, en plus cela
s'interface facilement sur des libs en C.

Alain

Avez-vous une bonne réference là-dessus s'il vous plaît ?

Est-ce juste un enrobage de code ?

Jano

29/01/2007 à 11:45

schtroumpf wrote:

je te recommande de faire un tour sur http://www.swig.org/

bye,

samuel

OK Merci.. je n'avais pas compris. Je m'excuse pour cette question de
Newbie... :-( :-)

denebet

29/01/2007 à 12:31

Jano wrote:

denebet wrote:

Qt est pas mal pour la compatibilité Linux et Windows, en plus cela
s'interface facilement sur des libs en C.

Alain

Avez-vous une bonne réference là-dessus s'il vous plaît ?

Est-ce juste un enrobage de code ?

Je ne comprends pas la question. Il me semblait que vous souhaitiez modifier
uniquement la GUI?
Vous pouvez utiliser QT uniquement pour la GUI avec l'avantage sur java
d'être natif et que l'interface C++/lib C est plus facile à gérer.
Vous pouvez aussi utiliser les classes non-gui de Qt, vous devrez alors
modifier votre code mais ce sera le même sous Win et Linux (et MacOs X).
Par contre QT en version non GPL coûte bonbon.
www.trolltech.com

alain

Sylvain

29/01/2007 à 13:04

Jano wrote on 29/01/2007 11:41:

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, [...]

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

OK.

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe : [...]

si je trouve 5 mn je ferais qlq benckmarch avec vos ordres de grandeur
pour le nombre d'objets.

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous linux
(ou lieu de PC sous Windows et à la place des stations actuelles), pour
le reste vous (et vous seul) devrez vous acquitter de licences pour les
outils de dev. M$ (un compilo free ne me parait pas pérenne, ni
rentable: perte de temps plus importante que gain initial)

Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.

Windows se mets à jour sans arrêt mais une application pour Windows peut
très bien vivre de nombreuses années ("subissant" sans effet, sauf cas
rare, les mises à jour du système).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

c'est une approche possible; elle permettra de prototyper / valider
l'interface (pour ce qu'elle pourrait avoir de Windows spécifique)
rapidement.

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes des
sources d'objets, d'events, etc).
dans votre version actuelle - basée sur des lib. statiques - vont
accéder directement pour chaque besoin à un extern d'un des modules;
avec une interface Java vous devrez définir / implémenter des accessors
(getXX / setXX) pour chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ??
dans ce cas; il faudra 8000 wrapper Java<->C, ie 8000 méthodes déclarées
native en Java et implémentés en C pour appeler la méthode
correspondante de la lib.

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels à
un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes.
les 2 plus classiques fournis par SUN sont AWT (abstract window toolkit)
présent depuis Java 1.0, revisité en 1.1 (ça date mais c'est toujours
présent et fonctionnel), et Swing qui a démarré comme un add-on et qui
est intégré depuis Java 2.0
java.awt.Graphics est la classe de base du système graphique de AWT,
elle définit toutes les primitives de tracé (en autres) que vous
pourriez utiliser.

OUI et comme j'ai déjà assez de travail et de langages comme ça

il faut vous faire aider ! sous-traiter donc une partie du travail ;)

je ne prendrais qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage d'un
second outil c'est que celui-ci est mauvais et ne devrait pas être retenu.
Eclipse me parait un bon choix pour la partie Java; un environnement
Visual Studio me parait indiqué pour la partie C/C++ - oui, il existe un
plug-in GNU C/C++ pour Eclipse, non il n'est pas comparable à Studio.

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives Draw_Line,
etc); ces primitives aujourd'hui "externes" (apportées statiquement par
le module d'interface) seraient implémentés dans un nouveau module
implémentant une communication socket.

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que cela
représente une charge importante. (fr.comp.lang.c si besoin).

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un langage
statique (ne repose pas sur une définition statique du code).

A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

dans le meilleur des cas, vous aurez un .jar (fichier archive) qui
regroupera les dizaines, centaines, de classes (.class) constituant
votre projet et une DLL externe - je ne connais pas de moyen d'insérer
une telle lib. dans le jar.

Sylvain.

Jano wrote on 29/01/2007 11:41:

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, [...]

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

OK.

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe : [...]

si je trouve 5 mn je ferais qlq benckmarch avec vos ordres de grandeur
pour le nombre d'objets.

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous linux
(ou lieu de PC sous Windows et à la place des stations actuelles), pour
le reste vous (et vous seul) devrez vous acquitter de licences pour les
outils de dev. M$ (un compilo free ne me parait pas pérenne, ni
rentable: perte de temps plus importante que gain initial)

Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.

Windows se mets à jour sans arrêt mais une application pour Windows peut
très bien vivre de nombreuses années ("subissant" sans effet, sauf cas
rare, les mises à jour du système).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

c'est une approche possible; elle permettra de prototyper / valider
l'interface (pour ce qu'elle pourrait avoir de Windows spécifique)
rapidement.

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes des
sources d'objets, d'events, etc).
dans votre version actuelle - basée sur des lib. statiques - vont
accéder directement pour chaque besoin à un extern d'un des modules;
avec une interface Java vous devrez définir / implémenter des accessors
(getXX / setXX) pour chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ??
dans ce cas; il faudra 8000 wrapper Java<->C, ie 8000 méthodes déclarées
native en Java et implémentés en C pour appeler la méthode
correspondante de la lib.

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels à
un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes.
les 2 plus classiques fournis par SUN sont AWT (abstract window toolkit)
présent depuis Java 1.0, revisité en 1.1 (ça date mais c'est toujours
présent et fonctionnel), et Swing qui a démarré comme un add-on et qui
est intégré depuis Java 2.0
java.awt.Graphics est la classe de base du système graphique de AWT,
elle définit toutes les primitives de tracé (en autres) que vous
pourriez utiliser.

OUI et comme j'ai déjà assez de travail et de langages comme ça

il faut vous faire aider ! sous-traiter donc une partie du travail ;)

je ne prendrais qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage d'un
second outil c'est que celui-ci est mauvais et ne devrait pas être retenu.
Eclipse me parait un bon choix pour la partie Java; un environnement
Visual Studio me parait indiqué pour la partie C/C++ - oui, il existe un
plug-in GNU C/C++ pour Eclipse, non il n'est pas comparable à Studio.

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives Draw_Line,
etc); ces primitives aujourd'hui "externes" (apportées statiquement par
le module d'interface) seraient implémentés dans un nouveau module
implémentant une communication socket.

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que cela
représente une charge importante. (fr.comp.lang.c si besoin).

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un langage
statique (ne repose pas sur une définition statique du code).

A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

dans le meilleur des cas, vous aurez un .jar (fichier archive) qui
regroupera les dizaines, centaines, de classes (.class) constituant
votre projet et une DLL externe - je ne connais pas de moyen d'insérer
une telle lib. dans le jar.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

Jano wrote on 29/01/2007 11:41:

Je vais essayer d'éclaircir encore quelques points :

1) Une précision globale : ce n'est pas une seule appli, [...]

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

2) Ce n'est pas à proprement parler un SIG comme on l'entend en
général, mais plutôt un système de visualisation de données
géoréférencées, et où donc un affichage géographique est sous-jacent.
Ce n'est certainement pas un "mini-sig web" (voir ci-dessous)

OK.

3) En ce qui concerne la vitesse de raffraichissement, je pense que
cela tombe dans le cas le plus complexe : [...]

si je trouve 5 mn je ferais qlq benckmarch avec vos ordres de grandeur
pour le nombre d'objets.

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est principalement
pour la portabilité, la continuité, et le fait de ne pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous linux
(ou lieu de PC sous Windows et à la place des stations actuelles), pour
le reste vous (et vous seul) devrez vous acquitter de licences pour les
outils de dev. M$ (un compilo free ne me parait pas pérenne, ni
rentable: perte de temps plus importante que gain initial)

Cependant, au vu de la criticité de l'application, l'important est
qu'elle roule vite, avec le moins possible de mises à jour.

Windows se mets à jour sans arrêt mais une application pour Windows peut
très bien vivre de nombreuses années ("subissant" sans effet, sauf cas
rare, les mises à jour du système).

5) du coup, il est possible qu'il soit nécessaire de développer 2 IHM
: si le temps de réponse avec Java n'est pas viable, peut-être la
développer plus près de la machine sous Windows, avec quand même une
version Java en parallèlle.

c'est une approche possible; elle permettra de prototyper / valider
l'interface (pour ce qu'elle pourrait avoir de Windows spécifique)
rapidement.

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes des
sources d'objets, d'events, etc).
dans votre version actuelle - basée sur des lib. statiques - vont
accéder directement pour chaque besoin à un extern d'un des modules;
avec une interface Java vous devrez définir / implémenter des accessors
(getXX / setXX) pour chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ??
dans ce cas; il faudra 8000 wrapper Java<->C, ie 8000 méthodes déclarées
native en Java et implémentés en C pour appeler la méthode
correspondante de la lib.

si cette interface n'est pas dispo, on pourra transmettre directement
un java.awt.Graphics aux routines C mais celles-ci seront alors
marquées par le modèle d'abstraction graphique choisi coté Java (donc
sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels à
un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes.
les 2 plus classiques fournis par SUN sont AWT (abstract window toolkit)
présent depuis Java 1.0, revisité en 1.1 (ça date mais c'est toujours
présent et fonctionnel), et Swing qui a démarré comme un add-on et qui
est intégré depuis Java 2.0
java.awt.Graphics est la classe de base du système graphique de AWT,
elle définit toutes les primitives de tracé (en autres) que vous
pourriez utiliser.

OUI et comme j'ai déjà assez de travail et de langages comme ça

il faut vous faire aider ! sous-traiter donc une partie du travail ;)

je ne prendrais qu'un seul outil.. (Egalement pour des raisons de
maintenance). Pour Java, j'ai installé il y a 2 jours Eclipse.. Pour un
aute langage, ce serait vraisemblablement du C++ via qquechose comme
VC++..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage d'un
second outil c'est que celui-ci est mauvais et ne devrait pas être retenu.
Eclipse me parait un bon choix pour la partie Java; un environnement
Visual Studio me parait indiqué pour la partie C/C++ - oui, il existe un
plug-in GNU C/C++ pour Eclipse, non il n'est pas comparable à Studio.

un exemple: le client Flash utilisé par un navigateur.
coté Java les sockets sont simples d'emploi (voir java.net.Socket)
coté C les API unix et win32 sont différentes.

OUI. Ce que vous voulez dire, c'est que je pourrais ouvrir un socket
de communication de chaque côté, et faire passer quelque chose comme
"trace point à 800, 600 de couleur rouge" sur le socket, c'est ça (du C
vers Java) ou "Fait boucle" (de Java vers C") ?

MAis ça ça veut dire redéfinir toutes les opérations possibles en
structure texte, dans les 2 sens, avec un parser... ça me semble très
lourd...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives Draw_Line,
etc); ces primitives aujourd'hui "externes" (apportées statiquement par
le module d'interface) seraient implémentés dans un nouveau module
implémentant une communication socket.

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que cela
représente une charge importante. (fr.comp.lang.c si besoin).

oui bien sur, pour le compilo tous peuvent être utilisés s'ils savent
créer une librairie (dynamique forcément) exportant des statiques C.

Dans ce cas que veux dire "dynamique forcément" ? Un DLL ? un ".so" ?

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un langage
statique (ne repose pas sur une définition statique du code).

A l'heure actuelle je fabrique des ".a". L'avantage est que pour la
livraison je livre un binaire, et non pas tout un tas de bibliothèques
(dont de plus la localisation dans le système doit être la même
partout).

dans le meilleur des cas, vous aurez un .jar (fichier archive) qui
regroupera les dizaines, centaines, de classes (.class) constituant
votre projet et une DLL externe - je ne connais pas de moyen d'insérer
une telle lib. dans le jar.

Sylvain.

Jano

29/01/2007 à 13:39

denebet wrote:

Jano wrote:

denebet wrote:

Qt est pas mal pour la compatibilité Linux et Windows, en plus cela
s'interface facilement sur des libs en C.

Alain

Avez-vous une bonne réference là-dessus s'il vous plaît ?

Est-ce juste un enrobage de code ?

Je ne comprends pas la question. Il me semblait que vous souhaitiez
modifier uniquement la GUI?
Vous pouvez utiliser QT uniquement pour la GUI avec l'avantage sur
java d'être natif et que l'interface C++/lib C est plus facile à
gérer. Vous pouvez aussi utiliser les classes non-gui de Qt, vous
devrez alors modifier votre code mais ce sera le même sous Win et
Linux (et MacOs X). Par contre QT en version non GPL coûte bonbon.
www.trolltech.com

alain

1600 à 3000 $ la licence ??????

Jano

29/01/2007 à 14:13

Sylvain wrote:

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

Non plusieurs binaires correspondant à plusieurs applications
différentes, mais chacun constitué de nombreux modules (librairies
statiques), et basés sur la même "classe" d'IHM.

Exemple : librairie statique communication socket
librairie statique création/gestion des données
librairie statique fonctions générales (changement de
langue, lecture d'un fichier, manipulation de dates, fonctions de
maths, etc..)
librairie statique fonctionalité métier
librairie statique fonctionalité d'interface (affichage
d'une donnée, boucle, création d'un film, etc)
librarie statique créant et gérant la classe "appli" IHM

d'ou plusieurs applis (binaires) linkées avec ces librairies

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est
principalement pour la portabilité, la continuité, et le fait de ne
pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous
linux (ou lieu de PC sous Windows et à la place des stations
actuelles) :

c'est déjà le cas... 60 stations de travail Linux, réparties dans
30 bureaux à travers le pays, avec 120 utilisateurs environs.

La version Windows serait éventuellement pour des clients externes ne
souhaitant (ou pouvant) pas avoir de PC sous Linux, ou des utilisateurs
plus "administratifs"..

pour le reste vous (et vous seul) devrez vous acquitter
de licences pour les outils de dev. M$ (un compilo free ne me parait
pas pérenne, ni rentable: perte de temps plus importante que gain
initial)

D'accord avec vous sur ce point..

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes
des sources d'objets, d'events, etc). dans votre version actuelle -
basée sur des lib. statiques - vont accéder directement pour chaque
besoin à un extern d'un des modules; avec une interface Java vous
devrez définir / implémenter des accessors (getXX / setXX) pour
chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ?? dans ce cas; il faudra 8000 wrapper
Java<->C, ie 8000 méthodes déclarées native en Java et implémentés en
C pour appeler la méthode correspondante de la lib.

Non pas 8000 routines invoquables "directement" par menu, mais
invoquées dans l'ensemble des callbacks en gros oui (peut-être 5000, je
n'ai pas exactement compté)...

Donc cette solution me semble lourde....

si cette interface n'est pas dispo, on pourra transmettre
directement >> un java.awt.Graphics aux routines C mais celles-ci

seront alors >> marquées par le modèle d'abstraction graphique choisi
coté Java (donc >> sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels
à un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes. les 2 plus classiques
fournis par SUN sont AWT (abstract window toolkit) présent depuis
Java 1.0, revisité en 1.1 (ça date mais c'est toujours présent et
fonctionnel), et Swing qui a démarré comme un add-on et qui est
intégré depuis Java 2.0 java.awt.Graphics est la classe de base du
système graphique de AWT, elle définit toutes les primitives de tracé
(en autres) que vous pourriez utiliser.

OK.. Dans ce cas-là vraisembablement ce serait l'utilisation de ce
java.awt.Graphics..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage
d'un second outil c'est que celui-ci est mauvais et ne devrait pas
être retenu. Eclipse me parait un bon choix pour la partie Java; un
environnement Visual Studio me parait indiqué pour la partie C/C++ -
oui, il existe un plug-in GNU C/C++ pour Eclipse, non il n'est pas
comparable à Studio.

Lol.. Non je ne parlais pas d'outil compliqué, mais de l'ensemble, en
vue de la maintenance ou du développement par d'autres : déjà avoir une
application de 700 000 lignes est complexe. Avoir 2 langages au sein
d'une même application est complexe. Mais au moins pour l'instant ce
sont des langages standards des plateformes unix (C et X11/Motif). En
rajouter d'autres (OpenGL ou DirectX par exemple) complexifie
inutilement et rajoute encore les problèmes de maintenabilité,
perennité, etc...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives
Draw_Line, etc); ces primitives aujourd'hui "externes" (apportées
statiquement par le module d'interface) seraient implémentés dans un
nouveau module implémentant une communication socket.

OK ça c'est faisable... Il n'y a que (!!) environ 70 telles
primitives...

Est-ce ça auquel vous faisiez référence ci-dessus avec le "pas dispo" ??

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que
cela représente une charge importante. (fr.comp.lang.c si besoin).

Là je ne suis pas forcément d'accord, car une partie importante (pas en
volume, mais en fonctionalité) du code est un module de communication
socket TCP/IP (code source original du HTTP utilsé dans le WWW).

Si donc je le compile sous cygwin par exemple (pusique il m'apparaît
comme étant le seul compilateur sous Windows à disposer des sockets "as
is"), cela voudrait dire re-développer un module parallèle avec les
Winsocks... Et du coup peut-être refaire le module s'occupant des
sockets en utilisant les winsocks, pour ne pas avoir 2 structures
différentes simultanées....

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un
langage statique (ne repose pas sur une définition statique du code).

OK. facile.. Il suffit de faire générer un ".so" et non un ".a"..

Sylvain wrote:

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

Non plusieurs binaires correspondant à plusieurs applications
différentes, mais chacun constitué de nombreux modules (librairies
statiques), et basés sur la même "classe" d'IHM.

Exemple : librairie statique communication socket
librairie statique création/gestion des données
librairie statique fonctions générales (changement de
langue, lecture d'un fichier, manipulation de dates, fonctions de
maths, etc..)
librairie statique fonctionalité métier
librairie statique fonctionalité d'interface (affichage
d'une donnée, boucle, création d'un film, etc)
librarie statique créant et gérant la classe "appli" IHM

d'ou plusieurs applis (binaires) linkées avec ces librairies

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est
principalement pour la portabilité, la continuité, et le fait de ne
pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous
linux (ou lieu de PC sous Windows et à la place des stations
actuelles) :

c'est déjà le cas... 60 stations de travail Linux, réparties dans
30 bureaux à travers le pays, avec 120 utilisateurs environs.

La version Windows serait éventuellement pour des clients externes ne
souhaitant (ou pouvant) pas avoir de PC sous Linux, ou des utilisateurs
plus "administratifs"..

pour le reste vous (et vous seul) devrez vous acquitter
de licences pour les outils de dev. M$ (un compilo free ne me parait
pas pérenne, ni rentable: perte de temps plus importante que gain
initial)

D'accord avec vous sur ce point..

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes
des sources d'objets, d'events, etc). dans votre version actuelle -
basée sur des lib. statiques - vont accéder directement pour chaque
besoin à un extern d'un des modules; avec une interface Java vous
devrez définir / implémenter des accessors (getXX / setXX) pour
chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ?? dans ce cas; il faudra 8000 wrapper
Java<->C, ie 8000 méthodes déclarées native en Java et implémentés en
C pour appeler la méthode correspondante de la lib.

Non pas 8000 routines invoquables "directement" par menu, mais
invoquées dans l'ensemble des callbacks en gros oui (peut-être 5000, je
n'ai pas exactement compté)...

Donc cette solution me semble lourde....

si cette interface n'est pas dispo, on pourra transmettre
directement >> un java.awt.Graphics aux routines C mais celles-ci

seront alors >> marquées par le modèle d'abstraction graphique choisi
coté Java (donc >> sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels
à un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes. les 2 plus classiques
fournis par SUN sont AWT (abstract window toolkit) présent depuis
Java 1.0, revisité en 1.1 (ça date mais c'est toujours présent et
fonctionnel), et Swing qui a démarré comme un add-on et qui est
intégré depuis Java 2.0 java.awt.Graphics est la classe de base du
système graphique de AWT, elle définit toutes les primitives de tracé
(en autres) que vous pourriez utiliser.

OK.. Dans ce cas-là vraisembablement ce serait l'utilisation de ce
java.awt.Graphics..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage
d'un second outil c'est que celui-ci est mauvais et ne devrait pas
être retenu. Eclipse me parait un bon choix pour la partie Java; un
environnement Visual Studio me parait indiqué pour la partie C/C++ -
oui, il existe un plug-in GNU C/C++ pour Eclipse, non il n'est pas
comparable à Studio.

Lol.. Non je ne parlais pas d'outil compliqué, mais de l'ensemble, en
vue de la maintenance ou du développement par d'autres : déjà avoir une
application de 700 000 lignes est complexe. Avoir 2 langages au sein
d'une même application est complexe. Mais au moins pour l'instant ce
sont des langages standards des plateformes unix (C et X11/Motif). En
rajouter d'autres (OpenGL ou DirectX par exemple) complexifie
inutilement et rajoute encore les problèmes de maintenabilité,
perennité, etc...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives
Draw_Line, etc); ces primitives aujourd'hui "externes" (apportées
statiquement par le module d'interface) seraient implémentés dans un
nouveau module implémentant une communication socket.

OK ça c'est faisable... Il n'y a que (!!) environ 70 telles
primitives...

Est-ce ça auquel vous faisiez référence ci-dessus avec le "pas dispo" ??

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que
cela représente une charge importante. (fr.comp.lang.c si besoin).

Là je ne suis pas forcément d'accord, car une partie importante (pas en
volume, mais en fonctionalité) du code est un module de communication
socket TCP/IP (code source original du HTTP utilsé dans le WWW).

Si donc je le compile sous cygwin par exemple (pusique il m'apparaît
comme étant le seul compilateur sous Windows à disposer des sockets "as
is"), cela voudrait dire re-développer un module parallèle avec les
Winsocks... Et du coup peut-être refaire le module s'occupant des
sockets en utilisant les winsocks, pour ne pas avoir 2 structures
différentes simultanées....

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un
langage statique (ne repose pas sur une définition statique du code).

OK. facile.. Il suffit de faire générer un ".so" et non un ".a"..

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

vous concluez par "je livre un binaire", je pense que l'on parle bien
d'un seul exécutable (que j'appelerais "appli") constitué de nombreux
modules (actuellement librairies statiques).

Non plusieurs binaires correspondant à plusieurs applications
différentes, mais chacun constitué de nombreux modules (librairies
statiques), et basés sur la même "classe" d'IHM.

Exemple : librairie statique communication socket
librairie statique création/gestion des données
librairie statique fonctions générales (changement de
langue, lecture d'un fichier, manipulation de dates, fonctions de
maths, etc..)
librairie statique fonctionalité métier
librairie statique fonctionalité d'interface (affichage
d'une donnée, boucle, création d'un film, etc)
librarie statique créant et gérant la classe "appli" IHM

d'ou plusieurs applis (binaires) linkées avec ces librairies

4) En ce qui concerne le choix Java ou autre, le "client" principal
est relativement peu exigeant. Si il a pensé Java, c'est
principalement pour la portabilité, la continuité, et le fait de ne
pas être lié à M$.

il peut ne pas être lié à M$ simplement en utilisant des PC sous
linux (ou lieu de PC sous Windows et à la place des stations
actuelles) :

c'est déjà le cas... 60 stations de travail Linux, réparties dans
30 bureaux à travers le pays, avec 120 utilisateurs environs.

La version Windows serait éventuellement pour des clients externes ne
souhaitant (ou pouvant) pas avoir de PC sous Linux, ou des utilisateurs
plus "administratifs"..

pour le reste vous (et vous seul) devrez vous acquitter
de licences pour les outils de dev. M$ (un compilo free ne me parait
pas pérenne, ni rentable: perte de temps plus importante que gain
initial)

D'accord avec vous sur ce point..

vous devrez manipuler depuis Java les grands items du moteur
(accès aux collections de données, aux règles d'inférences, ...)

J'avoue ne pas suivre le "accès aux collections de données, aux
règles..."...

en gros avoir accès, depuis le Java, à toutes les structures (listes
des sources d'objets, d'events, etc). dans votre version actuelle -
basée sur des lib. statiques - vont accéder directement pour chaque
besoin à un extern d'un des modules; avec une interface Java vous
devrez définir / implémenter des accessors (getXX / setXX) pour
chacun de ces accès.

Par contre oui le C contient environ 8000 routines appelées depuis
l'IHM.

8000 routines high-level, utilisateurs, toutes invoquables par menu,
palette d'outils, etc ?? dans ce cas; il faudra 8000 wrapper
Java<->C, ie 8000 méthodes déclarées native en Java et implémentés en
C pour appeler la méthode correspondante de la lib.

Non pas 8000 routines invoquables "directement" par menu, mais
invoquées dans l'ensemble des callbacks en gros oui (peut-être 5000, je
n'ai pas exactement compté)...

Donc cette solution me semble lourde....

si cette interface n'est pas dispo, on pourra transmettre
directement >> un java.awt.Graphics aux routines C mais celles-ci

seront alors >> marquées par le modèle d'abstraction graphique choisi
coté Java (donc >> sûrement moins pérenne).

Là j'avoue que vous me perdez.. Je ne comprends pas "pas dispo" et
"modèles d'abstraction graphique" .. et pas non plus
"Java.awt.Graphics".. Mais c'est sans doute que je ne connais rien à
JAva..

"pas dispo" signifiait si vous choisissez de ne pas coder une telle
interface (ie de coder dans le C faisant la liaison Java/C des appels
à un certain type - fixé / figé - de primitives graphiques).

car, en effet, plusieurs "systèmes graphiques" (le terme est un peu
fort) ou "modèle d'abstraction graphique" existent sous Java; ils se
distinguent par différents jeux d'API, des possibilités (types de
contrôles, ...) différentes et des fonctionnalités globales
(customisation, look'n'feel, ...) différentes. les 2 plus classiques
fournis par SUN sont AWT (abstract window toolkit) présent depuis
Java 1.0, revisité en 1.1 (ça date mais c'est toujours présent et
fonctionnel), et Swing qui a démarré comme un add-on et qui est
intégré depuis Java 2.0 java.awt.Graphics est la classe de base du
système graphique de AWT, elle définit toutes les primitives de tracé
(en autres) que vous pourriez utiliser.

OK.. Dans ce cas-là vraisembablement ce serait l'utilisation de ce
java.awt.Graphics..

IMHO, si l'outil est compliqué au point d'interdire l'apprentissage
d'un second outil c'est que celui-ci est mauvais et ne devrait pas
être retenu. Eclipse me parait un bon choix pour la partie Java; un
environnement Visual Studio me parait indiqué pour la partie C/C++ -
oui, il existe un plug-in GNU C/C++ pour Eclipse, non il n'est pas
comparable à Studio.

Lol.. Non je ne parlais pas d'outil compliqué, mais de l'ensemble, en
vue de la maintenance ou du développement par d'autres : déjà avoir une
application de 700 000 lignes est complexe. Avoir 2 langages au sein
d'une même application est complexe. Mais au moins pour l'instant ce
sont des langages standards des plateformes unix (C et X11/Motif). En
rajouter d'autres (OpenGL ou DirectX par exemple) complexifie
inutilement et rajoute encore les problèmes de maintenabilité,
perennité, etc...

la "syntaxe" des messages peut être binaire et ne pas nécessiter de
parser (seulement des switch); cette option pré-suppose l'existence
exhaustive de primitives de tracé coté lib. C (les primitives
Draw_Line, etc); ces primitives aujourd'hui "externes" (apportées
statiquement par le module d'interface) seraient implémentés dans un
nouveau module implémentant une communication socket.

OK ça c'est faisable... Il n'y a que (!!) environ 70 telles
primitives...

Est-ce ça auquel vous faisiez référence ci-dessus avec le "pas dispo" ??

Et d'autre part cela voudrait sans doute dire modifier le code
C pour pouvoir gérer les sockets Windows, ce dont je ne suis pas sûr
d'avoir envie ...

qlq primitives systèmes devront être changées, je ne pense pas que
cela représente une charge importante. (fr.comp.lang.c si besoin).

Là je ne suis pas forcément d'accord, car une partie importante (pas en
volume, mais en fonctionalité) du code est un module de communication
socket TCP/IP (code source original du HTTP utilsé dans le WWW).

Si donc je le compile sous cygwin par exemple (pusique il m'apparaît
comme étant le seul compilateur sous Windows à disposer des sockets "as
is"), cela voudrait dire re-développer un module parallèle avec les
Winsocks... Et du coup peut-être refaire le module s'occupant des
sockets en utilisant les winsocks, pour ne pas avoir 2 structures
différentes simultanées....

librairie externe chargée dynamiquement donc non lié statiquement au
programme principal ... simplement parce que Java n'est pas un
langage statique (ne repose pas sur une définition statique du code).

OK. facile.. Il suffit de faire générer un ".so" et non un ".a"..

Jano

29/01/2007 à 15:25

Un petit ajout, mais significatif :

mon client principal vient de me signaler que de toutes façons, ce
serait Java... Que toutes les IHM passeraient sous Java...

Bon, c'est ce que souhaite le dépt informatique... Qui n'a jamais
développé une seule application opérationnelle chez eux...

Vu que toutes leurs applications ont été développées (et maintenues)
par les utilisateurs (scientifiques) je ne suis pas certain de cette
affirmation.... ni de sa date de mise en oeuvre ;-).

De plus le dépt Info. s'étant déjà fait remonter les bretelles par le
passé pour ses choix (architectures, matériels, temps de réponse,
etc..) par les utilisateurs (car le service n'est pas en "Front Line",
contrairement aux utilisateurs), ce n'est peut-être pas définitif...

Néanmoins.... Le choix ne fait donc plus de doute, tout au moins pour
eux....et leur administration..

Je vais donc me pencher violemment (euh ... ^^) sur les pistes évoquées
ci-dessus....

Jano

Jano

30/01/2007 à 10:36

Merci pour tous les renseigneents..

Vu les messages ci-dessus, je vais donc m'atteler à la tâche..

Je pense commencer par faire les fenêtres, puis essayer petit à petit
de plugger les routines..

Il est donc certain ( :-( ) que vous entendrez encore parler de moi
dans le groupe ...

Cependant, comme vous avez l'air pas mal au courant, pourriez-vous
m'envoyer un email pour que l'on puisse communiquer éventuellement
directement ? Je ne vous flooderais pas de questions, mais au cas où,
vu que mon style d'application est un peu particulier et que vous
semblez avoir un bon "handle" dessus.. Si ça ne vous dérange pas bien
entendu...

En tous cas merci de tous ces conseils, et je garde préciesuement vos
exemples et suggestions.. :-)

Jano

Question sur l'inclusion de ibrairies C...

10 réponses

Veuillez sélectionner un problème