Discussion :

[joho]

Oui. Il y a des barjots qui tentent regulierement l'ecriture de compilateur pour la JVM: Scheme, haskell, fortran, ADA, lisp, ...

Faut arreter d'etre aussi desobligeant. Si certains font des choses, peut etre que c'est parce quqe ça leur sert

[pseudocode]

Faut arreter d'etre aussi desobligeant. Si certains font des choses, peut etre que c'est parce quqe ça leur sert

C'etait ironique comme remarque. J'aurais du mettre un smiley.

D'autant plus ironique que j'avais commencé un compilateur d'un langage "maison"

[adiGuba]

est-ce qu'il existe des compilateurs autre-langage-que-java ---> Bytecode ?

Groovy est aussi compilé en bytecode...

A noter que ceci est possible depuis toujours, mais que ce n'est pas vraiment mis en avant par Sun qui priviliégie Java...

Toutefois, pour Java 7 il y a de forte chance que le format du bytecode évolue afin de mieux supporter l'invocation dynamique des langages de script...

Je ne crois pas que les createur de Java se sont dit: "Tiens, on va créer un langage/framework qui permet de faire des IHM portables.". Ca, je pense que c'etait plus l'idée des créateurs de HTML

Si justement !!!

A l'origine Java était prévu pour faire des applications graphiques portables d'une machine à l'autre. Et à l'origine la cible était clairement le Web (via les applets).

Cela n'a jamais pris pour plusieurs raisons, dont :

• Les premières versions de Java qui n'étaient pas très performante (pas de compilateur JIT), et AWT, le prédécesseur de Swing, est assez lourd et pas très complet...
• Lorsque Swing fut intégré à Java, il fut très peu utilisé sur le web à cause d'un gros problème d'incompatibilité : Microsoft livrait Internet Explorer avec sa propre version de Java, qui comportait des API non-standard (spécifique à Windows) et obsolète (pas de Swing).
• Et dans le même temps, un concurrent de taille s'était déjà pris une bonne part du gateau : Flash. Ce dernier possédait d'ailleur un gros avantage sur Swing : un EDI permettant de faire de belles animations très simplement (et c'est ce qui était recherché sur le web).

Mais Flash et Java/Swing ne cible pas les mêmes besoins/utilisateurs.

• Flash est plutôt destiné à l'animation et aux graphistes (même s'il est possible de faire des applications)
• Swing est plutôt destiné à faire des applications Desktop standard et aux développeurs "de base" (même s'il est possible de faire des animations...)

Il est clair que Flash est bien plus adapté aux besoins du web que ne peuvent l'être les applets... et on peut dire que Java a été sauvé par son positionnement coté "serveur"...



Toutefois, c'est très différent avec le retour en force des applications riches, Swing dispose de certains avantages indéniables :

• Portabilité et déploiement facile (via Java Web Start).
• Il profite du reste de l'API de Java SE qui est vraiment énorme.
• S'il possède une base de composant minimum, un grand nombre de composant personnalisé et d'outils annexe sont disponible...
• Une apparence par défaut pas très belle (LookAndFeel metal), mais la possibilité de la changer facilement ou d'utiliser le look du système hôte (désormais vraiment très proche).
• NetBeans propose désormais un GUI Builder évolé, ce qui a manqué pendant longtemps...

Et les JSR de Java 7 vont continuer dans ce sens :

• Beans bindings, qui permettra de lier plus facilement deux propriétés de deux composants/objets...
  
• Swing Application Framework, dont l'objectif est de fournir une base commune à la plupart des applications Desktop :
  
  • Gestion du cycle de vie de l'application (démarrage et arrêt).
  • Chargement et gestion des resources (messages formatés, images, etc.) et injection des données directement dans les composants.
  • Définition et gestion des actions (les evenements à associer avec des évenements).
  • Gestion de la persistence de l'état de l'application.
  
  
  Pour avoir testé une version en développement il y a quelques temps je dois dire que cela a l'air prometteur...

Mais ce qui manque vraiment c'est une "power-app" qui remettrait Swing sur le devant de la scène... un peu comme l'a fait Gmail avec 'AJAX', qui n'est ni plus ni moins que du DHTML (c'est à dire une technologie classé "toute pourrie" il y a quelques années).


a++

[Deadpool]

Comme d'hab, adiGuba a fournit une explication infiniment plus détaillé que moi.

[pseudocode]

Ok, je me

"JAVA EST CONCU POUR DEVELOPPER DES IHM PORTABLES"

(je pensais que Java avait été créé au départ pour developper des systèmes reseaux embarqués, ce qui est maintenant la cible de JME)

[lunatix]

pour les applets moches, faut arreter, c'etait au debut, y'a longtemps, et a été bien pourri par microsoft et sa jvm pas standard.
voir : http://services.alphaworks.ibm.com/manyeyes/home
ou http://demicron.com/gallery/index.html
pour quelques simples exemples

[JeitEmgie]

sans oublier les assembleurs comme Jasmin…
http://jasmin.sourceforge.net/

[pseudocode]

@lunatix: Il y aussi les demos officielles du JDK de SUN

http://java.sun.com/applets/jdk/1.4/index.html

[FremyCompany]

Ecoutez, je vous mets au défi. J'ai 15 ans, et j'ai fait ceci (NET 2 + VS2005) en 20 minute.



L'application s'adapte en fonction des couleurs systèmes (vert chez moi mais bleu en général)

Le taux de transparence varie.
Le splash screen s'ouvre dès le début et se ferme dès que la fenêtre "maitre" est prête (après onload mais avant show)

Ensuite ce que fait l'appli a peu d'importance...

Possible avec java ? En combien de temps ?

[joho]

Effectivement java n'est pas aussi portable ... (pour faire ca avec la transparence qui varie je ne vois que les JNI ... soit du C ... sinon ca doit se faire sans la transparence qui varie en 10 min. mais bon ... j'ai 23 ans )
ou alors il faut voir MP Gfx ou des gens qui touche un peu swing ou awt .... qui j'imagine le ferait en moins de temp.
java c'est bien faut pas croire

je lisais des gens qui disait que DotNET ne seravait pas a la meme chose que java. Il me semble qu'on peut faire des portails d'entreprise (intranet) avec java (webspehere) et qu'on peut en faire avec DotNET (sharepoint) donc ces deux langages sont comparables sur ce point au moins

A part ça j'ai trouvé des benchmark qui montre quel langage est plus rapide http://www.dotnet-project.com/News-o...-et-c-.67.aspx
mais c'est un bench qui date, comme tout ceux que je trouves, de quand ma grand mere est née (2004) et je ne trouves pas ça très probant. Un décideur ne va pas choisir java parce qu'il a pris a DotNET 0.05 sec. sur une opération ou vice versa.
Si vous aviez des benchmarks sur la productivité avec les langages, le nombre de lignes de codes écrit pour faire une meme tache, la facilité a trouver du code (oui je sais ... ce dernier est super subjectif) etc.... ca ferait bien plaisir


Sinon bravo quand meme a 15 ans (si c'est bien ton age) d'avoir autant d'étoile sous ton avatar. A cet age la , je savais que je voulais faire de l'informatique mais je n'avais aucune idée de ce a quoi ca ressemblait

[adiGuba]

Effectivement java n'est pas aussi portable ...

Au contraire ! Java est portable et c'est pour ca que ce n'est pas aussi facile...

L'application s'adapte en fonction des couleurs systèmes (vert chez moi mais bleu en général)

Si tu parles de la couleur de la barre de titre, c'est très facile à obtenir en Java à partir du moment où on utilise le LookAndFell système :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Color color = UIManager.getColor("activeCaption");

Le splash screen s'ouvre dès le début et se ferme dès que la fenêtre "maitre" est prête (après onload mais avant show)

Avev Java6 il suffit d'indiquer le fichier à utiliser comme splash dans le manifest de l'application :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 SplashScreen-Image: <nom_du_fichier_dans_le_jar>

Le taux de transparence varie.

A l'intérieur de l'application c'est très facile à faire, par exemple transparence à 50% :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Graphics2D g2d = (Graphics2D) g ;
	g2d.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, 0.5f ));

Par contreau niveau de la fenêtre c'est autre chose car c'est géré par le système d'exploitation (et donc variable d'un système à l'autre). Il faut donc soit passer par du code natif (et donc perdre en portabilité), soit magouillé en faisant un printscreen...

Là tu mets le point sur un des désavantages de Java : l'intégration au système !
Mais même temps cela peut être un avantage selon les besoins...

Essayes de déployer ton application sur des systèmes MacOS, Unix ou Linux...


a++

[JeitEmgie]

Ecoutez, je vous mets au défi. J'ai 15 ans, et j'ai fait ceci (NET 2 + VS2005) en 20 minute.



L'application s'adapte en fonction des couleurs systèmes (vert chez moi mais bleu en général)

Le taux de transparence varie.
Le splash screen s'ouvre dès le début et se ferme dès que la fenêtre "maitre" est prête (après onload mais avant show)

Ensuite ce que fait l'appli a peu d'importance...

Possible avec java ? En combien de temps ?

si un beau splash screen peut être quelque chose d'amusant à faire, et qui donne du "peps" à une application,
on ne choisit pas une solution de développement pour la facilité d'écrire ce genre de choses…
d'autant plus qu'à l'ère du multimedia on pourra toujours faire tout ce que l'on veut sous forme de "movie"…

[pseudocode]

C'est marrant de remarquer que lorsqu'on propose un exemple concret dans un langage X, y a toujours tout plein de fanboy du langage Y qui t'explique comment t'en passer.

NB: Ca marche aussi en remplacant "langage" par "OS".

Vis a vis de cet exemple, moi je garde mon mentra

[adiGuba]

C'est marrant de remarquer que lorsqu'on propose un exemple concret dans un langage X, y a toujours tout plein de fanboy du langage Y qui t'explique comment t'en passer.

Je n'ai pas expliquer comment s'en passer !

C'est juste une différence de philosophie entre les deux plateformes (concernant le GUI en tout cas) :

• Java/Swing se veut portable, et possède donc un certain nombre de limite sur des spécificité du système d'exploitation ou du gestionnaire de fenêtre...
• .NET/WinForms ou .NET/XAML permettent de générer des applications Windows, et peuvent donc bénéficier de toutes les spécificités du système...

La portabilité peut être un besoin aussi important (voir plus) qu'un effet de transparence sur une fenêtre

a++

[JeitEmgie]

C'est marrant de remarquer que lorsqu'on propose un exemple concret dans un langage X, y a toujours tout plein de fanboy du langage Y qui t'explique comment t'en passer.

NB: Ca marche aussi en remplacant "langage" par "OS".

Vis a vis de cet exemple, moi je garde mon mentra

n'utilisant qu'occasionnellement Java et ses technologies associées et jamais .Net, je ne suis ni fan de l'un ni anti de l'autre,
je constate seulement qu'en maintenant 21 pages de post dans ce forum, il n'y a toujours pratiquement rien qui permette à un "étranger" de se faire ne fut-ce que l'ombre d'un avis basé sur des critères autres que des opinions soit très générales, à la limite du truisme, soit des surenchères verbales du niveau "bac à sable", les quelques commentaires censés étant rapidement détournés de leur bon chemin initial par des intervenants qui semblent souvent répondre avant de lire …

[pseudocode]

C'est juste une différence de philosophie entre les deux plateformes (concernant le GUI en tout cas)

Je suis d'accord a 2000 % !! C'est ce que je dit depuis 2O posts !
Ma remarque ne s'adressait pas a toi

J'essaye de choisir un langage/framework en fonction de ma problematique.

J'essaye de ne pas adapter ma problematique en fonction des capacités du langage/framework que je souhaiterai utiliser.

[pseudocode]

les quelques commentaires censés étant rapidement détournés de leur bon chemin initial par des intervenants qui semblent souvent répondre avant de lire …

Ca ca doit etre pour moi

n'utilisant qu'occasionnellement Java et ses technologies associées et jamais .Net (...)

(...) je ne devrais pas argumenter sur un sujet que je ne connais pas ?

[JeitEmgie]

Je n'ai pas expliquer comment s'en passer !

C'est juste une différence de philosophie entre les deux plateformes (concernant le GUI en tout cas) :

• Java/Swing se veut portable, et possède donc un certain nombre de limite sur des spécificité du système d'exploitation ou du gestionnaire de fenêtre...
• .NET/WinForms ou .NET/XAML permettent de générer des applications Windows, et peuvent donc bénéficier de toutes les spécificités du système...

La portabilité peut être un besoin aussi important (voir plus) qu'un effet de transparence sur une fenêtre

a++

il n'y a pas de critères généraux… tout est toujours lié à un contexte…

si la transparence pour le plaisir de faire un beau "startup screen" n'a de fait que peu d'intérêt, on peut imaginer une autre situation où un effet de transparence apporterait un réel plus à l'utilisateur final dans son utilisation de l'application, par exemple durant le feedback d'un drag-and-drop, voir en transparence ce qui est en dessous de l'objet déplacé peut améliorer la qualité du "vécu" de l'utilisateur final…
dans ce genre d'exemple, alors il serait intéressant de comparer effectivement les implémentations possibles dans les différents frameworks…

[JeitEmgie]

Ca ca doit etre pour moi


(...) je ne devrais pas argumenter sur un sujet que je ne connais pas ?

c'est bien ce que je disais : "des intervenants qui semblent souvent répondre avant de lire …"

j'argumente sur des questions de méthodologie de comparaison,
pas sur le mieux et le moins bon de chacune des technologies…

[pseudocode]

j'argumente sur des questions de méthodologie de comparaison, pas sur le mieux et le moins bon de chacune des technologies…

Méthodologie de comparaison de quoi ?
- de la syntaxe du langage ?
- du nombre de classe/methode de la libraire ?
- du nombre de lignes de code pour faire un solitaire ?
- du temps passé a comprendre la philosophie du langage ?
- du cout de formation des nouveaux/anciens codeurs de la société ?

Est-ce que tu penses vraiment qu'on peut faire une grille de criteres exaustive qui caracterise entierement un langage/framework ?

Moi je ne le pense pas. Je peux faire une grille de criteres exaustive qui caracterise ma problematique. Et ensuite regarder si tel ou tel langage/framework est plus ou moins bien adapté a mon probleme.

Il n'y a pas de formule magique qui te donne le meilleur langage/framework avec des criteres vagues comme (je te cite) la "classique" situation de devoir présenter à l'utilisateur une liste d'objets dont il pourra "éditer" ou "supprimer" des objets existant, et en "créer" de nouveaux…"

Les discussions de comparaison entre langage n'aboutissent jamais a rien, sinon a une gueguerre fanboy/trolleur. Souvenez vous des debats C++/Java, ou meme Vb/Java