• [^] # Re: Un projet qui tue pour Java: SwingWT

    Posté par (site web personnel) . En réponse au journal Un projet qui tue pour Java: SwingWT. Évalué à 2.

    C'est ce que j'ai commence a faire: j'ai deja reimplemente javax.net mais pas javax.net.ssl -> en gros ca correspond a refaire entierement OpenSSL, avec ca ma these je suis pas pres de la finir !

    Pour repondre a Gniarf (flemme de faire 2 posts)
    > à l'époque de Symantec Visual Café (v2) on pouvait déjà générer un executable pour Windows de son projet Java (paquet de classes). mais on se retrouvait avec des .exe énormes

    Un chti serveur HTTP (donc sans interface graphique) de 500 lignes compile sous Windows avec MingW fait 4Mo mais j'ai pas vraiment (je suis pas sur en fait) reussi a utiliser les librairies dynamiques. Toutes les demos graphiques que j'ai compiles sous Windows faisaient 4Mo environ. Pour comparer, ce meme serveur HTTP compile avec gcj sous Linux fait 67ko et Httpd.o fait 72ko cf: http://tanguy.dyndns.org/communication/httpd/httpd-0.1/(...)

    Moi je pense sincerement que ca peu donner un super bon truc, rien que sur du code tout petit on voit clairement la difference de temps de lancement de l'application grace a gcc et SWING lag meme pour ouvrir une fenetre d'ouverture de fichier, ce qui n'est pas le cas de SWT. Pour la latence au niveau de l'interface graphique, il suffit de lancer Eclipse pour se faire son propre avis (Eclipse utilise la JVM, des builds de Eclipse compiles avec gcj existent mais c'est encore experimental).

    Evidemment ca ne pourra jamais etre aussi rapide et leger qu'un code C, mais faut bien voir aussi qu'en Java on programme a mon avis 5 fois plus vite qu'en C pour au final un code plus clair, modulaire, reutilisable, plus facilement maintenable, portable, moins de ligne de code, moins buggue... tout ceci a un coup (reduit par la montee en puissance des ordinateurs). Bref c'est un compromis.