Après Java, Apple ne proposera plus Flash par défaut sous OS X, Réactions à la publication du 23/10/2010

[proulout]

M'est avis que tant qu'à se taper une migration, y en a qui vont en profiter pour passer à Linux ou Windows...

J'ai installé Linux depuis 2 jours à cause de tout ça

[MacNiaque]

JEdit... Well, je préfère encore emacs dans mon terminal... Affaire de goût

Comme tu dis; et c'est loin d'être de la mauvaise foie car j'ai testé des dizaines d'éditeurs de code sous Mac (BBedit, Smultron, Subethaedit...) et pour ma part aucun n'arrive à la cheville de JEdit tant du point de vue de l'interface (que tu peux arranger comme tu veux) que des différents plugins. Le seul que je trouve bon (mais un poil moins) c'est Editra qui est lui aussi multi plateforme car écrit en Python.

L'argument sur l'économie de code... En ObjC++ on factorise une énorme quantité de code d'une plate forme à l'autre, ce qui n'est pas 'economisable' est la logique applicative/UI. Mais c'est sur ce terrain là que les plate forme de dev cross plate forme sont décevantes...

Niveau factorisation du code, tu arrives à la même chose que ce soit en ObjC, en Java, en C++...
Je pense pas que les bibliothèques multi-plateforme soient décevantes niveau GUI; il y a plusieurs excellentes API qui donnes des résultats qui n'ont rien à envier à des applis native Cocoa ou Carbon. Pour avoir longuement codé en wxWidgets qui reste pour moi la meilleure API de part sa conception, ses fonctions, son rendu et, choses trop souvent mise de coté, sa doc, je peux te dire qu'on peut faire des applis multi plateforme qui rendent comme si elles étaient natives et avec beaucoup plus de code en commun (heureusement, c'est le but) qu'avec du Cocoa.

On peur ne pas y être sensible, mais alors là, autant installer Windows sur son Mac car les applis java sous Windows font moins tache...

Je préfère de loin utiliser des applis Java bien codés sous MacOS X que sous Windows, je suis pas sous Mac grace ou à cause de Cocoa mais pour le Finder, le système, les logiciels...
Cocoa n'est pour moi qu'un outil, rien de plus.

[Guest_ps1024_*]

JEdit... Well, je préfère encore emacs dans mon terminal... Affaire de goût

Comme tu dis; et c'est loin d'être de la mauvaise foie car j'ai testé des dizaines d'éditeurs de code sous Mac (BBedit, Smultron, Subethaedit...) et pour ma part aucun n'arrive à la cheville de JEdit tant du point de vue de l'interface (que tu peux arranger comme tu veux) que des différents plugins. Le seul que je trouve bon (mais un poil moins) c'est Editra qui est lui aussi multi plateforme car écrit en Python.

J'ai juste installé JEdit pour voir, je ne jugerai donc pas la fonctionnalité, juste l'intégration avec Mac OS X que tu vantes plus haut... Désolé, mais ça ne ressemble pas du tout à une "vraie" application Mac : le glissé-déposé de texte ne fonctionne pas, les menus ne sont pas standards, les dialogues d'enregistrement c'est encore pire, ça ne supporte pas les services, si l'on ferme la fenêtre, la barre de menu disparaît et on ne peut pas ouvrir de nouvelles fenêtres, ...

Et c'est juste ce que j'ai constaté en deux minutes ! En aucun cas on ne peut dire que cette application "s'intègre parfaitement dans Mac OS X" comme tu le prétends.

Ce message a été modifié par ps1024 - 25 Oct 2010, 17:18.

[igerard]

JEdit... Well, je préfère encore emacs dans mon terminal... Affaire de goût

Comme tu dis; et c'est loin d'être de la mauvaise foie car j'ai testé des dizaines d'éditeurs de code sous Mac (BBedit, Smultron, Subethaedit...) et pour ma part aucun n'arrive à la cheville de JEdit tant du point de vue de l'interface (que tu peux arranger comme tu veux) que des différents plugins. Le seul que je trouve bon (mais un poil moins) c'est Editra qui est lui aussi multi plateforme car écrit en Python.

J'ai juste installé JEdit pour voir, je ne jugerai donc pas la fonctionnalité, juste l'intégration avec Mac OS X que tu vantes plus haut... Désolé, mais ça ne ressemble pas du tout à une "vraie" application Mac : le glissé-déposé de texte ne fonctionne pas, les menus ne sont pas standards, les dialogues d'enregistrement c'est encore pire, ça ne supporte pas les services, si l'on ferme la fenêtre, la barre de menu disparaît et on ne peut pas ouvrir de nouvelles fenêtres, ...

Et c'est juste ce que j'ai constaté en deux minutes ! En aucun cas on ne peut dire que cette application "s'intègre parfaitement dans Mac OS X" comme tu le prétends.

Évidemment...

je suis sur Mac en grande partie à cause du look & Feel et de Cocoa... Au niveau intégration pour ce qui est des éditeurs... Soyons sérieux 2 secondes... TextMate, Coda, Xcode4.... Ok pas de java très intégré dans ces applications là évidemment.

Au niveau applicatif grand public la liste est super longue des application OSX cocoa absolument superbes... qui ne peuvent pas être fait au même niveau en natif... J'ai fait 5 ans de Qt sous Windows et Solaris un peu et OSX aussi... Et pourtant qt4 est vraiment pas mal, la doc également...

Mais soyons clair dans mon taff y a des ultra qui ne jurent que par vi.... Donc restons en là

[MacNiaque]

JEdit... Well, je préfère encore emacs dans mon terminal... Affaire de goût

Comme tu dis; et c'est loin d'être de la mauvaise foie car j'ai testé des dizaines d'éditeurs de code sous Mac (BBedit, Smultron, Subethaedit...) et pour ma part aucun n'arrive à la cheville de JEdit tant du point de vue de l'interface (que tu peux arranger comme tu veux) que des différents plugins. Le seul que je trouve bon (mais un poil moins) c'est Editra qui est lui aussi multi plateforme car écrit en Python.

J'ai juste installé JEdit pour voir, je ne jugerai donc pas la fonctionnalité, juste l'intégration avec Mac OS X que tu vantes plus haut... Désolé, mais ça ne ressemble pas du tout à une "vraie" application Mac : le glissé-déposé de texte ne fonctionne pas, les menus ne sont pas standards, les dialogues d'enregistrement c'est encore pire, ça ne supporte pas les services, si l'on ferme la fenêtre, la barre de menu disparaît et on ne peut pas ouvrir de nouvelles fenêtres, ...

Pour le glisser deposer de texte entre applis, ça me sert tellement que je ne m'en était même pas rendu compte... Mais si c'est pour que ça mette le Path du fichier dans le texte comme c'est le cas de pas mal d'applis en Cocoa, mieux vaut comme ça car JEdit ouvre le fichier lorsqu'on le glisse dessus (Editra fait les deux). Pour les menus, mis à part les raccourcis clavier mal annotés (C au lieu de touche pomme) et le doublon "Quit JEdit" et "Exit", pour le reste c'est comme n'importe quel appli OSX. Les dialogues de gestions de fichier ne sont pas les standards Apple pour une bonne raison : JEdit propose des dizaines de fonctions qu'Apple ne propose pas dans ces dialogues de fichiers sans parler des Plugins (connection direct ftp ou scp par exemple); utiliser ceux d'Apple serait une catastrophe niveau fonctionnalités.
Après avoir fermé ta dernière fenêtre JEdit, tu peux en rouvrir une en cliquant juste sur l'icone JEdit ou en glissant/déposant un fichier dessus (mais je reconnaise qu'ils auraient pu mettre un menu "File" minimaliste, ça aurait été mieux.

[Guest_ps1024_*]

Les dialogues de gestions de fichier ne sont pas les standards Apple pour une bonne raison : JEdit propose des dizaines de fonctions qu'Apple ne propose pas dans ces dialogues de fichiers

Les dialogues standards peuvent être modifiés (ajout de bouton, menus, ...) par les applications natives, ce n'est donc pas une excuse valable.

[MacNiaque]

Les dialogues de gestions de fichier ne sont pas les standards Apple pour une bonne raison : JEdit propose des dizaines de fonctions qu'Apple ne propose pas dans ces dialogues de fichiers

Les dialogues standards peuvent être modifiés (ajout de bouton, menus, ...) par les applications natives, ce n'est donc pas une excuse valable.

Pour faire ce que fait JEdit, il faut les réécrire de toute façons, même s'il s'agissait d'une application Cocoa et Carbon. Il y a encore quelques années (je ne sais pas aujourd'hui), Adobe avait écrit ses propres dialogues de fichier pour afficher un aperçu de l'image ainsi que des informations que n'affiche pas normalement un dialogue de fichier. Alors effectivement en Cocoa on peut les "personnaliser" plus qu'on peut en Carbon mais pour permettre la navigation dans des systèmes de fichiers non prévus (archives, volumes réseaux...) il faut écrire ses propres dialogues.

Mais le problème est simple : tu pourras pas mobiliser suffisemment sous MacOS X et encore moins en Cocoa pour faire une appli de cette envergure. Si le mac ne peux plus demain executer du Java, il perdra purement et simplement ces logiciels, les dev ne vont pas, pour faire plaisir à SJ passer en Cocoa, surtout que la majorité ne sont pas sous Mac.

[Guest_ps1024_*]

C'est un point de vue qui se défendait quand Apple avait une minuscule part de marché. Ce n'est plus vrai aujourd'hui, avec 20 % du marché "retail" au US par exemple. Il est temps maintenant de pousser les technologies natives, qui font de Mac OS X ce qu'il est. Si c'est pour faire tourner des applications qui n'exploitent pas ses spécificités et se comportent comme sur Linux, ben... autant utiliser Linux ! Je comprend tout à fait le point de vue d'Apple de ne pas continuer à investir des ressources dans des technologies comme Java qui ne contribue pas à profiler Mac OS X, alors que ses concurrents (Windows et Linux) n'ont pas à fournir cet effort.

A supposer qu'à terme, Java disparaisse de Mac OS X, soit une application vise un public très restreint et disparaîtra (et sans doute une partie des ses utilisateurs avec, quoique une machine virtuelle Linux par exemple pourrait aussi faire l'affaire). Soit il y a un beaucoup d'utilisateurs potentiels, et donc une application native pourra voir le jour, surtout qu'elle sera libérée de la concurrence "déloyale" (en terme d'effort à fournir) des applications Java.

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Ce message a été modifié par ps1024 - 26 Oct 2010, 16:28.

[SartMatt]

C'est un point de vue qui se défendait quand Apple avait une minuscule part de marché. Ce n'est plus vrai aujourd'hui, avec 20 % du marché "retail" au US par exemple.

Mais le marché, ce n'est pas que le "retail"... Sur l'ensemble du marché US, Apple dépasse à peine les 10% aux dernières nouvelles, et sur le marché mondial, ils sont à moins de 5.3% : http://www.macworld.fr/2010/10/14/mac/appl...aux-usa/507303/

Ça reste peu pour justifier un portage de certaines applications... D'autant qu'il s'agit là de la part sur les ventes, pas sur le parc installé, où elle est encore inférieure...

Si c'est pour faire tourner des applications qui n'exploitent pas ses spécificités et se comportent comme sur Linux, ben... autant utiliser Linux !

Ce qui aurait été intelligent, ça aurait justement été de faire une JVM exploitant au mieux les spécificités de OS X, plutôt que d'abandonner la JVM... Ils auraient ainsi offert aux développeurs la possibilité de porter leurs applications Java sur Mac tout en exploitant les spécificités de la plateforme avec un coût de portage minimal...

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Si : parce que Java "desktop" est aussi énormément utilisé dans le monde des serveurs, où la part de marché de Linux est loin d'être aussi faible que celle d'Apple sur le marché des machines clientes...
Le nombre d'utilisateur reste certes supérieur, puisque les serveurs représentent relativement peu de machines, mais en termes d'importance du marché, pour une boîte comme Oracle qui est justement spécialisé dans des produits serveurs, 1 serveur Linux est plus important que 1000 Mac...

Ce message a été modifié par SartMatt - 26 Oct 2010, 16:57.

[igerard]

C'est un point de vue qui se défendait quand Apple avait une minuscule part de marché. Ce n'est plus vrai aujourd'hui, avec 20 % du marché "retail" au US par exemple.

Mais le marché, ce n'est pas que le "retail"... Sur l'ensemble du marché US, Apple dépasse à peine les 10% aux dernières nouvelles, et sur le marché mondial, ils sont à moins de 5.3% : http://www.macworld.fr/2010/10/14/mac/appl...aux-usa/507303/

Ça reste peu pour justifier un portage de certaines applications... D'autant qu'il s'agit là de la part sur les ventes, pas sur le parc installé, où elle est encore inférieure...

Si c'est pour faire tourner des applications qui n'exploitent pas ses spécificités et se comportent comme sur Linux, ben... autant utiliser Linux !

Ce qui aurait été intelligent, ça aurait justement été de faire une JVM exploitant au mieux les spécificités de OS X, plutôt que d'abandonner la JVM... Ils auraient ainsi offert aux développeurs la possibilité de porter leurs applications Java sur Mac tout en exploitant les spécificités de la plateforme avec un coût de portage minimal...

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Si : parce que Java "desktop" est aussi énormément utilisé dans le monde des serveurs, où la part de marché de Linux est loin d'être aussi faible que celle d'Apple sur le marché des machines clientes...
Le nombre d'utilisateur reste certes supérieur, puisque les serveurs représentent relativement peu de machines, mais en termes d'importance du marché, pour une boîte comme Oracle qui est justement spécialisé dans des produits serveurs, 1 serveur Linux est plus important que 1000 Mac...

Il y a 12 ans quelques amis très business, dans des postes de consulting très 'classe', disaient que le mieux pour Apple aurait été de séparer le hard du soft....

Apple, Steve et ses lieutenants, ont je pense des idées très précises de là où ils veulent aller, soyons humble.

Sinon, de mon point de vue, java n'apporte rien à la plate forme Apple, c'est ainsi, ou disons sur un secteur ridicule vu les part de marché en jeu. Je crois volontier à la viabilité d'une machine orientée java, mais le matos Apple n'est plus dans cette catégorie là.

Maintenant si Oracle considère que cela a du sens ecomiquement d'avoir une jvm de qualité sous OSX je suis certain que moyennant finance Apple leur donnera le support nécessaire pour la question. Apple s'allie à Unisys pour le marché pro... Ils veulent laisser à d'autres le soin de s'occuper de marchés qui ne sont pas assez intéressant pour eux, j'imagine que leur décision est commandé simplement par le ratio de retour sur investissement, il n'y a sans doute pas d'affectif la dedans.

[MacNiaque]

C'est un point de vue qui se défendait quand Apple avait une minuscule part de marché. Ce n'est plus vrai aujourd'hui, avec 20 % du marché "retail" au US par exemple.

Comme dit SartMatt, ton chiffre ne veut rien dire car il y a beaucoup de domaine dans lesquels le mac ne représente quasi rien.
Or lorsqu'une société s'interesse à la plateforme pour laquelle elle va développer, elle regarde le marché dans son domaine; le marché global elle s'en fout.

Il est temps maintenant de pousser les technologies natives, qui font de Mac OS X ce qu'il est. Si c'est pour faire tourner des applications qui n'exploitent pas ses spécificités et se comportent comme sur Linux, ben... autant utiliser Linux ! Je comprend tout à fait le point de vue d'Apple de ne pas continuer à investir des ressources dans des technologies comme Java qui ne contribue pas à profiler Mac OS X, alors que ses concurrents (Windows et Linux) n'ont pas à fournir cet effort.

Si Apple a besoin de s'enfermer dans des technologies propres pour faire valoir son OS, son interface... c'est que finalement MacOS X n'aurait aucun intérêt. Pour ma part, je pense que l'intérêt de MacOS X réside dans son OS, son interface (Aqua), dans le Finder... Non dans une technologie dont au final je me fous complètement lorsque j'utilise ma machine pour lire des mp3, aller sur le net, éditer un document...
Exploiter les spécificités d'OS X comme tu dis, c'est bien gentil mais dans 90% des cas, c'est pas ce qu'on demande à une appli; on lui demande plutot de faire ce qu'on attend d'elle.
Et le meilleur exemple est que des dizaines d'applis sont tout les jours utilisés par des gens qui ne savent pas du tout ce qu'est Cocoa ou Carbon sans qu'ils trouvent quoi que ce soit à redire à l'interface (Photoshop Elements ou Picassa par exemple qui sont en QT, Audacity qui est en wxWidgets).
Si Java n'exploite pas MacOS X, c'est aucunement de la faute de Java mais simplement de son implémentation et donc d'Apple lui même et c'est pas en abandonnant la chose que ça va être mieux.

A supposer qu'à terme, Java disparaisse de Mac OS X, soit une application vise un public très restreint et disparaîtra (et sans doute une partie des ses utilisateurs avec, quoique une machine virtuelle Linux par exemple pourrait aussi faire l'affaire). Soit il y a un beaucoup d'utilisateurs potentiels, et donc une application native pourra voir le jour, surtout qu'elle sera libérée de la concurrence "déloyale" (en terme d'effort à fournir) des applications Java.

Tu oublies une chose : les développeurs.
Et Java sous OS X ou non, ils ne vont pas se mettre à l'ObjC et à Cocoa pour faire plaisir à SJ. Donc si Java disparait d'OS X, ils partiront aussi et leurs soft disparaitront d'OS X.

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Linux est beaucoup plus implenté qu'OS X en entreprise. Or Java est indispensable pour faire tourner du JSP et pour faire tourner des applis server en général. Linux est aussi très présent sur des serveurs de prod, terminaux... où MacOS X est tout bonnement innexistant et où les applis Java sont légion.

Et il faut voir aussi que la version linux a en gros le même code que les versions pour les autres Unix (Solaris, BSD...) alors que sur Mac il faut réécrire toute l'interface.

[Guest_ps1024_*]

Ce qui aurait été intelligent, ça aurait justement été de faire une JVM exploitant au mieux les spécificités de OS X, plutôt que d'abandonner la JVM... Ils auraient ainsi offert aux développeurs la possibilité de porter leurs applications Java sur Mac tout en exploitant les spécificités de la plateforme avec un coût de portage minimal...

C'est ce qu'Apple a fait, on peut (on pouvait en tout cas, ça fait quelques années que je n'ai plus touché Java sur Mac) faire des applications qui sont difficile à distinguer d'applications natives. Mais peu d'applications Java sont dans ce cas, parce que ça marche aussi sans faire l'effort. Alors que si ton code est en C, et bien tu es obligé de refaire l'interface par exemple. Un exemple c'était par exemple Azureus (tout en Java sauf erreur) vs. Transmission (l'interface est native, le "moteur" est multi plateforme).

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Si : parce que Java "desktop" est aussi énormément utilisé dans le monde des serveurs, où la part de marché de Linux est loin d'être aussi faible que celle d'Apple sur le marché des machines clientes...

Le gros effort pour porter Java semble être l'intégration avec la GUI (SWT, AWT, Swing, ...) ce qui n'est pas nécessaire pour les applications serveurs. Voir OpenJDK par exemple, qui justement sur Mac ne peut passer que par X11. Si cet effort se justifie pour Linux, alors il se justifie aussi pour Mac OS X.

[Guest_ps1024_*]

C'est un point de vue qui se défendait quand Apple avait une minuscule part de marché. Ce n'est plus vrai aujourd'hui, avec 20 % du marché "retail" au US par exemple.

Comme dit SartMatt, ton chiffre ne veut rien dire car il y a beaucoup de domaine dans lesquels le mac ne représente quasi rien.
Or lorsqu'une société s'interesse à la plateforme pour laquelle elle va développer, elle regarde le marché dans son domaine; le marché global elle s'en fout.

C'est bien ce que je dis : si tu fais un jeu par exemple, la part de marché intéressante de Mac OS X, c'est le "consumer". Pas les serveurs et la bureautique en entreprise.

Si Apple a besoin de s'enfermer dans des technologies propres pour faire valoir son OS, son interface... c'est que finalement MacOS X n'aurait aucun intérêt.

Non, justement pas. Si c'est pour n'exploiter que des trucs multi plateformes, pourquoi ne pas utiliser Windows ?

Pour ma part, je pense que l'intérêt de MacOS X réside dans son OS, son interface (Aqua), dans le Finder... Non dans une technologie dont au final je me fous complètement lorsque j'utilise ma machine pour lire des mp3, aller sur le net, éditer un document...

La technologie en soit n'est pas le problème, le problème c'est les conséquence qu'elle a sur l'expérience utilisateur. Et force est de constater qu'une application écrite avec Cocoa aura plus de chance d'être réussie sur ce plan là qu'une application Java.

Exploiter les spécificités d'OS X comme tu dis, c'est bien gentil mais dans 90% des cas, c'est pas ce qu'on demande à une appli; on lui demande plutot de faire ce qu'on attend d'elle.

Dans ce cas, Mac OS X n'a plus de raison d'être : pourquoi développer un OS avec des fonctionnalités propres, si finalement on ne les utilisent pas ?

Si Java n'exploite pas MacOS X, c'est aucunement de la faute de Java mais simplement de son implémentation et donc d'Apple lui même et c'est pas en abandonnant la chose que ça va être mieux.

Non, non. On peut faire nettement mieux comme intégration en Java que JEdit par exemple. Simplement, c'est facultatif et donc ça n'est pas fait, c'est beaucoup plus simple de reprendre tout plus on moins tel quel et on arrive aux horreurs que je citais.

A supposer qu'à terme, Java disparaisse de Mac OS X, soit une application vise un public très restreint et disparaîtra (et sans doute une partie des ses utilisateurs avec, quoique une machine virtuelle Linux par exemple pourrait aussi faire l'affaire). Soit il y a un beaucoup d'utilisateurs potentiels, et donc une application native pourra voir le jour, surtout qu'elle sera libérée de la concurrence "déloyale" (en terme d'effort à fournir) des applications Java.

Tu oublies une chose : les développeurs.
Et Java sous OS X ou non, ils ne vont pas se mettre à l'ObjC et à Cocoa pour faire plaisir à SJ. Donc si Java disparait d'OS X, ils partiront aussi et leurs soft disparaitront d'OS X.

Justement, je crois que si, Apple l'a démontré avec l'iPhone : les utilisateurs feront venir le devs, quelques soient les conditions (ObjC + validation + 30% des revenus à Apple, c'est pas franchement la démarche la plus séductrice pour les devs).

[SartMatt]

Le gros effort pour porter Java semble être l'intégration avec la GUI (SWT, AWT, Swing, ...) ce qui n'est pas nécessaire pour les applications serveurs. Voir OpenJDK par exemple, qui justement sur Mac ne peut passer que par X11. Si cet effort se justifie pour Linux, alors il se justifie aussi pour Mac OS X.

Euh, c'est pas parce que c'est serveur qu'il y a pas de GUI hein... On est plus en 1980... À l'école, on faisait tourner des eclipse sur des serveurs Solaris, donc la partie GUI, elle est bien là sur le Java "serveur" (et pour cause, il n'y a pas de distinction client/serveur au niveau de la JRE, c'est la même pour les deux...).

Et justement, comme OS X intègre X11, si ils font un portage Mac, ils vont probablement pas se faire chier à porter la partie graphique, il la feront tourner sur X11, comme pour les versions Linux...

Ce message a été modifié par SartMatt - 26 Oct 2010, 18:25.

[Guest_ps1024_*]

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Linux est beaucoup plus implenté qu'OS X en entreprise. Or Java est indispensable pour faire tourner du JSP et pour faire tourner des applis server en général. Linux est aussi très présent sur des serveurs de prod, terminaux... où MacOS X est tout bonnement innexistant et où les applis Java sont légion.

Comme dit plus haut, ça n'est pas de faire un port pour serveur qui est compliqué, c'est la partie visible, donc pour le desktop. Et là Linux est loin derrière Mac OS X.

Et il faut voir aussi que la version linux a en gros le même code que les versions pour les autres Unix (Solaris, BSD...) alors que sur Mac il faut réécrire toute l'interface.

Ca fait toujours moins d'utilisateurs que Mac OSX, parce que côté Solaris et BSD il n'y a quasiment que du serveur.

[SartMatt]

A supposer qu'à terme, Java disparaisse de Mac OS X, soit une application vise un public très restreint et disparaîtra (et sans doute une partie des ses utilisateurs avec, quoique une machine virtuelle Linux par exemple pourrait aussi faire l'affaire). Soit il y a un beaucoup d'utilisateurs potentiels, et donc une application native pourra voir le jour, surtout qu'elle sera libérée de la concurrence "déloyale" (en terme d'effort à fournir) des applications Java.

Tu oublies une chose : les développeurs.
Et Java sous OS X ou non, ils ne vont pas se mettre à l'ObjC et à Cocoa pour faire plaisir à SJ. Donc si Java disparait d'OS X, ils partiront aussi et leurs soft disparaitront d'OS X.

Justement, je crois que si, Apple l'a démontré avec l'iPhone : les utilisateurs feront venir le devs, quelques soient les conditions (ObjC + validation + 30% des revenus à Apple, c'est pas franchement la démarche la plus séductrice pour les devs).

Tu oublies un "petit" détail là dedans : la part de marché d'Apple sur les smartphones, marché nouveau, est au moins 5 fois supérieure à la part de marché du Mac sur le marché des ordinateurs, marché déjà bien mature.
Donc forcément, les développeurs qui ARRIVENT sur le marché des applications smartphones, ils vont s'adapter à la plateforme dominante.
Par contre, sur le marché des applications pour ordinateurs, les développeurs en place depuis des années, ils ont pas forcément envie de s'adapter pour une plateforme qui représente même pas 5% du parc d'ordinateurs...

Cela dit, je pense que si Oracle continue le développement de Java "desktop" pour Linux, il n'y a aucune raison de ne pas le faire pour Mac OS X qui dispose de bien plus d'utilisateurs.

Linux est beaucoup plus implenté qu'OS X en entreprise. Or Java est indispensable pour faire tourner du JSP et pour faire tourner des applis server en général. Linux est aussi très présent sur des serveurs de prod, terminaux... où MacOS X est tout bonnement innexistant et où les applis Java sont légion.

Comme dit plus haut, ça n'est pas de faire un port pour serveur qui est compliqué, c'est la partie visible, donc pour le desktop. Et là Linux est loin derrière Mac OS X.

Et il faut voir aussi que la version linux a en gros le même code que les versions pour les autres Unix (Solaris, BSD...) alors que sur Mac il faut réécrire toute l'interface.

Ca fait toujours moins d'utilisateurs que Mac OSX, parce que côté Solaris et BSD il n'y a quasiment que du serveur.

Je te rappelle juste que Solaris, c'est l'Unix de Sun, le créateur de Java. Donc c'est assez logique que quelque soit le nombre d'utilisateur de cet OS, ils supportent toutes les fonctionnalités de Java dessus (autrement, ça serait comme si Apple arrêtait iTunes Mac pour se concentrer sur la version Windows...). À partir de là, pondre les version Linux est un effort minimal, voir quasi nul.
Pondre une version OS X qui passerait pas par X11 par contre, c'est une autre paire de manches...

[Guest_ps1024_*]

Le gros effort pour porter Java semble être l'intégration avec la GUI (SWT, AWT, Swing, ...) ce qui n'est pas nécessaire pour les applications serveurs. Voir OpenJDK par exemple, qui justement sur Mac ne peut passer que par X11. Si cet effort se justifie pour Linux, alors il se justifie aussi pour Mac OS X.

Euh, c'est pas parce que c'est serveur qu'il y a pas de GUI hein... On est plus en 1980...

Et justement, comme OS X intègre X11, si ils font un portage Mac, ils vont probablement pas se faire chier à porter la partie graphique, il la feront tourner sur X11, comme pour les versions Linux...

La GUI, c'est le boulot du client normalement. Je pense notamment à tout ce qui utilise Java en back-end dans les serveurs web, pour au final générer de l'HTLM pour l'utilisateur. Pour X11, logiquement c'est le prochain truc sur la liste (déjà que ça n'a jamais été installé par défaut).

[SartMatt]

Le gros effort pour porter Java semble être l'intégration avec la GUI (SWT, AWT, Swing, ...) ce qui n'est pas nécessaire pour les applications serveurs. Voir OpenJDK par exemple, qui justement sur Mac ne peut passer que par X11. Si cet effort se justifie pour Linux, alors il se justifie aussi pour Mac OS X.

Euh, c'est pas parce que c'est serveur qu'il y a pas de GUI hein... On est plus en 1980...

Et justement, comme OS X intègre X11, si ils font un portage Mac, ils vont probablement pas se faire chier à porter la partie graphique, il la feront tourner sur X11, comme pour les versions Linux...

La GUI, c'est le boulot du client normalement. Je pense notamment à tout ce qui utilise Java en back-end dans les serveurs web, pour au final générer de l'HTLM pour l'utilisateur.

C'est oublier qu'il y a aussi tout un tas d'outils d'administration qui tournent avec une GUI...
Et serveur, ce n'est pas que des serveurs d'applis web hein... Tu as aussi tous les serveurs destinés à accueillir des connexions de terminaux légers. Sur ces serveurs, on fait tourner toutes le même genre d'applications que sur une machine de bureau, seul le rendu étant déporté sur le client (c'est l'un des trucs bien pratiques avec X11 : chaque appli est un client X11, qui peut envoyer les commandes au serveur X11, qu'il soit local ou distant). Comme je te l'ai dit plus haut, dans mon école par exemple, on avait UN serveur Unix par promo (Solaris en 1ère année, AIX en 2A, Solaris en 3A), et tous les postes des salles informatique (entre 150 et 200 postes) étaient juste des petits TX Neoware, tout tournait sur les serveurs. Et là dessus, on faisait tourner des Firefox, des OpenOffice, mais aussi des eclipse. Donc la partie graphique de Java est bien présente sur les gros Unix pour serveurs...

Et sur mon premier boulot, on avait un serveur de gestion de sources qui utilisait PVCS sous AIX. Là aussi, l'interface graphique d'administration (en Java) fonctionnait parfaitement sur ces serveurs...

Pour X11, logiquement c'est le prochain truc sur la liste (déjà que ça n'a jamais été installé par défaut).

C'est sûr que, Apple allant vers toujours plus de fermeture, y a des chances que ça soit une des prochaines étapes... Faudrait surtout pas que les gros crades du monde Linux viennent salir le joli environnement Apple avec leurs applis moches mais fonctionnelles. C'est tellement mieux d'avoir plein de zolis machins graphiques qui servent à rien...

Ce message a été modifié par SartMatt - 26 Oct 2010, 18:50.

[Guest_ps1024_*]

Tu oublies un "petit" détail là dedans : la part de marché d'Apple sur les smartphones, marché nouveau, est au moins 5 fois supérieure à la part de marché du Mac sur le marché des ordinateurs, marché déjà bien mature.
Donc forcément, les développeurs qui ARRIVENT sur le marché des applications smartphones, ils vont s'adapter à la plateforme dominante.
Par contre, sur le marché des applications pour ordinateurs, les développeurs en place depuis des années, ils ont pas forcément envie de s'adapter pour une plateforme qui représente même pas 5% du parc d'ordinateurs...

C'est pas le pourcentage qui est intéressant, mais le nombre de clients potentiels que ça représente, c'est à dire le marché. Et celui des utilisateurs Mac OS X est maintenant suffisamment important, et croît de plus fortement, pour qu'Apple puisse se permettre d'être plus contraignant pour les devs en les incitant fortement à offrir la meilleure expérience utilisateur possible, pour faire encore croître le marché. Je pense que c'est la stratégie d'Apple, après avoir passé des années à vendre de la performance (les "super ordinateur" G5, les comparatifs Photoshop, ...). Super, mais c'est pas ça qui a beaucoup fait progresser le nombre d'utilisateurs. Le passage à Intel et surtout l'iPod puis l'iPhone, les a forcé à se recentrer sur ce qui a fait le succès du Mac à l'origine et à se remettre à vendre non pas un OS, des applications ou des ordinateurs, mais une expérience. C'est pas forcément ce que veut la majorité des utilisateurs, mais i y en a suffisamment pour que la plateforme soit viable.

Je te rappelle juste que Solaris, c'est l'Unix de Sun, le créateur de Java. Donc c'est assez logique que quelque soit le nombre d'utilisateur de cet OS, ils supportent toutes les fonctionnalités de Java dessus (autrement, ça serait comme si Apple arrêtait iTunes Mac pour se concentrer sur la version Windows...). À partir de là, pondre les version Linux est un effort minimal, voir quasi nul.
Pondre une version OS X qui passerait pas par X11 par contre, c'est une autre paire de manches...

Quand je vois JEdit, je me dit que ça serait pas pire sous X11 : )

Et serveur, ce n'est pas que des serveurs d'applis web hein... Tu as aussi tous les serveurs destinés à accueillir des connexions de terminaux légers. Sur ces serveurs, on fait tourner toutes le même genre d'applications que sur une machine de bureau, seul le rendu étant déporté sur le client (c'est l'un des trucs bien pratiques avec X11 : chaque appli est un client X11, qui peut envoyer les commandes au serveur X11, qu'il soit local ou distant). Comme je te l'ai dit plus haut, dans mon école par exemple, on avait UN serveur Unix par promo (Solaris en 1ère année, AIX en 2A, Solaris en 3A), et tous les postes des salles informatique (entre 150 et 200 postes) étaient juste des petits TX Neoware, tout tournait sur les serveurs. Et là dessus, on faisait tourner des Firefox, des OpenOffice, mais aussi des eclipse. Donc la partie graphique de Java est bien présente sur les gros Unix pour serveurs...

Et sur mon premier boulot, on avait un serveur de gestion de sources qui utilisait PVCS sous AIX. Là aussi, l'interface graphique d'administration (en Java) fonctionnait parfaitement sur ces serveurs...

Oui, mais concernant Java, ce que j'avais retenu c'est que côté "client" (desktop) ça ne sait jamais imposé, alors que côté serveur back end, c'est plus le cas. C'est pas très étonnant vu qui était derrière Sun en même temps. Mais ça n'est plus trop mon domaine, donc je n'affirme rien. En tout cas, si ça influe sur les chances de voir Java pour Mac OS X repris par Oracle, ça ne change pas grand chose à l'impact que pourrait avoir la disparition de Java sur Mac OS X.

Pour X11, logiquement c'est le prochain truc sur la liste (déjà que ça n'a jamais été installé par défaut).

C'est sûr que, Apple allant vers toujours plus de fermeture, y a des chances que ça soit une des prochaines étapes... Faudrait surtout pas que les gros crades du monde Linux viennent salir le joli environnement Apple avec leurs applis moches mais fonctionnelles. C'est tellement mieux d'avoir plein de zolis machins graphiques qui servent à rien...

Mouarf !

[SartMatt]

Tu oublies un "petit" détail là dedans : la part de marché d'Apple sur les smartphones, marché nouveau, est au moins 5 fois supérieure à la part de marché du Mac sur le marché des ordinateurs, marché déjà bien mature.
Donc forcément, les développeurs qui ARRIVENT sur le marché des applications smartphones, ils vont s'adapter à la plateforme dominante.
Par contre, sur le marché des applications pour ordinateurs, les développeurs en place depuis des années, ils ont pas forcément envie de s'adapter pour une plateforme qui représente même pas 5% du parc d'ordinateurs...

C'est pas le pourcentage qui est intéressant, mais le nombre de clients potentiels que ça représente, c'est à dire le marché.

Le pourcentage à une grande importance, car c'est lui qui va te déterminer la rentabilité du portage...

Faire un portage qui te fait augmenter tes frais de développement de plus de 50%, en augmentant ta cible de 5% (cas d'un portage vers Mac), c'est pas comme faire un portage qui te fait augmenter tes frais de développement de 50% en augmentant ta cible de plus de 100% (cas d'un portage vers iPhone...).

Et puis surtout, les développements iPhone, ce ne sont pour la plupart PAS des portages, mais bien des applis développées initialement sur iPhone, car plateforme dominante, et ensuite portées éventuellement (rarement...) vers d'autres plateformes mobiles.

Les positions sont donc inversées : une appli iPhone, ça se compare à une appli Windows. Et un portage Mac d'une appli Windows, ça se compare à un portage WinMo d'une application iPhone (et encore... le ratio WinMo/iPhone est bien plus grand que le ratio Windows/Mac...).

D'ailleurs, le manque de motivation des développeurs pour porter sur Mac, il saute aux yeux hein... Si la logithèque Mac est aujourd'hui plutôt bien fournie, c'est en majorité des applications exclusivement développées sur Mac, pas des applications développées initialement sur d'autres plateformes puis portées sur Mac. Et en compliquant de plus en plus le portage, Apple ne travaille pas à faire changer cet état de fait...

[igerard]

C'est sûr que, Apple allant vers toujours plus de fermeture, y a des chances que ça soit une des prochaines étapes... Faudrait surtout pas que les gros crades du monde Linux viennent salir le joli environnement Apple avec leurs applis moches mais fonctionnelles. C'est tellement mieux d'avoir plein de zolis machins graphiques qui servent à rien...

Un peu ridicule comme remarque, non ? Juste un peu réducteur sur les applications native OSX.

Ils cherchent à définir une ligne de produit qui leur est propre, ils se moquent complètement de ce qui est dans l'ordre des choses, pour une boite qui a rarement respecté les idées ayant pignon sur rue :

How Apple Got Everything Right By Doing Everything Wrong

ça me semble aller de soi.

Et il faut garder à l'esprit l'association avec Unisys... Tout n'est pas perdu côté techno standards pour le Mac, mais ce n'est pas Apple qui va s'en charger, that's all.

Et Apple me semble devenir autre chose, leur nouvelle position forte,leur cash... ça change la donne... L'histoire est intéressante pour le moins

Oui, mais concernant Java, ce que j'avais retenu c'est que côté "client" (desktop) ça ne sait jamais imposé, alors que côté serveur back end, c'est plus le cas. C'est pas très étonnant vu qui était derrière Sun en même temps. Mais ça n'est plus trop mon domaine, donc je n'affirme rien. En tout cas, si ça influe sur les chances de voir Java pour Mac OS X repris par Oracle, ça ne change pas grand chose à l'impact que pourrait avoir la disparition de Java sur Mac OS X.

Là où je bosse, nous utilisons massivement Java pour les serveur d'application, mais les interfaces graphiques sont faites avec d'autres technos... Et ce n'est pas un petit éditeur!

Et on fait tourner Eclipse sous Windows pour les devs... Le mac n'existe pas dans cet univers là... Apple prend juste la mesure de la vanité de chercher à rester sur ce créneau alors que les jeux sont faits depuis un bail.


Ce message a été modifié par igerard - 26 Oct 2010, 20:00.

[Guest_ps1024_*]

C'est pas le pourcentage qui est intéressant, mais le nombre de clients potentiels que ça représente, c'est à dire le marché.

Le pourcentage à une grande importance, car c'est lui qui va te déterminer la rentabilité du portage…

Non, car si le volume n'est pas intéressant pour l'éditeur de la version Windows, tant pis, ou plutôt tant mieux pour un éditeur plus petit qui lui se contentera du seul marché Mac en développant une application que pour Mac OS X.

Si la logithèque Mac est aujourd'hui plutôt bien fournie, c'est en majorité des applications exclusivement développées sur Mac, pas des applications développées initialement sur d'autres plateformes puis portées sur Mac. Et en compliquant de plus en plus le portage, Apple ne travaille pas à faire changer cet état de fait...

Pourquoi changer cet état fait alors que la plateforme se porte mieux que jamais ? Il faut au contraire continuer sur cette lancée, ce qu'Apple indique bien vouloir faire avec le Mac App Store, dont les restrictions techniques ne concernent justement pas les applications qui sont développées que pour Mac OS X.

[MacNiaque]

Là où je bosse, nous utilisons massivement Java pour les serveur d'application, mais les interfaces graphiques sont faites avec d'autres technos... Et ce n'est pas un petit éditeur!

Les interface de config aussi ?
Car c'est là que Java est très présent et comme en parlais SartMatt, grace à X11 et XMing ça s'affiche directement sous Windows. Quand tu bosses dans de la prod, les interfaces de config et de gestions en Java sont courantes.

[MacNiaque]

Si Apple a besoin de s'enfermer dans des technologies propres pour faire valoir son OS, son interface... c'est que finalement MacOS X n'aurait aucun intérêt.

Non, justement pas. Si c'est pour n'exploiter que des trucs multi plateformes, pourquoi ne pas utiliser Windows ?

Si MacOS X est mieux que les autres, alors il y a un intérêt à y utiliser ses applications. Sinon, si MacOS X n'est pas meilleur que les autres voir moins bon, mieux vaut utiliser autre chose effectivement.
Mais c'est là qu'Apple doit se différencier, par le Finder, par Aqua... et c'est parce que je pense qu'OSX est meilleur en tel que tel que je l'utilise, pas parce qu'il y a tel ou tel application dessus car dans ce cas là où est l'intérêt d'utiliser OSX sachant que Windows a des dizaines de fois plus d'applis et que c'est pas prêt de changer en faveur d'OSX.

Pour ma part, je pense que l'intérêt de MacOS X réside dans son OS, son interface (Aqua), dans le Finder... Non dans une technologie dont au final je me fous complètement lorsque j'utilise ma machine pour lire des mp3, aller sur le net, éditer un document...

La technologie en soit n'est pas le problème, le problème c'est les conséquence qu'elle a sur l'expérience utilisateur. Et force est de constater qu'une application écrite avec Cocoa aura plus de chance d'être réussie sur ce plan là qu'une application Java.

Les concéquences des technos sur les softs, elles ont 2 origines : d'abord celui qui fait la techno, en l'occurence Apple pour ce qui est de Java et ensuite les développeurs du soft à savoir s'il y en a au moins un pour faire les tests de l'applis sur la plateforme (ici OSX) et corriger les problème éventuels d'intégration. Quand tu n'as même pas cette personne pour faire ce boulot de quelques dizaines d'heures tout au plus, comment peux-tu immaginer qu'il va y avoir une équipe qui va se monter pour faire une version mac avec cette fois les centaines d'heures que ça va demander, ça a pas de sens ?
Donc on va se retrouver avec moins d'applis et/ou des applis de moins bonne qualité.

Je vais te donner une anecdote toute bête : il y a quelques années, j'utilisais un éditeur d'interface PalmOS (il s'appelait de mémoire PRCEdit) codé en Java. J'étais le seul connu à l'utiliser sous OSX. Je l'ai testé et j'ai corriger dans le class pour que la barre de menu s'affiche bien en haut de l'écran et plus en haut de la fenêtre.
S'il n'y avait pas eu de Java sous OSX ou s'il avait (ce qui revient au même en fait) été codé en win32, je l'aurais utilisé sous Windows et le mac n'aurait jamais eu d'éditeur d'interface PalmOS car je ne me serais pas taper le dev d'un tel éditeur.

Exploiter les spécificités d'OS X comme tu dis, c'est bien gentil mais dans 90% des cas, c'est pas ce qu'on demande à une appli; on lui demande plutot de faire ce qu'on attend d'elle.

Dans ce cas, Mac OS X n'a plus de raison d'être : pourquoi développer un OS avec des fonctionnalités propres, si finalement on ne les utilisent pas ?

Les fonctionnalités d'OSX n'ont justement rien à voir avec Cocoa ou Carbon. C'est spotlight, c'est TimeMachine, c'est le finder, c'est la navigation dans les repertoires, c'est le dock, c'est la bare de menu... Tout ça se sont les fonctionnalités de MacOS X et quel que soit ce qui est utilisé pour créer l'appli, quel que soit le langage, l'API, la VM ça peux marcher et ça n'impose aucunement une écriture spécifique de l'appli ou de son interface.

Ca fait toujours moins d'utilisateurs que Mac OSX, parce que côté Solaris et BSD il n'y a quasiment que du serveur.

Détrompe toi, Solaris tourne sur quantité de machines de prod et de stations de travail, beaucoup plus que de mac (d'ailleurs j'ai jamais vu un mac dans une quelquonque prod).
Pour te donner un exemple tout bête, toutes les imprimantes de prod Xerox sont systèmatiquements fournis qu'elles soient loués ou achetés avec une station de travail Sun sous Solaris et les dernières versions de l'appli de gestions des flux est entièrement en Java, y compris son GUI.

[Guest_ps1024_*]

Si Apple a besoin de s'enfermer dans des technologies propres pour faire valoir son OS, son interface... c'est que finalement MacOS X n'aurait aucun intérêt.

Non, justement pas. Si c'est pour n'exploiter que des trucs multi plateformes, pourquoi ne pas utiliser Windows ?

Si MacOS X est mieux que les autres, alors il y a un intérêt à y utiliser ses applications. Sinon, si MacOS X n'est pas meilleur que les autres voir moins bon, mieux vaut utiliser autre chose effectivement.
Mais c'est là qu'Apple doit se différencier, par le Finder, par Aqua... et c'est parce que je pense qu'OSX est meilleur en tel que tel que je l'utilise, pas parce qu'il y a tel ou tel application dessus car dans ce cas là où est l'intérêt d'utiliser OSX sachant que Windows a des dizaines de fois plus d'applis et que c'est pas prêt de changer en faveur d'OSX.

Justement, il faut avoir des applications uniques ! Des utilisateurs sont passés de Windows à Mac pour avoir iMovie et iDVD parce qu'il n'y avait pas d'offre comparable sur Windows. De plus, Mac OS X, ça n'est pas que le Finder ou Aqua (respectivement, un gestionnaire de fichier et une interface graphique). Un OS, c'est l'ensemble des technologies mise à disposition des applications. De plus, justement, pas mal d'applications Java massacrent Aqua… Sérieusement, si Java était si génial (le langage l'est, en passant), tout le monde l'utiliserait et pourrait déployer sur toutes les plateformes pour quasiment le prix d'un seul développement (le fameux "write once, run anywhere" de Sun). Pourtant, c'est resté marginal sur le "desktop".

Je vais te donner une anecdote toute bête : il y a quelques années, j'utilisais un éditeur d'interface PalmOS (il s'appelait de mémoire PRCEdit) codé en Java. J'étais le seul connu à l'utiliser sous OSX. Je l'ai testé et j'ai corriger dans le class pour que la barre de menu s'affiche bien en haut de l'écran et plus en haut de la fenêtre.
S'il n'y avait pas eu de Java sous OSX ou s'il avait (ce qui revient au même en fait) été codé en win32, je l'aurais utilisé sous Windows et le mac n'aurait jamais eu d'éditeur d'interface PalmOS car je ne me serais pas taper le dev d'un tel éditeur.

Il n'y en aurait pas eu, ce qui aurait posé problème à … un utilisateur ! C'est clair que ça, ça va motiver Apple a continuer le développement de Java…
Et encore, maintenant le problème se résout gratuitement via Virtual Box et Ubuntu par exemple, qui feront très bien l'affaire pour faire tourner un logiciel qui n'exploite aucune technologies de Mac OS X.

Les fonctionnalités d'OSX n'ont justement rien à voir avec Cocoa ou Carbon. C'est spotlight, c'est TimeMachine, c'est le finder, c'est la navigation dans les repertoires, c'est le dock, c'est la bare de menu…

C'est un tout. Spotlight, si les applications ne fournissent pas de modules d'importation, ça ne sert à rien. Idem pour QuickLook. Pour Spotlight et Time Machine, il faut aussi que chaque élément unitaire (un messages par exemple) soit stocké sous forme de fichier et non pas dans une base monolithique comme le fait Entourage). Spaces demande aussi un minimum de coopération de la part de l'application (Office 2008 par exemple n'est pas totalement compatible et c'est TRÈS pénible). C'est aussi l'intégration avec iCal, le carnet d'adresses, etc…

Ca ne signifie pas renoncer à toute portabilité. Je donnais l'exemple du client BitTorrent Transmission, dont le back-end est portable, mais qui est ensuite intégré dans une application totalement native. Sur Linux le front-end est en GTK. Natif des deux côté. Résultat, plutôt qu'un résultat très moyen comme JEdit où visiblement on s'est économisé, comme souvent, le travail d'intégration, on a une vrai application Mac qui supporte par exemple QuickLook. C'est aussi plus ou moins l'approche suivie pour Thunderbird (qui utilise cependant des couches d'abstraction en plus).

Ca fait toujours moins d'utilisateurs que Mac OSX, parce que côté Solaris et BSD il n'y a quasiment que du serveur.

Détrompe toi, Solaris tourne sur quantité de machines de prod et de stations de travail, beaucoup plus que de mac (d'ailleurs j'ai jamais vu un mac dans une quelquonque prod).

Ca je m'en serais un peu douté...

Pour te donner un exemple tout bête, toutes les imprimantes de prod Xerox sont systèmatiquements fournis qu'elles soient loués ou achetés avec une station de travail Sun sous Solaris et les dernières versions de l'appli de gestions des flux est entièrement en Java, y compris son GUI.

Ca ne change rien à la pertinence de la stratégie d'Apple vu que ces marchés, que se soit du serveur ou des machines de production, sont des marchés où le Mac est virtuellement inexistant.

Cela dit, je n'ai rien contre Java que j'ai utilisé, y compris pour développer des applications "in house". Ca a plein d'avantages, mais certainement pas celui d'inciter à exploiter toutes les possibilités d'une plateforme, ou de s'intégrer au mieux dans "l'expérience utilisateur" de Mac OS X. D'où à mon avis la volonté d'Apple de ne plus la développer.

[igerard]

Là où je bosse, nous utilisons massivement Java pour les serveur d'application, mais les interfaces graphiques sont faites avec d'autres technos... Et ce n'est pas un petit éditeur!

Les interface de config aussi ?
Car c'est là que Java est très présent et comme en parlais SartMatt, grace à X11 et XMing ça s'affiche directement sous Windows. Quand tu bosses dans de la prod, les interfaces de config et de gestions en Java sont courantes.

Je n'y suis que depuis 2 mois... je ne connais pas toute la collection d'innombrables outils présent ... mais pour ce qui est des applications finales pour les consultants ou les clients, les interfaces sont Web non java, config et prod. Et ce n'est pas prêt de changer, puisque nous défrichons de nouvelles technos mais ce sont des technos web non java.

-----

Pour le sujet qui nous intéresse, je dois dire que ce que j'attends des éditeurs de soft sous OSX c'est qu'ils écrivent des applications natives du type : iLife, iWork, Omni*, Coda, CSSEdit, PixelMator ... etc

Un exemple important qui motive ma position, les 3 dernières années j'ai bossé énormément sur le standard XBRL basé sur XML, j'ai donc eu besoin d'outils XML mais sincèrement j'ai abandonné l'utilisation des différents outils java sous OSX, je bossais avec sous Windows, car sous OSX c'était vraiment décevant. Tu t'en contente, considérant que la fonction prévaut... Pas moi, désolé

Ce message a été modifié par igerard - 27 Oct 2010, 02:41.

[MacNiaque]

Pour le sujet qui nous intéresse, je dois dire que ce que j'attends des éditeurs de soft sous OSX c'est qu'ils écrivent des applications natives du type : iLife, iWork, Omni*, Coda, CSSEdit, PixelMator ... etc

C'est là qu'il y a un vrai différent parce que dans ce que tu cites, il y a pour moi 2 véritables taches du mac : iWork et PixelMator. Des soft qui (PixelMator est de loin le pire) ne respectent absolument pas les Apple Guidelines, qui font vraiment taches dans MacOS X et ont sacrifiés au joli l'intuitivité et la fonctionnalité. Les meilleurs exemples de ce que je veux éviter d'utiliser.
Plutot que PixelMator, j'attend d'une appli de retouche d'images qu'elle s'intègre un minimum à OS X comme c'est le cas d'un Graphic Converter ou d'un Photoline32.
Pareil pour la bureautique, je préfère de loin utiliser Office 2004 ou même Appleworks 6 qu'iWorks !

[igerard]

Pour le sujet qui nous intéresse, je dois dire que ce que j'attends des éditeurs de soft sous OSX c'est qu'ils écrivent des applications natives du type : iLife, iWork, Omni*, Coda, CSSEdit, PixelMator ... etc

C'est là qu'il y a un vrai différent parce que dans ce que tu cites, il y a pour moi 2 véritables taches du mac : iWork et PixelMator. Des soft qui (PixelMator est de loin le pire) ne respectent absolument pas les Apple Guidelines, qui font vraiment taches dans MacOS X et ont sacrifiés au joli l'intuitivité et la fonctionnalité. Les meilleurs exemples de ce que je veux éviter d'utiliser.
Plutot que PixelMator, j'attend d'une appli de retouche d'images qu'elle s'intègre un minimum à OS X comme c'est le cas d'un Graphic Converter ou d'un Photoline32.
Pareil pour la bureautique, je préfère de loin utiliser Office 2004 ou même Appleworks 6 qu'iWorks !

Oui nous n'avons pas les mêmes valeurs... Ce que tu appelle OSX ressemble furieusement a MacOS 6...

[MacNiaque]

Des utilisateurs sont passés de Windows à Mac pour avoir iMovie et iDVD parce qu'il n'y avait pas d'offre comparable sur Windows. De plus, Mac OS X, ça n'est pas que le Finder ou Aqua (respectivement, un gestionnaire de fichier et une interface graphique). Un OS, c'est l'ensemble des technologies mise à disposition des applications. De plus, justement, pas mal d'applications Java massacrent Aqua… Sérieusement, si Java était si génial (le langage l'est, en passant), tout le monde l'utiliserait et pourrait déployer sur toutes les plateformes pour quasiment le prix d'un seul développement (le fameux "write once, run anywhere" de Sun). Pourtant, c'est resté marginal sur le "desktop".

Le fait qu'une techno puisse être mal utilisé ne signifie pas que la techno soit mauvaise. Java est bon pour certaines choses, une catastrophe pour d'autres, comme l'est aussi Cocoa, Carbon, Python et toutes les technos.
Le bon outil pour le bon travail.
Dire qu'iMovie et iDVD peuvent justifier de passer de Windows à MacOS X, le marketting autour surement mais tu prends rien que les softs Ulead, ils permettent de faire tout ce que permet iMovie et iDVD (et même bien plus depuis la disparition des plugins dans iMovie) tout aussi facilement. Et je cite Ulead parce que je le connais mais il y en a surement d'autres.

Je vais te donner une anecdote toute bête : il y a quelques années, j'utilisais un éditeur d'interface PalmOS (il s'appelait de mémoire PRCEdit) codé en Java. J'étais le seul connu à l'utiliser sous OSX. Je l'ai testé et j'ai corriger dans le class pour que la barre de menu s'affiche bien en haut de l'écran et plus en haut de la fenêtre.
S'il n'y avait pas eu de Java sous OSX ou s'il avait (ce qui revient au même en fait) été codé en win32, je l'aurais utilisé sous Windows et le mac n'aurait jamais eu d'éditeur d'interface PalmOS car je ne me serais pas taper le dev d'un tel éditeur.

Il n'y en aurait pas eu, ce qui aurait posé problème à … un utilisateur ! C'est clair que ça, ça va motiver Apple a continuer le développement de Java…
Et encore, maintenant le problème se résout gratuitement via Virtual Box et Ubuntu par exemple, qui feront très bien l'affaire pour faire tourner un logiciel qui n'exploite aucune technologies de Mac OS X.

A pensser comme ça, on va pas faire une appli pour 10 utilisateurs, puis franchement, 1000 utilisateurs qu'est-ce qu'on s'en fout... Demain il va manquer des dizaines d'applis au mac, applis qui aujourd'hui existent et fonctionnent dessus.
Tu m'explique où elle est l'intégration avec OS X si tu fais tourner des applis dans VirtualBox ???
Il ne faut pas tout mélanger. Si autant sur un Smartphone on est pas à compter les applis ni a pester pour quelques fonctions en moins; ici on parle d'un ordinateur où l'offre logiciel est primordiale.

Ca ne signifie pas renoncer à toute portabilité. Je donnais l'exemple du client BitTorrent Transmission, dont le back-end est portable, mais qui est ensuite intégré dans une application totalement native. Sur Linux le front-end est en GTK. Natif des deux côté. Résultat, plutôt qu'un résultat très moyen comme JEdit où visiblement on s'est économisé, comme souvent, le travail d'intégration, on a une vrai application Mac qui supporte par exemple QuickLook. C'est aussi plus ou moins l'approche suivie pour Thunderbird (qui utilise cependant des couches d'abstraction en plus).

Transmission a néanmoins 2 "particularités" qui pemettent ça : il s'agit d'un client Bittorrent, type d'application à même de mobiliser suffisemment de contributeurs et il s'agit d'une interface relativement simple. C'est pas du tout possible de faire ça avec un logiciel comme JEdit puisque ça demanderais un travail considérable pour copier l'appli de base et on perdrais tout les plugins qui font tout l'intérèt du logiciel. Au final on se retrouverais avec un éditeur de code comme les actuels disponibles sur Mac avec la moitié des options indispensables absentes.
Pour Thunderbird, il utilise l'API de Mozilla, comme Kompozer et surtout Firefox. S'il n'y avait pas Firefox, il y a toute les chances pour que ces applis auraient étés beaucoup moins bonnes sur Mac.

[Guest_ps1024_*]

Dire qu'iMovie et iDVD peuvent justifier de passer de Windows à MacOS X, le marketting autour surement mais tu prends rien que les softs Ulead, ils permettent de faire tout ce que permet iMovie et iDVD (et même bien plus depuis la disparition des plugins dans iMovie) tout aussi facilement. Et je cite Ulead parce que je le connais mais il y en a surement d'autres.

C'était il y a une dizaine d'année. Avoir des applications qui n'existent pas ailleurs est important pour l'attrait de Mac OS X. Sinon, autant faire "comme la majorité" et acheter un PC avec Windows.

Tu m'explique où elle est l'intégration avec OS X si tu fais tourner des applis dans VirtualBox ???

Justement, ça augmente l'intérêt de développer une application native. C'est clairement la stratégie d'Apple avec le Mac App Store ? Vous voulez profiter de la visibilité qu'il offre ? Et bien, faite une application native de qualité qui pourra facilement exploiter les technologies spécifiques de Mac OS X. S'il s'agit d'un portage, elle ne sera pas forcément meilleure que l'originale, mais au moins elle s'en différenciera. C'est ça le point central, sinon comme déjà dit, autant faire comme la majorité et utiliser Windows.