Mono préféré à Java pour les développements d'applications pour station de travail Linux

[gorgonite]

Mono préféré à Java pour les développements d'applications pour station de travail Linux


Selon certains experts, Mono serait désormais plus apprécié que Java par les développeurs d'applications pour station de travail en environnement GNU/Linux.
Parmi les plus populaires applications, nous pouvons cité Tomboy outil de prise de note écrit en C#, Banshee un lecteur multimédia apprécié par des utilisateurs de Gnome, l'outil de recherche Do pour le gestionnaire de fenêtres Gnome, etc


Pour rappel, Mono est une implantation libre du framework Microsoft .Net, soutenue par la société Novell, qui possède la distribution GNU/Linux Suse.




plus d'infos
http://www.sdtimes.com/link/33597


voir aussi
Mono et C# distribué avec Debian : Richard M. Stallman s'insurge
Microsoft : C# et CLI donnés aux développeurs




Mono, malgré les risques potentiels, serait plus attrayant que le désormais "libre" Java, qu'en pensez-vous ?

[sinok]

Bah ouais, en même temps faire du spécifique Gtk ou Gnome avec java c'est un peu se tirer une balle dans le pied alors que pour le même cout en dev (ou pas grand chose de plus) on peut avoir une appli portable...
Car si on compte le nombre d'appli SWT et Swing qui sont utilisées sous Linux (qui ne dois pas être faramineux non plus, genre Azureus, Eclipse/Netbeans, LimeWire par exemple)...

C'est un peu trollifère et à coté de la plaque comme comparaison. Tomboy et banshee ne sont rien de plus que des appli Gtk+/Gnome comme il y en a surement des paquets codées en python (toujours par exemple).

ET puis j'adore cette phrase

Code :

1
2
Eclipse 3.1 lacks features that MonoDevelop has, including code completion, integrated debugging, refactoring, and unit testing capabilities, Hargett claimed. "I've found in my consulting that people who install Eclipse 3.1 through the [Debian] package manager say, 'This is terrible.' " He said that customers that have installed a version of Eclipse beyond 3.1 like it.

Il n'a jamais eu l'occasion de toucher eclipse l'auteur. Ce sont des fonctionnalités qui datent d'eclipse 2 au minimum

[Bluespear]

Pour être en train de passer progressivement de Java+Swing à Qt(+Boost) dans mon développement je trouve plutôt osé de faire du C# sous Linux (je précise quand même que je n'ai que très peu touché à C#).

Ce langage dépend quand même exclusivement de Microsoft qui peut changer l'API quand bon lui semble et aura surtout une longueur d'avance permanente en version Windows (sur Mono). Et quand je vois le temps de sortie ainsi que le retard de la version Linux de Silverlight (Moonlight) j'ai vraiment tendance à ne pas vouloir utiliser ce genre de choses.

Bref, à voire, mais je ne m'attends pas à une révolution du développement GUI sous Linux grace à Mono, loin de là.

[Xitog]

Microsoft vient de passer le C# sous une licence qui protège les développeurs du monde libre de toutes "attaques aux brevets". Reste les libs, mais Gtk# n'en pose aucun.
http://tirania.org/blog/archive/2009/Jul-06.html

Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

[vintz72]

Envoyé par sinok

ET puis j'adore cette phrase

Il n'a jamais eu l'occasion de toucher eclipse l'auteur. Ce sont des fonctionnalités qui datent d'eclipse 2 au minimum

C'est clair que ça rend son article peu crédible ! Il ne sait visiblement pas du tout de quoi il parle ! Encore du beau boulot d'intox...

[martopioche]

Envoyé par Xitog

Microsoft vient de passer le C# sous une licence qui protège les développeurs du monde libre de toutes "attaques aux brevets". Reste les libs, mais Gtk# n'en pose aucun.
http://tirania.org/blog/archive/2009/Jul-06.html

Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

Je ne suis pas juriste, mais je n'ai pas vu que cette "promesse" était une licence. De ce fait, je ne vois là dedans aucun engagement de Microsoft sur le long terme, et les conditions sont assez drastiques. De ce fait, l'intervention récente de Richard Stallman est bien d'actualité.

Maintenant, concernant la préférence des développeurs, les Linuxiens n'ont jamais apprécié Java. De ce fait, Java n'a jamais vraiment percé en environnement Linux. On compare donc un nombre limité de projets à un autre nombre limité de projets. Car si dans les projets très grand publique, je ne connais que Vuze en Java, il n'en demeure que nombre d'autres applications sont en Java (une bonne partie de ce qui tourne autour d'OpenStreetMap à commencer par JOSM, les outils de gestion du tuxDroid, bien des applications de développement...).

En ce qui concerne l'opinion, pour moi, Mono ne doit avoir qu'une seule fonction : faire tourner en environnement Linux des applications produites spécifiquement pour .Net, mais en aucun cas un projet Linux ne devrait choisir Mono comme techno.

Sinok et Vintz : la plus grosse critique de l'article concerne le packaging d'Eclipse dans les distributions. Et il est vrai que les versions d'Eclipse des dépôts sont on ne peux plus buggy. Mais le problème est surtout qu'à mon sens, Eclipse de part son mode de fonctionnement n'a rien à faire dans les dépôts puisqu'il est mieux installé individuellement.

[leyee]

Pour moi c'est plus un sujet à troll qu'autre chose : il n'y a rien pour étayer cette affirmation. Personnellement je connais peu d'entreprises qui investissent dans du développement .NET sous Linux contrairement à celle qui développent en Java...

[Traroth2]

Mono ne m'intéresse pas parce qu'il est condamné à rester pour toujours un sous-dotnet. Les nouvelles fonctionnalités sont implémentées avec des mois de retard par rapport à la version de Microsoft, et parfois jamais, d'ailleurs, et son l'existence même, qui est une implémentation de technologies brevetées, est soumise au bon vouloir de Microsoft, qui a toujours évité de prendre des engagements définitifs permettant de dire "l'avenir de Mono est assuré". Il est évident qu'il est impossible pour une entreprise d'investir dans des applications écrites pour Mono, à mes yeux. Si vraiment Microsoft voulait "ouvrir" Dotnet de manière pérenne, il faudrait au minimum :

• Étendre à tous les composants de Dotnet l'Open Specification Promise
• Créer un organisme analogue au JCP permettant aux autres acteurs du monde Dotnet (Novell, Infragistics,Embarcadero...) de s'impliquer dans son évolution

[dingoth]

Dans le fond, le gars a pas tort : Java n'a rien foutu pour Swing depuis 5 ans (ou presque). Quelques bonnes avancées avec l'intégration bureau dans Java 1.5, mais depuis quasi rien pour l'utilisateur final. Même le thème par défaut est toujours le laid (oui, laid) Metal, et c'est au développeur de préciser qu'il veut une application avec un L&F "comme les autres".

Il faudrait que Java s'émancipe de son idée "support pour tous" et entame des améliorations du genre "support pour le plus grand nombre". Le Swing App Framework est un pas en ce sens, avec sa gestion automatique des informations de session. Un autre ajout intéressant pourrait être l'accès aisé (et unifié) à la base de registre de Windows, au Gconf de Gnome, ou autre. Mais bon, je rêve.

[robert_trudel]

le langage le plus utilisé pour des projets sur sourceforge est il me semble java...

[Traroth2]

Envoyé par dingoth

Dans le fond, le gars a pas tort : Java n'a rien foutu pour Swing depuis 5 ans (ou presque). Quelques bonnes avancées avec l'intégration bureau dans Java 1.5, mais depuis quasi rien pour l'utilisateur final. Même le thème par défaut est toujours le laid (oui, laid) Metal, et c'est au développeur de préciser qu'il veut une application avec un L&F "comme les autres".

C'est totalement faux. Java 1.5 et Java 6 ont marqué quelques très grosses avancées, concernant Swing : simplification de mise en oeuvre (SwingWorker), amélioration des performances, nouvelles fonctionnalités. Le Look and Feel par défaut, maintenant, c'est Nimbus, au fait. Et il a un aspect tout à fait sympa. Il est fondé sur le système de L&F skinnable Synth, introduit par Java 1.5, qui permet de modifier l'aspect de son L&F très facilement.

[pseudocode]

Envoyé par gorgonite

Selon certains experts, Mono serait désormais plus apprécié que Java par les développeurs d'applications pour station de travail en environnement GNU/Linux.

Stephen O'Grady, l'expert en question, est bien connu pour ces positions pro-Microsoft.

Cela dit, il est vrai que Sun n'a jamais fait les efforts nécessaires pour imposer Java comme solution crédible au développement d'applications de bureau : que ce soit sa toolkit propriétaire (awt), son API objet (swing), la lourdeur au démarrage de sa JVM (Hotspot) et son allocation mémoire a-priori, ...

Bref, plein de petites choses qui font préférer une application native, voir une application Mono. Dommage. J'espérais que la donne allait changer avec le projet JavaFX mais non.

[4mleth]

Bonjour,

J'espérais que la donne allait changer avec le projet JavaFX mais non

Il me semble pour ma part que Sun s'engage sur une piste glissante de ce côté-là. JavaFX est vu par pas mal de monde comme étant une tentative quelque peu désespérée de rattraper le train des RIA/RDA, dont la locomotive Flex a clairement une longueur d'avance. Pour moi, mettre en avant JavaFX au détriment de Swing, c'est une grave erreur de comm' de la part de Sun : Swing permet de faire de vraies appli desktop (une RDA en AIR sera toujours à des milles derrière une appli Swing ou Eclipse RCP en termes d'intégration au desktop et de performance). Beaucoup de développeurs ne se sentent-ils pas un peu trahis par ce foin autour des paillettes JavaFX ? Le navire Swing a pas mal chaviré ces derniers temps... Par exemple, le départ d'Hans Muller pour Adobe (alors à la tête du projet Swing Application Framework il me semble). J'ai ensuite été très très rassuré de voir que le JSR 296 avait été validé pour Java 7, et qu'il avait trouvé un nouveau porteur.
Quant à Nimbus : peut-être peut-il jouer le rôle de facteur d'acceptation supplémentaire de Java auprès des utilisateurs...

[pseudocode]

Envoyé par 4mleth

J'ai ensuite été très très rassuré de voir que le JSR 296 avait été validé pour Java 7, et qu'il avait trouvé un nouveau porteur.

Pour ma part, je pense que le problème est plus profond qu'une simplification du framework Swing.

Je trouve que le modèle objet n'est pas vraiment adapté au codage d'une IHM (d'une toolkit oui, mais pas d'une IHM). D'ailleurs l'utilisation des syntaxes déclaratives (JavaFx, XAML) semble prouver la chose.

Et je trouve aussi que le langage lui même manque de souplesse. Par exemple il manque l'équivalent des "méthodes anonymes" pour associer des actions a des évènements. Ou des moyens simples de gérer le multitache, la ré-entrance, ... au niveau du code.

Quant à Nimbus : peut-être peut-il jouer le rôle de facteur d'acceptation supplémentaire de Java auprès des utilisateurs...

Hum... A l'heure de l'intégration application/desktop et de la personnalisation a outrance des thèmes de bureau, je suis pas bien sûr qu'un énième thème "statique" spécifique à Java soit un facteur d'acceptation.

[dingoth]

Envoyé par Traroth2

C'est totalement faux. Java 1.5 et Java 6 ont marqué quelques très grosses avancées, concernant Swing : simplification de mise en oeuvre (SwingWorker), amélioration des performances, nouvelles fonctionnalités. Le Look and Feel par défaut, maintenant, c'est Nimbus, au fait. Et il a un aspect tout à fait sympa. Il est fondé sur le système de L&F skinnable Synth, introduit par Java 1.5, qui permet de modifier l'aspect de son L&F très facilement.

Désolé, mais pour une fois, je vais être sec : TOTALEMENT faux ? Non. S'il peut y a voir des erreurs, l'ensemble n'est pas TOTALEMENT faux. Quand j'écris quelque chose, qu'on le lise plutôt que le survoler ! « Totalement faux » impliquerait qu'il n'y a pas eu d'avancée du tout, ce qui contredit ton argumentation.

Mais au fait, qu'y a-t-il eu comme avancée pour l'utilisateur final (dans la lib standard et sans des "trucs") ? Les bureaux supportant la 3D ? L'uniformisation des menus d'aide afin d'avoir une API minimale commune ? L'intégration native de vidéo ? Un parser et renderer HTML un peu potable ? Le support de zones transparentes ? Voir même une TreeTable, un DatePicker ou un panneau rétractable ? Que nenni : on a du se contenter de tables triables, du double-buffering (pas trop tôt) et d'un splash-screen. Dans le registre intéressant, on a enfin eu l'intégration avec la barre des tâches et la classe Desktop.

Mais bon, je parle d'utilisateur final, on me répond avec le SwingWorker... Mais c'est pour les développeurs, ça, et même... pour les développeurs qui ne connaissaient pas bien l'EDT. Je n'ai plus réalisé d'application qui freeze depuis 2001 et à l'époque le SwingWorker, c'était une lib à part et souvent buggée.

Et puis, y'aura Java 7, à nouveau parent pauvre en ce qui concerne les applis bureaux, puisque nous n'aurons que Swing Application Framework. Pour les développeurs, y'aura même pas le beans-binding et c'est pas certain à 100% qu'on aie le beans-validation ou les JMC. (Merci JavaFx d'avoir piqué les développeurs de Swing au passage.)

En ce qui concerne le LaF, mea culpa, je parlais bien de Metal ne connaissant pas Nimbus (normal, je parlais de Java 6 aussi, pas Java 6 update 10), mais je viens de jeter un oeil à Nimbus : il ne vaut pas mieux. Par défaut, une application doit avoir un LaF système, et pas un truc pondu. Qu'on garde Nimbus et Metal pour les applets, ok, mais pas pour les applis desktop. En java, on est obligé de préciser qu'on veut pas de ces trucs laids. C'est pas normal. En tant qu'utilisateur final d'applications, j'entends voir une application utilisant le thème de mon système d'exploitation en priorité, puis des trucs customisés dans un recoin des préférences si c'est indispensable. Si j'ai choisi Clearlooks comme thème par défaut sur Linux, c'est pas pour me retrouver avec Metal (ou Nimbus).

Alors oui, Java est en retard dans les applications desktop, et je comprends parfaitement que les développeurs préfèrent Mono à Java pour l'instant.

[gege2061]

Envoyé par robert_trudel

le langage le plus utilisé pour des projets sur sourceforge est il me semble java...

http://www.ohloh.net/languages/compa...s&percent=true

Sur quelques 10 000 projets va me semble représentatif

(enfin si on exclu le HTML du comparatif )

[4mleth]

Ce graphique nous indique une tendance très nette à la hausse pour Mono, et un début de stagnation pour Java (montée linéaire jusqu'à 2006, puis, au même moment, montée pour Mono... on peut dire que les développeurs commencent à se répartir entre les deux camps ?).

Un peu hors sujet, maintenant... :

Je me permets de rebondir sur la remarque de pseudocode au sujet des syntaxes déclaratives pour les IHM (d'un côté Mono arrive avec XAML, et de l'autre, Java a bien du mal à trouver un truc efficace, peut-être XWT pour SWT, qui semble très prometteur).
En fait, il me semble que l'engouement pour ce type de syntaxe a quelque peu obombré le fait que dans certains cas, on doit bâtir des interfaces reconfigurables, non statiques, non déterminées à priori, ou encore dont la logique de structuration n'est pas nécessairement arborescente. Ca concerne sans doute moins de 2% des applications, mais dans ce cas, la syntaxe déclarative ne rend pas forcément service. Dans cette catégorie d'applications, on peut ranger certains outils auteurs de création multimédia, les applications qui ne se contentent pas d'aligner les widgets pour visualiser des données, des applications "très graphiques", etc. Oui, la syntaxe déclarative XML/YAML rationalise le développement dans 99% des cas, mais non, le développement d'IHM ne s'y résume pas intégralement. Et je trouve que le manque d'innovation "ergonomiques" côté programmatique est grave et gênant (cela vaut pour Java, mais sans doute pour bien d'autres langages).

Par contre je ne suis pas certain de comprendre :

Je trouve que le modèle objet n'est pas vraiment adapté au codage d'une IHM (d'une toolkit oui, mais pas d'une IHM). D'ailleurs l'utilisation des syntaxes déclaratives (JavaFx, XAML) semble prouver la chose.

.
La syntaxe déclarative reste 100% objet (une balise XML correspond à l'instanciation d'un nouvel objet, avec ses attributs, ses méthodes), et, dans le cas de Flex/ActionScript, l'articulation du syntaxique et du programmatique est fantastiquement flexible...

[eclesia]

Envoyé par gege2061

http://www.ohloh.net/languages/compa...s&percent=true

Jolie lien, je suis souvent sur ohloh mais je connaissais pas cette partie la.

Ce graphique nous indique une tendance très nette à la hausse pour Mono, et un début de stagnation pour Java (montée linéaire jusqu'à 2006, puis, au même moment, montée pour Mono... on peut dire que les développeurs commencent à se répartir entre les deux camps ?).

Le graphique ne parle pas de Mono mais juste de C#.

Je pense que la progression de C# vient en bonne partie du renouvellement quasi imposé des applications (remplacement de VB6 et VBA qui ne sont plus supporté par microsoft). Ca va stagner a un moment, d'ailleur si on regarde bien sa stagne deja depuis presque 1an.

[gege2061]

Envoyé par eclesia

Ca va stagner a un moment, d'ailleur si on regarde bien sa stagne deja depuis presque 1an.

C'est même en train de décliner de plus de 25% depuis le début de l'année : http://www.ohloh.net/languages/compa...asure=projects (attention un indice se cache sur le graphique )

[robert_trudel]

Envoyé par gege2061

http://www.ohloh.net/languages/compa...s&percent=true

Sur quelques 10 000 projets va me semble représentatif

(enfin si on exclu le HTML du comparatif )

hum, sourceforge c'est près de 180 000 projets...