Question sur l'inclusion de ibrairies C...

Jano wrote:

Je lis que contrairement au C, Java ne permet pas l'utilisation de
pointeurs que ce soit en sortie de fonctions ou en pour se déplacer
dans un tableau.

Cependant je lis aussi qu'on peut avec des méthodes dites "natives"
linker avec des librairies de C.


Que se passe-t-il donc quand ces librairies font ce genre de
manipulation ?



Si la réponse est qu'on ne peut pas, alors j'abandonne tout de suite (9
ans de développement, je ne vais pas refaire ça..).

Si tu cree un emballage Java autour d'une librairie C, les specificites
de C sont masquees. Depuis Java tu vois juste une API Java comme une autre.

Alex Marandon wrote:

Jano wrote:

Je lis que contrairement au C, Java ne permet pas l'utilisation
de pointeurs que ce soit en sortie de fonctions ou en pour se
déplacer dans un tableau.

Cependant je lis aussi qu'on peut avec des méthodes dites
"natives" linker avec des librairies de C.


Que se passe-t-il donc quand ces librairies font ce genre de
manipulation ?



Si la réponse est qu'on ne peut pas, alors j'abandonne tout de
suite (9 ans de développement, je ne vais pas refaire ça..).

Si tu cree un emballage Java autour d'une librairie C, les
specificites de C sont masquees. Depuis Java tu vois juste une API
Java comme une autre.

OK Merci..ça me rassure ...

Mais par contre faut-il que les librairies C soient DLL, ou bien elles
peuvent rester statiques et avoir un DLL qui fait l'emballage ?

Bonjour

Voilà.. J'aimerais porter un TRES gros projet opérationnel et critique
(+700 000 lignes de code : C / Unix/Linux / XWindows/Motif) sous
Windows.

Je me pose beaucoup de questions sur les outils les mieux adaptés et
les plus faciles, et en même temps les plus prometteurs d'une longue
vie.

En particulier, dans ce projet, qui est développé "en couches", j'ai un
certain nombre (représentant 80% du code) de librairies en C (static
.a).

D'où ma question :

Je lis que contrairement au C, Java ne permet pas l'utilisation de
pointeurs que ce soit en sortie de fonctions ou en pour se déplacer
dans un tableau.

Cependant je lis aussi qu'on peut avec des méthodes dites "natives"
linker avec des librairies de C.


Que se passe-t-il donc quand ces librairies font ce genre de
manipulation ?



Si la réponse est qu'on ne peut pas, alors j'abandonne tout de suite (9
ans de développement, je ne vais pas refaire ça..).

Et enfin quesion subsidiaire si la réponse à la question ci-dessus est
qu'on peut : une de ces librairies gère la communication avec des
serveurs via les sockets (code HTTP original). Peut-elle s'intégrer ou
vaut-il mieux la réécrire ?

Merci d'avance

Bonsoir,

Ls questions à poser me semblent plutôt être "est-il interessant de
migrer mon application sous Java ? Et si oui, comment ?"

Mais pour y répondre il te faudra nous en dire plus sur ses
fonctionalités et ses spécificités ... structure, fonctionalités,
performances, utilisation ... bref, un panorama !

(sans bien sûr trahir de "secrets d'états"... alors au besoin utilisez
des analogies)

A+
TM

Jano wrote:

Mais par contre faut-il que les librairies C soient DLL, ou bien elles
peuvent rester statiques et avoir un DLL qui fait l'emballage ?

Oui, ca devrait marcher.

Mais attends un peu, d'apres ta question je deduit que tu ne disposes
pas des sources de ces libs, mais que tu dispose seulement des .a
compiles pour une plateforme Unix. Si c'est la cas tu as un gros
probleme non ? Comment comptes-tu executer du code natif Unix sur un
Windows ?

Alex Marandon wrote:

snip.

Mais attends un peu, d'apres ta question je deduit que tu ne disposes
pas des sources de ces libs, mais que tu dispose seulement des .a
compiles pour une plateforme Unix. Si c'est la cas tu as un gros
probleme non ? Comment comptes-tu executer du code natif Unix sur un
Windows ?

Non non du tout..J'ai absolument tous les sources, c'est moi qui ai
tout écrit..

Mon point est principalement que les DLL mettent du temps à charger, et
que je préférerais livrer quelque chose d'assez optimisé dans le temps..

Voir précisions dans la réponse au message suivant...

TestMan wrote:

snip.

Bonsoir,

Ls questions à poser me semblent plutôt être "est-il interessant de
migrer mon application sous Java ? Et si oui, comment ?"

Mais pour y répondre il te faudra nous en dire plus sur ses
fonctionalités et ses spécificités ... structure, fonctionalités,
performances, utilisation ... bref, un panorama !

(sans bien sûr trahir de "secrets d'états"... alors au besoin
utilisez des analogies)

A+
TM

OK.Je vais tenter d'expliquer un peu plus...

C'est une application scientifique professionnelle, avec affichage
graphique complexe et calculs.
[il y a environ une quinzaine de fenêtres, mais par contre elles sont
complexes (plus de 60 widgets dans chaque, avec redimensionnement de
parties de fenêtres, cache de certaines parties, constructions
dynamiques d'autres, etc..) et c'est très pointu en affichage
graphique, gourmand, avec possibilité de faire changer de couleur de 2
à 20 000 symboles sur un fond d'image si possible en moins d'un 1/10
seconde]

La structure est une structure en couches (transport avec HTTP,
protocole, puis bibliothèques de fonctions générales, puis biblothèques
de fonctionalités d'interface (indépendantes de l'outil), puis
bibliothèque de GUI.. Chaque application peut sans être modifiée être
liée (linkée) à un GUI différent (motif, windows, etc..).

Bien qu'écrite en C avec librairies statiques, la programmation a été
très "orentée objet", pour prendre un terme à la mode..Cependant, le
nombre d'objets manipulés peut aller jusqu'à 150 000 ou 200 000....

Elle fonctionne en temps réel (mais pas sur des OS temps réel), elle
est opérationnelle et critique (implique éventuellement évacuation
d'usines, fermetures d'aéroports, etc..), et fonctionne
opérationnelement depuis 10 ans sur des machines HP, SGI, PCs, sous
HPUX,SGI Unix,Unix, Linux..

Donc normalement toute la partie en dehors du GUI (80% du code), est
portable sur n'importe quelle plateforme, pourvu d'avoir un compilateur
C.

Mon problème réside pour le portage à Windows :

1) les compilateurs que je voit lors de mon survol actuel ne
semblent pas complets (pas tous les ".h", pas toutes les fonctionalités
(timers, signals, sockets)), ou alors il faut changer le code.

2) Même si je résous ça, il me reste le problème du GUI. Là plusieurs
choix s'offrent :

- utiliser Java
- utiliser un langage comme VC++, ou autre..

J'en suis à cette phase où j'essaye de déterminer quel serait le
meilleur outil, permettant :

a) de minimiser le travail à accomplir
b) de minimiser les transformations en dehors du GUI (l'application
doit continuer de fonctionner et d'être maintenue sur Unix/Linux)
c) de chosir un GUI ayant une durée de vie (prévue ? assurée ?)
longue
d) de choisir un GUI me permettant au mieux de pouvoir respecter
les contraintes temporelles d'exécution (pas forcément temps réel),
mais je vais citer un exemple :

je fais une boucle d'affichage de données représentées par des
symboles. Ces données sont définies par un temps d'arrivée et une
valeur. Le temps sur lequel je fais la boucle peut aller d'une heure à
2 ans. Je peux donc avoir de 100 000 à 3 millions de symboles
graphiques.
Lors de la boucle, je modifie les couleurs des données au fur et à
mesure du temps qui passe, de manière optimisée, c'est à dire que je ne
change pas tout, mais je tiens compte uniquement des frontières entre
les "bins" de temps. J'aimerais que dans le cas ou j'ai 40 à 50 000
données, et donc environ 3 à 5000 symboles à changer de couleur, le
temps de réponse soit au maximum de l'ordre de la seconde.. ou en tous
cas le plus rapide possible pour un affichage Windows.

Mon "client" principal (je suis à mon compte, mais j'ai développé ça
pour lui) aimerait que ce soit en Java. Cependant il connait les
contraintes, et donc veut choisir le meilleur compromis possible.

D'où ma recherche.....

Jano wrote on 27/01/2007 15:08:

Mon point est principalement que les DLL mettent du temps à charger,

à 9600 bps depuis les antipodes ? surement, en local c'est au moins
aussi long qu'une classe pure Java, soit imperceptible.

que je préférerais livrer quelque chose d'assez optimisé dans le temps..
Voir précisions dans la réponse au message suivant...

l'autre message détaille la dimension mais pas la complexité hors GUI.

a) si le temps est surtout mangé par le traitement, vous aurez avantage
à en effet garder un moteur C++ et à définir une interface de
communication optimale (simplifiant les échanges des données entre C/C++
et Java -- JNI permets de (quasi) tout échanger mais au prix de
nombreuses lignes de code).

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

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.

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, votre appli actuelle utilise surement un server
X-window, cette option bien que très peu répandue existe sous windows,
un portage C++ de votre code sous windows est donc surement également
possible (même si c'est certain le premier compilo venu - VS Express de
MS ? - pourrait donner l'impression contraire), demander conseil sur
fr.comp.lang.c++ si besoin.

Sylvain.

...

D'où ma question :

Je lis que contrairement au C, Java ne permet pas l'utilisation de
pointeurs que ce soit en sortie de fonctions ou en pour se déplacer
dans un tableau.

Cependant je lis aussi qu'on peut avec des méthodes dites "natives"
linker avec des librairies de C.


...

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

bye,

samuel

Jano wrote:

Donc normalement toute la partie en dehors du GUI (80% du code), est
portable sur n'importe quelle plateforme, pourvu d'avoir un compilateur
C.

Mon problème réside pour le portage à Windows :

1) les compilateurs que je voit lors de mon survol actuel ne
semblent pas complets (pas tous les ".h", pas toutes les fonctionalités
(timers, signals, sockets)), ou alors il faut changer le code.

2) Même si je résous ça, il me reste le problème du GUI. Là plusieurs
choix s'offrent :

- utiliser Java
- utiliser un langage comme VC++, ou autre..

J'en suis à cette phase où j'essaye de déterminer quel serait le
meilleur outil, permettant :

a) de minimiser le travail à accomplir
b) de minimiser les transformations en dehors du GUI (l'application
doit continuer de fonctionner et d'être maintenue sur Unix/Linux)

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

Alain

Très très intéressant, merci..

Je vais essayer de vous répondre, et de poser les questions que votre
post m'inspire...

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..) :

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).

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 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").

Donc le GUI est utilisé pour :

1) présenter les choix accessibles à l'utilisateur
2) appeler la fonctionalité requise (en C)
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..).

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

Cela permet, avec par exemple une plateforme Linux, de créer une
application qui, uniquement au moment de l'édition de liens, peut-être
XWindows, ou par un langage de commande sortant des GIF, des Jpegs,
etc.. , ou GL, etc.. mais dont la fonctionalité (débuggée) est
strictement la même.


Sylvain wrote:

Jano wrote on 27/01/2007 15:08:

Mon point est principalement que les DLL mettent du temps à charger,

à 9600 bps depuis les antipodes ? surement, en local c'est au moins
aussi long qu'une classe pure Java, soit imperceptible.

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.

a) si le temps est surtout mangé par le traitement, vous aurez
avantage à en effet garder un moteur C++ et à définir une interface
de communication optimale (simplifiant les échanges des données entre
C/C++ et Java -- JNI permets de (quasi) tout échanger mais au prix de
nombreuses lignes de code).

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.

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 ?

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, votre appli actuelle utilise surement un server
X-window, cette option bien que très peu répandue existe sous
windows, un portage C++ de votre code sous windows est donc surement
également possible (même si c'est certain le premier compilo venu -
VS Express de MS ? - pourrait donner l'impression contraire),
demander conseil sur fr.comp.lang.c++ si besoin.

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 plus complet, mais pas encore au niveau des compilateurs
Unix. Mais par contre même cette solution me laisse le choix du GUI
(puisque par exemple sous cygwin il existe un serveur X mais pas Motif).

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 ?