Discussion :

[djo.mos]

Bonjour,
Ca me peine de le dire, mais bon ... faut être honnete
Bref, dans votre cas, eclipse RCP serait du suicide pûr et dûr ... pour quelqu'un ne connaissant même pas l'OO (ni encore le langage Java), s'attaquer à un truc aussi costaud qu'eclipse RCP ...
Je ne veux pas dire que c'est complexe, mais que c'est du costaud (basé sur l'OSGi et les points d'extension): ça te permet de faire des trucs impressionnants, pas en termes d'UI (il est plutôt classqiue la dessus), mais en termes de modularité et extensibilité. Mais il faut déjà bien connaitre le langage (Java) et quelques points avancés qui lui sont relatifs (pour comprendre l'OSGi), + un peu d'XML ...

[FloMo]

Oui, mais l'argumentaire pour le défendre est que c'est facile de trouver du monde qui connait le Java ( qui est un langage facile à apprendre )et que le C++ est long et fastidieux. Enfin, c'est l'argumentaire que j'ai en face.

Je me dis qu'en étant utilisateur de Qt avec C++ je n'ai pas un avis forcément objectif. d'où mon post.

[yan]

Sans rentrer dans les détails, une sorte de Basic proprio mais pouvant faire appel à des bibliothèques dynamiques. Il y a aussi des scripts shell ( je sais, ça craint ).

Qt te permettra de contrôler l'execution des shell par QProcess.
Au faite , Qt existe en JAVA : QtJambi.

ton basic proprio et tes lib dynamiques sont portable???

[yan]

Oui, mais l'argumentaire pour le défendre est que c'est facile de trouver du monde qui connait le Java ( qui est un langage facile à apprendre )et que le C++ est long et fastidieux. Enfin, c'est l'argumentaire que j'ai en face.

De ce que j'ai compris,il est plus facile d'apprendre la programmation OO avec Java que C++. Mais aussi difficile de faire de vrai programme. Tout comme en OCAML, python, ruby...
Il n'existe pas de langage parfais. Uniquement des langages pour des domaine privilégié
Vue le domaine, je dirait que le C++ est plus approprié.

[FloMo]

ton basic proprio et tes lib dynamiques sont portable???

Le basic n'est pas du tout portable et mes libs sont réalisées par mes soins, donc portables grâce aux autotools.

[FloMo]

De ce que j'ai compris,il est plus facile d'apprendre la programmation OO avec Java que C++. Mais aussi difficile de faire de vrai programme. Tout comme en OCAML, python, ruby...
Il n'existe pas de langage parfais. Uniquement des langages pour des domaine privilégié
Vue le domaine, je dirait que le C++ est plus approprié.

C'est vrai que c'est un bon argument.

Par contre, d'un point de vue rapidité afin d'avoir une équipe opérationnelle, vous avez une idée ?

[eclesia]

Pour l'argument "portabilité" du C++. Ok, mais il faut toujours gerer au final une version par plateforme.

On se simplifi la vie avec java, un seul jar pour tous.
On combine ca avec la plateforme NetBeans RCP et on obtient une application qui se lance n'importe où.
Et ce n'est pas une théorie, je developpe sur netbeans plateforme, et l'appli resultant marche sur mon linux64 aussi bien que sous winXp et sous mac sans rien recompiler.

Niveau maintenance on est gagnant

Au faite , Qt existe en JAVA : QtJambi.

Personnellement j'éviterai, en l'utilisant tu réduis les potentiels personnes qui pourraient t'aider. De plus la librairie SWING propose les mêmes composants en preservant la portabilité.

[yan]

Pour l'argument "portabilité" du C++. Ok, mais il faut toujours gerer au final une version par plateforme.

On se simplifi la vie avec java, un seul jar pour tous.
On combine ca avec la plateforme NetBeans RCP et on obtient une application qui se lance n'importe où.
Et ce n'est pas une théorie, je developpe sur netbeans plateforme, et l'appli resultant marche sur mon linux64 aussi bien que sous winXp et sous mac sans rien recompiler.

Niveau maintenance on est gagnant

Ha la guerre de java vs C++. Y as aussi C# avec mono sous linux.
Mais bon on parle de vrai language donc de C++

Personnellement j'éviterai, en l'utilisant tu réduis les potentiels personnes qui pourraient t'aider.

Pourquoi?

[eclesia]

Pourquoi?

C'est juste un fait, il y a plus de developpeur SWING que qtJambi.
S'il fallait trier les api par nombre de developpeurs.
Je pari sur :
SWING >> SWT >= AWT > ...autre api...
cf : Vieux Sondage
(je precise pour qui va lire les commentaires du sondage que les premiers posts date de 2004 et que l'argument de "performance" de SWT n'est plus vrai)

De plus QtJambi à le même defaut que SWT, c'est du JNI, donc tu dois te trimballer une version differente par plateforme.

[FloMo]

De plus QtJambi à le même defaut que SWT, c'est du JNI, donc tu dois te trimballer une version differente par plateforme.

De ce point de vue là, les tests internes ont démontré 2 choses :
- pour être sûr du résultat, il vaut mieux tester sur chaque plateforme cible,
- pour avoir des performances correctes ( clients légers X11 ) , il a fallu compiler le code Eclipse RCP, donc compiler pour chaque plateforme.

De plus, ce n'est pas pour 2 minutes de compilation par plateforme que l'on va sacrifier l'une ou l'autre des technologies. Ce ne sont que 2 minutes qui vont s'ajouter aux batteries de test.

[FloMo]

C'est juste un fait, il y a plus de developpeur SWING que qtJambi.

Pour l'aide, vu que l'on est dans un contexte de produit commercial, on paye une licence avec Qt, donc on a le support de TrollTech.

[yan]

De plus QtJambi à le même defaut que SWT, c'est du JNI, donc tu dois te trimballer une version differente par plateforme.

Tu n'utilise pas de lib externe?
Je ne pense pas que tu puisse trouver des équivalences à toute les lib en java pure.
Y auras toujours des dépendances (au moins indirecte) lié à la plateforme.

[eclesia]

Tu n'utilise pas de lib externe?
Je ne pense pas que tu puisse trouver des équivalences à toute les lib en java pure.
Y auras toujours des dépendances (au moins indirecte) lié à la plateforme.

Et bien non , je n'ai jamais utilisé de libraires externes natives.
j'ai toujours tout trouvé en "java pure".

Swing est tres riche et est extensible grace a java2D.
On peut pratiquement faire tous les composants qu'on peut imaginer.

PS : je retourne meme la question : peut on trouver tous les composants java en natifs ? Vu que les composants swing sont dessinés ils n'ont aucune contrainte par rapport au composant natif.

[yan]

Et bien non , je n'ai jamais utilisé de libraires externes natives.
j'ai toujours tout trouvé en "java pure".

chapeau .
Mais c'est concevable uniquement quand on code et recode tout avec.

PS : je retourne meme la question : peut on trouver tous les composants java en natifs ? Vu que les composants swing sont dessinés ils n'ont aucune contrainte par rapport au composant natif.

[eclesia]

chapeau
Mais c'est concevable uniquement quand on code et recode tout avec.

ya pas de " chapeau " c'est juste Java

Je vais tacher d'expliquer : Swing, c'est du dessin (Java2D)

Par exemple un JButton en swing, ca a l'aparence d'un bouton, ca réagit comme un bouton, ca fait tout comme un bouton.
Seulement ce n'est qu'un dessin fait en tracant des lignes, des rectangles et du texte. Tous les composants Swing sont comme ca.
Un arbre, une liste, un tableau ...etc...

C'est en fait tres simple de faire un composant a partir de rien, il suffit de savoir utiliser java2D (ce qui n'est pas la mer a boire) et savoir intercepter un evenement, clavier, souris ...etc...
Swing n'a en fin de compte aucun liens avec les composants natifs.

[FloMo]

Je vais tacher d'expliquer : Swing, c'est du dessin (Java2D)

D'où les performances médiocres. Ce n'est pas envisageables pour nous car nous avons une dizaine de platines X11 en moyenne pour un serveur avec 1Go de RAM en général.

[yan]

ha ok.
Faudra que je regarde tous cela un de ces jours.

[yan]

Et pour autre chose que de l'ihm, tu fait comment?
Par exemple des traitement 3D? ou d'image?

[eclesia]

D'où les performances médiocres. Ce n'est pas envisageables pour nous car nous avons une dizaine de platines X11 en moyenne pour un serveur avec 1Go de RAM en général.

Ha encore celui la : les performances.
C'est l'argument favorie des anti-Java.

Je vais pas lancer la contre-attaque ici, c'est deja bien entamé sur le forum C++ vs Java, mais si tu dois demontrer que swing est lent, alors je conseil de trouver des documents de valeurs et pas des "On dit".

[yan]

Ha encore celui la : les performances.
C'est l'argument favorie des anti-Java.

Et ça la réponse des java-iste

si tu dois demontrer que swing est lent, alors je conseil de trouver des documents de valeurs et pas des "On dit".

Tous ça par ce qu'ils ne veulent pas le reconnaitre

Toute façon dire que swing est lent ne veut rien dire. C'est de l'ihm. C'est pas ça qui prend du cpu (en principe).
C'est le reste.Et c'est la où est la différence.

C'est le context qui donnera le bon langage.
Le C/C++ sera toujours plus rapide. Mais parfois à quel prix!!!
Bien sur cela ne veut pas dire que java est forcément plus lent