Interview : quel avenir pour Java sur Mac ?

Christophe Laporte |
Peu après la présentation « succincte » de Mac OS X Lion, Apple faisait discrètement savoir qu’elle allait cesser de proposer sa propre implémentation de Java avec son système d’exploitation. L’affaire a fait grand bruit jusqu’à ce qu’Apple et Oracle annoncent qu’elles allaient travailler conjointement au portage d’OpenJDK pour Mac OS X (lire : Java : un accord entre Apple et Oracle).

D’autre part, Apple s’engage à fournir Java SE 6 avec Snow Leopard et Lion. Par contre, les prochaines versions à commencer par Java SE 7 seront disponibles auprès d’Oracle. Pour Bertrand Serlet, senior vice president of Software Engineering d’Apple, c’est une bonne nouvelle pour les utilisateurs Mac : « Nous sommes ravis de travailler avec Oracle pour que nos utilisateurs continuent de bénéficier d'une version Java très performante sur Mac ».

Cet accord est-il une bonne chose pour l’utilisateur Mac ? Va-t-on vers une meilleure prise en charge de Java sur Mac OS X ? Comme l’indiquait Steve Jobs à un utilisateur mécontent, Java sur Mac a presque toujours un train de retard (lire : Steve Jobs répond sur Java et Mac OS X). De plus, en matière de sécurité, Apple n’a pas toujours été irréprochable (lire : Java sur Mac se traîne des failles depuis six mois).

Afin de faire le point, nous avons demandé à Emmanuel Puybaret et Henri Gomez, deux spécialistes de Java sur Mac ce qu’ils pensaient des récentes annonces d’Apple et d’Oracle.

Emmanuel Puybaret est développeur et formateur Java, il a écrit plusieurs ouvrages spécialisés (notamment Les Cahiers du programmeur : Java 1) et est l’auteur de Sweet Home 3D, un logiciel libre d'aménagement d'intérieur lequel est écrit en Java (lire : Sweet Home 3D passe la troisième).

De son côté, Henri Gomez est un développeur Java de longue date impliqué dans bon nombre de projets open source. Il tient un blog sur lequel il partage ses découvertes sur (entre autres) tout ce qui touche à OpenJDK.


Quelle est votre lecture de l'annonce faite conjointement par Apple et Oracle ?

- Emmanuel Puybaret : C'est une très bonne nouvelle. Non seulement, on est assuré d'avoir Java SE 6 dans Mac OS X Lion ce qui permettra à tous les programmes Java existants de continuer à fonctionner, mais en plus Java SE 7 sera disponible librement sous Mac OS X via OpenJDK. Par ailleurs, Apple va contribuer activement avec Oracle à cette version libre, gage d'une intégration correcte de Java dans Mac OS X.

- Henri Gomez : Ma lecture est qu'Apple se concentre sur ses technologies propres, XCode, ObjectiveC, Cocoa, OS X et iOS. Le projet OpenJDK était une excellente opportunité pour Apple de se dégager de la maintenance Java tout en reversant dans un projet GPL (c'est important), ses adaptations pour OS X et Cocoa.

J'imagine que les équipes d'Apple font contribuer le code OS X et qu'ensuite il est probable qu'ils le laissent vivre et évoluer par le soutien de la communauté.

Le rachat de Sun par Oracle concrètement a-t-il changé beaucoup de choses concernant Java ? Le fait que Larry Ellison et Steve Jobs s'entendent bien a-t-il pu faire évoluer les choses selon vous ?

- Emmanuel Puybaret : Peut-être, mais alors l'amitié et le business ne doivent pas faire si bon ménage dans leur cas, car annoncer l'abandon de Java sans donner aucune suite pendant 3 semaines, j'appelle ça un coup de couteau dans le dos plutôt qu'une preuve d'amitié, non ?


Bien que l'annonce du rachat de Sun date d'il y a 18 mois, l'intégration de Sun ne s'est effectuée dans les faits que récemment et Oracle commence à dévoiler petit à petit sa stratégie : annonce de Java SE 7 pour la mi 2011 qui ne comportera finalement que les nouvelles fonctionnalités déjà développées (le fameux plan B), IBM et Apple qui rejoignent OpenJDK, procès contre Google... Qu'on apprécie ou non certaines décisions, on sent que Java commence à revivre enfin après une longue période de léthargie.


- Henri Gomez : Sujet délicat. Le rachat de Sun par Oracle va énormément changer l'écosystème Java et cela a déjà commencé. Ce que Sun n'a pas su faire, autrement dit monétiser Java, Oracle saura le faire.

Par contre, on assiste à énormément de départs en masse de pointures Java, des profils très techniques et pointus. Cela peut être inquiétant pour le futur, même si souvent ils rejoignent des structures plus petites qui oeuvrent aussi dans l'écosystème Java.

Pour les relations entre Larry Ellison et Steve Jobs, je pense que cela a dû aider à pousser Apple vers OpenJDK (ou OpenJDK vers Apple). Je perçois aussi un recentrage des activités, le poste utilisateur chez Apple sur iOS/OS X et ce qui est serveur chez Oracle.

- Est-ce une bonne chose pour les développeurs Java sur Mac ?

- Emmanuel Puybaret : Définitivement, si Apple et Oracle tiennent leurs promesses bien sûr. À terme, les mises à jour Java pour Mac OS X pourront sortir en même temps que leurs cousines sous Windows, Linux et Solaris. Et les développeurs pourront contribuer à corriger des bugs ou proposer des améliorations sans attendre le bon vouloir d'Apple comme jusqu'à maintenant.

- Henri Gomez : Qu'Apple rejoigne OpenJDK, absolument puisque cela va devenir le Java commun à toutes les plateformes, Windows, Linux et maintenant OS X.

J'ai pu faire des tests de performance entre OpenJDK 6 et la VM Apple et là aussi, les performances sont meilleures côté OpenJDK.



Ne reste qu'à attendre le pont AWT / Cocoa et on aura une VM parfaitement utilisable avec les outils de développements Java actuels, avec un gain de performance en prime.

- Suite à l’abandon de Java par Apple, vous [Emmanuel Puybaret] vouliez lancer JKoala, un portage d'OpenJDK sur Mac. Allez-vous le poursuivre ?

- Emmanuel Puybaret : Non, je l'ai déjà arrêté dans la foulée de l'annonce. Le développement d'une seconde version open source d'AWT / Swing sous Mac OS X ne présente pas d'intérêt maintenant qu'Apple a rejoint OpenJDK. Autant contribuer à améliorer leur version une fois qu'elle sera disponible.

Malgré tout, je ne regrette pas d'avoir lancé ce projet. C'est une initiative parmi d'autres qui a fait sûrement bouger les acteurs en jeu et ça a été l'occasion de mieux connaître les acteurs d'OpenJDK et de Java sous Mac OS X.

Revenons-en à OpenJDK pour Mac, comment les choses se présentent ? Apple a communiqué des informations sur ses mailings listes. Pouvez-vous nous en dire plus ?

- Emmanuel Puybaret : Le fait qu'Apple précise de façon publique ses intentions sur Java est déjà en soit un fait extraordinaire, et cela faisait très très longtemps que ça n'était pas arrivé ! Espérons qu'on puisse y voir une première preuve que l'équipe Java d'Apple commence à basculer dans le monde moins secret de l'open source...

Apparemment, la décision de rejoindre OpenJDK n'a pas été simple et Apple n'en est qu'au début de sa contribution. Ils vont d'abord compléter SoyLatte, la version d'Open JDK pour BSD qui fonctionne sous Mac OS X avec X11, pour qu'elle puisse s'adapter à l'architecture Java mise au point par Apple lors de la dernière mise à jour de Java. Puis dans les mois qui viennent, Apple va contribuer son implémentation de Java 6 et remplacer la couche graphique qui fait appel à X11 par une couche qui fera appel à Cocoa et OpenGL.

Apple contribuera aussi son Look and Feel Swing pour Mac OS X ainsi que son API eAWT/eIO spécifique. Par contre, l'implémentation actuelle des composants graphiques AWT ne pourra pas être contribuée, et un système de remplacement sera développé pour assurer la compatibilité avec les programmes existants.

- Henri Gomez : L'adaptation d'OpenJDK 6 sur OS X, d'après le projet OpenJDK BSD est un travail énorme qui a été accompli par des bénévoles, comme M. Landoff, Greg Lewis, Kurt Miller, Dalibor Topic.

Un coup de chapeau a eux, car ça reste l'oeuvre de passionnés et dans un cadre totalement Open source.

OpenJDK 7 a profité de ses patchs et fourni un support OS X quasiment complet.

Le point bloquant est le pont AWT vers Cocoa, pour l'instant il n'est qu’en mode X11, ce qui n'est pas satisfaisant.

Pour donner une idée, mon environnement de développement, Eclipse, tourne sous OpenJDK 1.7 64bits depuis quelque temps déjà et fonctionne sans aucun problème. Il n'y a pas de problème d'accès à l'interface utilisateur puisqu'Eclipse utilise SWT qui a un pont Cocoa depuis plusieurs années.

L'annonce de la création du projet de portage OpenJDK 1.7 sous OS X cette semaine et l'arrivée des ingénieurs Apple est particulièrement rassurante puisqu'on va pouvoir profiter des développements Apple dans OpenJDK 1.7.

Je compte d'ailleurs suivre ce projet, comme le projet BSD, avec mon camarade Gildas Cuisinier et l'inclure dans notre projet de construction continu de JVM OpenJDK, afin de pouvoir fournir régulièrement l'état de l'art à la communauté Java sous OS X.


Quels sont les avantages de travailler sur Mac pour un développeur Java ?

- Emmanuel Puybaret : On peut développer et tester la portabilité des programmes Java avec un seul ordinateur grâce aux logiciels de virtualisation comme Parallels Desktop, VMware ou VirtualBox, où vous pouvez installer Windows, Linux, Solaris...

- Henri Gomez : J'ai switché sur Mac l'année dernière parce que je voulais un environnement stable, avec une bonne ergonomie et surtout un noyau Unix.

Mac OS X apporte tout ça, avec en plus l'accès à la ligne de commande qui est quand même souvent utilisée par les développeurs Java, notamment avec certains outils de constructions d'applications comme Maven.

Apple n'a pas semblé être très active concernant Java ces derniers temps… Où en est-on par rapport aux autres JVM sur les autres plates-formes ?

- Emmanuel Puybaret : Si certaines fonctionnalités ont permis d'améliorer récemment l'intégration des programmes Java dans Mac OS X, la liste des bogues et fonctionnalités standards qui manquent à l'implémentation Java sous Mac OS X est en effet trop longue à mon goût : une boîte de dialogue d'ouverture de fichiers Swing qui rappelle celle de Mac OS... 9, une boîte de dialogue de choix de couleurs qui n'a jamais été adaptée au look de celle de Mac OS X, pas de fenêtre de forme non-rectangulaire ou translucide, une implémentation du Java Plug-in 2 qui n'est toujours pas celle par défaut et qui n'est pas compatible avec les versions actuelles de JOGL et Java 3D,... je préfère m'arrêter là pour ne pas lasser vos lecteurs.




Certaines de ces fonctionnalités ont reçu des correctifs extérieurs comme avec le projet Quaqua Look and Feel par exemple, mais pourquoi Apple n'a jamais développé ces correctifs elle-même ? Ca restera toujours un mystère, d'autant plus opaque que les listes des bugs et demandes d'amélioration d'Apple sont complètement privées.




- Henri Gomez : Je ne pense pas que Java ait jamais été une cible pour Apple. Il leur fallait une VM pour le fonctionnement d'applications serveur et ils ont donc fait l'effort. Pour l'utilisateur normal, le non-développeur, Java n'est quand même pas souvent utile sur son poste.

Pour un serveur par contre, c'est quasiment indispensable, puisqu’on y retrouve souvent des serveurs d'Application comme JBoss ou Glassfish.

Et sans Java, c'est un pan énorme de services qui ne peut être offert sur serveur.

D'ailleurs je trouve que l'annonce de l'arrêt de la maintenance Java et des XServe est peut-être révélatrice.


Jusqu'à présent, Mac OS X à la différence de Windows était un package très complet et intégrait par défaut Java et Flash. Apple a semble-t-il changé son fusil d'épaule. Comment jugez-vous cette nouvelle politique ?

- Emmanuel Puybaret : Cette intégration simplifie l'accès à de nombreux programmes pour les utilisateurs de Mac OS X, mais elle oblige les développeurs à s'adapter au rythme des mises à jour, ou plutôt des non-mises à jour, qu'Apple effectue dans Mac OS X pour ces technologies. Par exemple, Sweet Home 3D, un logiciel que j'ai développé en Java, reste encore compatible avec Java 5 pour pouvoir fonctionner sous Mac OS X Tiger, parce qu'Apple a décidé que Java 6 ne serait disponible qu'à partir de Mac OS X Leopard sous Intel.

- Henri Gomez : La aussi, ça reste dans une approche très Cupertinoesque, un recentrage sur ses propres technologies et son écosystème.

Personnellement je suis partisan de l'ouverture, et c'est d'ailleurs cette ouverture qu'il y avait dans OS X, son coté tout packagé qui a autant attiré les développeurs Java, qui ne voulaient plus perdre de temps sur leur configuration Windows.

Maintenant, on voit un système qui se replie sur lui même, qui s'inspire de plus en plus d'iOS, ce qui permet certes d'attirer le plus grand nombre, mais qui aussi semble décider tout seul de ce qui est bon ou pas pour sa plateforme. C'est vraiment dommage de mon point de vue.

- Le Mac App Store n'acceptera pas les applications écrites en Java. Qu'est-ce que cela vous inspire ?

- Emmanuel Puybaret : Je soupçonne que c’est cette décision qui a poussé Apple à abandonner Java précipitamment, puisque la sortie de la dernière mise à jour de Java avec la fameuse release note qui annonçait la fin de la version Java d'Apple est intervenue juste après le special event présentant Mac OS X Lion et le Mac App Store.

Il n'empêche que je ne comprends pas ce qui peut justifier d'exclure du Mac App Store une application écrite en Java ou en n'importe quel autre langage, à partir du moment où elle s'intègre correctement au système. Si c'est pour éviter une dépendance vis-à-vis de la version de Java installée, les développeurs n'auront qu'à fournir leur programme en l'accompagnant d'un runtime Java pour le rendre autonome. C'est ce que je fais déjà pour les versions Windows et Linux de Sweet Home 3D et ça fonctionne très bien. Le programme pèse 20 Mo de plus au téléchargement, mais ça n'est plus un problème avec la bande passante à laquelle les internautes ont désormais accès. Aussitôt que ce sera possible de faire la même chose avec OpenJDK pour Mac OS X, je relancerai l'équipe du Mac App Store sur ce sujet.

- Henri Gomez : C'est un choix pertinent dans l'esprit Apple qui n'accepte pas les applications produites en dehors de ses outils comme XCode.

Et puis, l'App Store reste quand même pour le grand public, je ne vois pas l'intérêt pour Apple d'y héberger une application comme Tomcat ou Eclipse :)
Mais personnellement je regrette ce choix, l'ouverture est toujours bénéfique.

Un mot enfin sur l'abandon du Xserve ?

- Emmanuel Puybaret : Je n'utilise pas de Xserve mais c'est un message plutôt sombre qui est envoyé au monde de l'entreprise... ou alors, si Apple nous présente finalement une solution alternative comme pour l'épisode Java, c'est encore une façon bien bizarre de communiquer ! À force de mettre la charrue avant les bœufs, Apple ne risque-t-elle de se prendre les pieds dans le tapis ?

- Henri Gomez : Je n'ai jamais travaillé avec du matériel Xserve, et je le regrette, car c'était une fois de plus la patte d'Apple, mais cette fois-ci dans un environnement serveur.
De bien belles machines, performantes et qui avaient leur public et leurs applications propres. Je suis sur que notre outillage de construction continue d'OpenJDK aurait tourné comme une horloge sur un XServe (sic) :-)
Tags
avatar Florent Morin | 
Apple a utilisé Java pour remplacer Objective-C sur WebObjects. Puis, rapidement, s'est tournée vers des technologies plus légères, comme par exemple Ruby. Grosse contribution dans des projets comme SproutCore (optimisé pour du RoR), MacRuby (compatible Cocoa, Grand Central Dispatch) et bien entendu Ruby On Rails, intégré à Mac OS X. En clair, Apple semble avoir laissé Oracle et la communauté s'occuper de Java pour se focaliser sur d'autres technologies. Si on fait le bilan des annonces au tour de l'avenir de Mac OS X, on a : - plus de Java intégré - une forte mise en avant du couple Objective-C / Cocoa (Touch) - un XCode 4 tout beau tout neuf intégrant Interface Builder (avec des interfaces compatibles Ruby entre autres) - un Mac AppStore qui supporte Objective-C / C / C++ et toute autre technologie pré-installée, ce qui n'exclut pas Python / Perl / Ruby (moyennant packaging) En clair, Java est accepté mais ça en reste là. Pas sur l'AppStore, pas pré-installé... comme Flash au final.
avatar Almux | 
...Et voilà... Alors, comme ça... Apple va acheter Oracle? Aah bon?! * Euh... Ça grattouille, ou ça chatouille? * = lol
avatar Ninety | 
Java c'est pour les kikoolol.
avatar Nyx0uf | 
Depuis quand Java c'est performant sérieux.
avatar totorino | 
Oui. Java EST performant. Ceux qui disent le contraire ne travaillent souvent pas avec...
avatar YenoIwesa | 
Hellooooo, on est plus à Java 1.1 là, La JVM intègre un compilateur Just In Time qui compile les hotspots en langage machine, inline le code quand c'est nécessaire, optimise a la volée etc. Aujourd'hui Java c'est aussi performant que du C, c'est tout.
avatar Superboy58 (non vérifié) | 
Java > All :) Les développeurs savent...
avatar good loser | 
[quote]yenoiwesa [08/12/2010 20:22] via MacG Mobile Hellooooo, on est plus à Java 1.1 là, La JVM intègre un compilateur Just In Time qui compile les hotspots en langage machine, inline le code quand c'est nécessaire, optimise a la volée etc. Aujourd'hui Java c'est aussi performant que du C, c'est tout.[/quote] Dans ce cas les développeurs java codent avec les pieds, il suffit de lancer une appli java conséquente pour se rendre compte à quel point java est lent, Eclipse en première ligne... Je suis en master informatique et je peux te dire qu'à chaque fois que le temps d'execution doit être optimisé on se tourne vers le C ou autre mais certainement pas java.
avatar Cal Apone | 
Toujours le même vieux débat et les mêmes vieux trolls quand on parle de java vs natif (C, C++,etc…). (un peu comme à propos de flash, d'ailleurs) Oui, une machine virtuelle est plus lente que du natif (forcément), mais permet une meilleure portabilité (forcément). Le tout est de peser le pour et le contre en fonction de ce qui est demandé.
avatar Le docteur | 
Une portabilité plus facile, mais pas meilleure. Merci de vous rappeler que,très souvent, les applications Java sont de véritables plaies pour l'utilisateur final.
avatar ispeed | 
Discours complaisant et langue de bois bref on y apprend pas grand chose à part le monde de oui oui :)
avatar ovea | 
@flomo Merci pour ce brushing.
avatar ovea | 
Par contre, je tente de ne pas comprendre le faut débat sur l'écriture d'un programme. Car coder direct dans un langage c'est bien … mais comment ignorer que l'on ai des outils d'abstraction qui nous permettent de schématiser l'application autant dans l'un et dans l'autre des langages. On se dit — Ouai, va falloir tout réécrire ! Mais l'occasion d'une réécriture doit être une chance et non un inconvénient. On le voir bien avec iOS qui suscite chez RIM la construction d'un OS virtualisé (temps réel ?! ) et l'annonce du côté de VMWare pour portable Androide. On essai la plupart du temps de maintenir un code pourri car il ne supporte pas les évolutions. Il faut sortir de l'attitude où on espère faire de la maintenance de son code sans en avoir appris quoi que ce soit sur l'environnement d'exécution !!!
avatar Le docteur | 
@ Totorino Je travaille souvent avec une application Java et c'est tout simplement pitoyable. Maintenant le code est peut-être sérieux, à la base. Mais le résultat...
avatar biniou | 
Le compilateur JIT (Just In Time) améliore grandement la done concernant les performances de Java. Java est le langage le plus utilisé par les développeurs et particulièrement dans le monde de l'entreprise. On pense Java, et on dit ah mais Java c'est lent. Pourtant je suis sûr que vous employez au moins une application qui est programmée en Java et qui tourne parfaitement mais dont vous ne savez juste pas en quoi c'est implémenté. La recherche académique s'est penchée sur la différence de vitesse d'exécution de code Java et C/C++. Leur conclusion est sans appel, il n'y a pas de différence SIGNIFICATIVE (statistique quand tu nous tiens) entre la vitesse d'exécution d'un même programme écrit en Java avec un programme écrit en C/C++ pour la plupart des tâches...
avatar biniou | 
Alors Ruby "une technologie légère", ça, ça m'a fort fait rire. Vous ne voulez pas aussi dire que Python est plus rapide que la lumière ? Ce qu'il ne faut pas entendre !
avatar biniou | 
@ovea : QNX un OS virtualisé ? Celle-là aussi m'a fait rire ... "Construction" d'un OS qui existe déjà depuis longtemps et qui se trouve peut-être dans ta voiture ... Il existe des outils de modélisations et non de schématisation pour palier à l'ensemble des étapes d'un cycle de vie de génie logiciel. Ces outils sont indépendants d'un langage de programmation. De plus avec des outils comme JNI tu n'es pas obligé de tout réécrire et justement les outils de modélisations sont mis en place pour assurer la meilleure réutilisabilité possible du code. De plus on ne maintient pas du code mais un produit ... On implémente de plus en plus en utilisant des outils multiplates-formes qui ne se concentrent pas sur le système d'exploitation et ses API propriétaires (et/ou propres), mais sur le logiciel lui-même. Et cela va des jeux vidéos au programme de VoIP grand public. Tu as l'air soit de ne rien y connaître, soit d'être complètement confus dans tes propos.
avatar pol2095 | 
Pas de surcouche logiciel, à part peut-être le html5, on peut programmer en C et ne pas être forcément en natif aussi.
avatar vintz72 | 
@Ninety > Java c'est pour les kikoolol. Non, rien à voir. Java s'est pour les pros. Mais bon, il faut savoir de quoi on parle. Java est énormément utilisé en entreprise (ça fait partie de mon métier), et Mac Os X n'y est absolument pas présent. La décision d'arrêter les Xserve ne va certainement pas aider Apple à pénétrer les entreprises (françaises j'entends). Quant à Java, il était impossible pour Apple de s'en passer complètement. Certains softs très bons comme Sweet Home 3D sont fait en Java, et là, ça ne concerne pas que les pros. Et en effet, Java est bien plus performant que les langages à la mode comme Python ou Ruby. D'ailleurs, s'il existe des Jython et JRuby, c'est en grand partie pour ça. Par contre, ça reste bien moins performant que du C/C++/OBJ C qui sont des langages compilés.
avatar jewan | 
quelques précisisons : - Java est un langage compilé ( produit du p-code pour une machine vitruelle) - Java est un langage considéré maintenant comme rapide et meme dans certains cas etre plus rapide que du C/C++ (optimisation pendant l'execution JIT) - les programmes lents en java sont souvent des logiciels graphiques (en swing) -> cela vient de la technologie multiplateforme et des developeurs :) - java est enormement utilisé dans les entreprises et la recherche
avatar oomu | 
ce sont des débats sans intérêt. La réalité est que JAVA est maintenant une technologie pour _SERVEUR_ d'ENTREPRISE (ils citent explicitement JBOSS et Glassfish, jamais vous mettrez ça sur vos postes bureautiques) - ce n'est pas la performance pure de la JVM qui vous intéresse La jvm a toujours un coût en exécution et charge mémoire, _toujours_. Par rapport à objective C , ça sera moindre que face à C, parce que objective-C a un moteur sophistiqué intégré à chaque application. Mais il y a un coût. Non, ce qui vous intéresse et motive, c'est l'intégration de Java à la plateforme native (os X) et JAVA ne peut pas être "natif", par _design_ ils vous parlent de AWT ou SWT qui sont les interfaces graphiques de Java , PAR DESSUS cocoa (ou feu-carbon). Java isole du système, par conséquent il est obligatoirement plus "couteux" pour la machine (+ d'interfaçage = + de coût => - de performance) On peut se rouler par terre, trouver toutes les études statistiques du monde, tout utilisateur le voit. - maintenant, passons au monde de l'entreprise. Java est incontournable : - ses bibliothèques regorgent de fonctionnalités robustes et éprouvés pour tous les besoins de logiciels d'entreprises - abondamment documenté et développé - un nombre effroyable de logiciels et services autour de java. Les "serveurs applicatifs" tels jonas ou tomcat ou websphere ne sont pas des petits gadgets. Ils font vivre les logiciels java sur les serveur. - Java a tout ce qu'il faut pour s'adapter à la montée en charge par les utilisateurs d'un service, permet de tirer parti d'ordinateurs toujours plus riches en processeurs et mémoires. La portabilité de Java est utile dans le monde de l'entreprise, cela permet de faire passer des investissements _très lourds_ de Mac à Linux à Solaris à autre sans trop de casse. - pour l'utilisateur sur son poste de bureautique, cela n'a aucun intérêt. aucun du tout zéro total. Je suis pas QUE subversif, mais réaliste : + de 15 ans de javaserie déjà.
avatar oomu | 
"- Java est un langage compilé ( produit du p-code pour une machine vitruelle)" d'où le terme pseudo-compilé. Il est compilé dans un code intermédiaire (très standardisé) pour une fausse machine qui elle va tout faire pour l'exécuter sur le vrai processeur. " Java est un langage considéré maintenant comme rapide et meme dans certains cas etre plus rapide que du C/C++ (optimisation pendant l'execution JIT)" Autant profiter de toutes les optimisations des travaux sur les compilateurs pour le C. - ce n'est de toute façon pas le point. Vous le dites vous même en fait : "- les programmes lents en java sont souvent des logiciels graphiques (en swing) -> cela vient de la technologie multiplateforme et des developeurs :)" cela vient du principe même. pas des développeurs. Il vous faudra combien d'années de Swinguerie, de X11erie, de AWTzerie et autres FXzeries pour réaliser que plus vous ajoutez de couches très compartimentées, plus vous rajoutez du coût. Tout système est un empilage de couche oui, mais Java par son principe universel et portable ne peut pas être fondu et profité d'éventuelles améliorations de Quartz ou du noyau, il passe par COCOA sans être cocoa (c'est une api développeur totalement différente). Le fait d'être universel malgré windows, linux, os x est couteux et ne permet jamais de tirer partie des éventuels mécanismes spécifiques à chaque plateforme. Cela est critique en logiciels graphiques justement. La grande sophistication des api pour interface graphique rend difficile d'améliorer la situation sans créer 3 java incompatibles (ce qui est sans intérêt). - Le fait est Java est une excellente idée pour les logiciels d'infrastructures (ce qui gère banques, commerces, etc). pas pour Halo, Word ou dessiner la zolie page web Facebook.
avatar oomu | 
@Ninety > Java c'est pour les kikoolol. faux. Java est exactement pour la catégorie inverse de gens.
avatar fr1man | 
@ oomu Tu es extrémiste ! Il existe de bonnes applications Java. C'est dommage de rejeter les applications Java uniquement sur des concepts. Si une application me plait, je n'en ai rien à cirer qu'elle soit codée en Java ou dans n'importe quel autre langage. Et si en plus, je peux m'en servir sur des OS différents, c'est encore mieux.
avatar jewan | 
@oomu je suis d'accord avec toi à 98%, ce n'est pas le lieu pour pinailler sur les 2% ;)
avatar Hindifarai | 
@ oomu Votre discours m'étonne, vous m'avez habitué à des propos plus argumentés et je vous trouve un manque cruel de recul sur Java. Imputer un manque de performance à Java est tout de même rétrograde aujourd'hui. Une JVM française tourne sur un avr8 et est très stable. Certes vous n'aurez pas grand chose en dehors de la CLDC mais tout de même! Je connais peu de gens capables de produire un code C tournant sur cette plateforme. Preuve en est que Java peut s'adapter et produire des performances appréciables. Bref c'est le JVM qui est à pointer du doigt et non le langage. Les performances de cette dernière est en amélioration constante (on partait de loin je vous l'accorde). Seuls quelques frameworks graphiques sont asthmatiques de par leur difficultés à se reposer sur certains window managers (et là il faut pointer du doigt Apple qui n'a pas faciliter ce travail). Concernant votre paragraphe sur Swing et autres je ne comprends pas d'ailleurs votre discours. Toute JVM proposant Swing ou AWT implémente une interface commune en ciblant une architecture et un OS. Si cette implémentation est laborieuse ce n'est pas la faute de la JVM mais du support window manager qui leur met des batons dans les roues. Certes il y a quelques incohérences dans AWT par exemple mais c'est loin d'être le plus utilisé et c'est loin de pouvoir provoquer des cauchemars aux membres du GoF comme peut le faire LWUIT.
avatar eTeks | 
oomu, ça n'est pas parce que tu as apparemment décidé d'arrêter de programmer des applis en AWT, Swing ou SWT que ça t'autorise à descendre ceux qui continue à le faire. A t'écouter, [url=http://www.sweethome3d.com]Sweet Home 3D[/url] n'aurait jamais du exister. Mais comprends bien, que je n'aurai jamais eu le temps de redévelopper un logiciel comme celui-là sous Mac OS X ou Linux si un outil comme Swing n'existait pas. C'est aussi simple que ça ! Que ce ne soit pas l'architecture que veut nous vendre Steve Jobs, soit, mais les utilisateurs, eux, s'en fichent et les chiffres le prouvent (+100 000 téléchargements par semaine).
avatar bortek | 
Excellent article !
avatar biniou | 
Pour faire une application graphique multi-plateforme autant utiliser Qt et du bon vieux C++. Pour une application native réservé à une plate-forme, autant utiliser les API et le langage "phare" de la plate-forme. Je suis d'accord avec Oomu sur le fait que Java est surtout orienté serveur aujourd'hui et le sera de plus en plus. Mais Java est aussi orienté mobile et embarqué. Des SoC faisant tourné un JVM, il y en a pas mal aujourd'hui. De plus, deux des plus importants OS pour smartphone utilise massivement Java. Java s'est fait une niche dans le monde embarqué comme dans le monde des services Web.
avatar biniou | 
Aussi non, un petit détail, le code java est compilé en bytecode ;-) Et c'est ce bytecode qui est transformé en code natif par la JVM. "Les p-Codes diffèrent des bytecodes par le codage de leurs opérations, qui peut être de plusieurs octets avec une taille variable, tout comme les opcodes de nombreux processeurs. Ils ont un plus haut niveau descriptif, comme « afficher cette chaine de caractères » ou encore « effacer l'écran ». Le BASIC et quelques versions de Pascal utilisent un p-Code." [Wikipedia] Voici quelques liens pour vous : - http://books.google.be/books?id=QpL3gu-c_aoC&pg=PA89&lpg=PA89&dq=jvm+bytecode+pcode&source=bl&ots=d6caAMzErI&sig=2HEgWck8lE2jBbqGLVtOuMLUoak&hl=fr&ei=Q-oATY6nB4_rOfqR9KYB&sa=X&oi=book_result&ct=result&resnum=4&ved=0CDgQ6AEwAw#v=onepage&q&f=false - http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/
avatar rom54 | 
- Apple cede a Oracle la responsabilité du portage de Java sur OS X - Apple investit OpenJDK - Apple arrete la ligne XServe - Apple reussi une installation significative en entreprise au niveau terminal et end-user Bref Apple fait ce qu'il faut pour laisser la place libre a Oracle en entreprise pour ce qui est des infrastructures et particulierement des serveurs. Apple fait ce qu'il faut pour se développer au niveau end-user partout, que se soit en entreprise ou ailleurs. Cette strategie semble claire. OSX et iOS sont des postes clients, sur lesquels Apple investit massivement. Java est un langage massivement utilisé pour la sphere serveur. Apple a juste besoin que iOS et Mac OS soient des clients performants, donc pas besoin de Java autre qu'en compatibilité. Par contre Apple se focalise sur Objective-C et Ruby, afin de permettre un développement de logiciels réellement user-friendly (intuitif, productif, ...) Finalement, c'est une bonne chose (hormis qu'Oracle seul conduit l'evolution de Java), Apple a fait clairement comprendre que les applications pour OS X/iOS se font uniquement en Objective-C et Cocoa, mais que les Mac restent de bonnes machines sur lesquelles ont peut continuer a faire du développement pour Java, donc pour des programmes qui tourneront sur des serveurs (Oracles) . On va juste espérer qu'Apple va nous sortir un générateur d'interfaces performant et simple, qui permette de rendre plus rapide,léger et efficace le portage des applications Java. Y a quelques applications clefs qui ont vraiment besoin d'etre presentes sur OS X, surtout dans le domaine de la recherche du genre SPSS ou encore Freeplane et evidement OpenOffice...
avatar tomate | 
Je suis d'accord sur le fait qu'il n'est pas aisé (possible) de faire usage de toutes les supers technos disponibles sur une plateforme donnée depuis Java (CoreAnimation, OpenCL, etc). Même si le pont entre Java et l'OS pourrait (devrait), lui, en tirer le meilleur parti possible. Maintenant il est tout à fait possible de réaliser des applis de qualités tant en fonction qu'en look en Java. Suffit de voir SweetHome3D ou Netbeans. D'ailleurs en parlant de ce dernier, comment ferait-on pour programmer en Java sans IDE que qualité écrit lui même en Java? XCode? Non merci. VisualStudio? Je vais vomir. Regardez par exemple http://platform.netbeans.org/screenshots.html De nombreuses personnes réalisent des applis desktop de qualité en Java. Après le look, c'est une question de goût et d'effort graphique. On peut faire des mochetés en Cocoa, eh oui et des applis Java très réussies. Et puis on n'a pas toujours besoin des dernières techno bling bling pour tous les types de softs. Pour finir, Java est language de programmation très efficace et abordable. Et ça, ça compte en entreprise également. C++ c'est bien, mais mon dieu quel effort pour le porter sur différentes plateformes...
avatar eTeks | 
@ biniou Je m'attendais à la réponse Qt... Et bien, si c'est pour aboutir à une IHM toute beurk comme celle Adobe Photoshop Elements, bof, bof !!! Sincèrement, je fais mieux en Swing. Si vous voulez je vous donne une longue liste des problèmes d'intégration à Mac OS X de Photoshop Elements. Et n'allez pas dire que ça n'est pas une application grand public, hein !
avatar biniou | 
@eTeks : Qt utilise les librairies graphiques de Mac OS X et son look and feel ;-) Après à chacun de choisir comment on programme avec ses pieds ;-) Voici les logiciels qui sont développés avec Qt : - http://qt.nokia.com/qt-in-use/target/desktop - Sans compter Maya et http://qt.nokia.com/qt-in-use/usage/advanced-gui-development
avatar eTeks | 
Donc on est d'accord, si tu programmes correctement en faisant l'effort d'intégrer ton programme aux OS auxquels tu le destines, tout est possible que ce soit en Objective-C/Cocoa, Java/Swing, C++/Qt, liste à laquelle on pourrait sûrement ajouter plein d'outils de programmation. ;-) Malgré tout, je t'accorde que Swing sous Mac OS X n'est pas encore parfait, mais son passage sous OpenJDK ne pourra qu'arranger les choses !
avatar Hindifarai | 
Java est dominant dans le monde serveur depuis longtemps maintenant et profite de sa position de force pour résister face à Ruby qui a pourtant de serieux atouts. Le monde de l'embarqué lourd (téléphones, tablettes) devient le terrain de jeu de prédilection de Java malgré des spécifications hasardeuses dans ses frameworks graphiques(au sens designs APIs). Pour l'embarqué léger (micro processeurs arm inferieure à 9 ou avr) alors le C est dominateur voir quelques essais courageux en C++, le Java monte grâce à la boîte française créant des JVM embarquées optimisées. Pour ce qui est du reste des plateformes, des ordinateurs "classiques" et des applications qui les concernent le constat est difficile à faire. Sous mac osx rares sont les applis Java bien intégrées, la faute à un mauvais binding ou parfois son absence. La charge de dev s'en trouve largement augmentée sur cette plateforme pour Java. Le constat est tout autre sur les autres plateformes. La charge inhérente à la maintenance du code en multiplateforme est bien inférieure avec la technologie Java (C++ Qt demande plus de dev sur ce point de vue). C'est triste mais le calcul de toutes ces charges(et d'autres) est un point important lorsque l'on développe un logiciel si l'on veut toucher plusieurs plateformes. Alors oui on peut faire des applis moches en Java, tout comme en objectiveC, tout comme en C++. Pour le mythe du Java lent et ogre en ressources, le jour où les personnes se revendiquant à tort comme dev java sauront laisser de côté les StringBuffer et Vector au profit de StringBuilder ou List, lorsqu'ils apprendront à faire des for décrémentaux à double instructions ou simplement liront les specs de la VM alors plus personne ne se pourra se plaindre de lenteurs, car oui développer est un métier qui s'apprend.
avatar ovea | 
Apprendre ! C'est vrai qu'pn apprend beaucoup avec java… Surtout dans les technos clients/serveur. Mais Y'a encore des p'tits recoins pas claires comme la persistance des objets en Java, la récursivité des clauses WITH … AS … chez Oracle, à chaque étape où Apple n'est pas présent et où le rapprochement oracle/java pourrait faire du bien. Reste le boulet IE… (ne parlons même plus du client lourd ) Il n'y en a plus avec Apple :p ?! Là où le graphiste va ‘scénariser’ l'interface avec tous les principes ergonomiques affairants. Le gestionnaire découvre que la bureautique n'existe plus depuis trente ans. Et pourtant…
avatar biniou | 
@ovea : avec tout le respect que je vous dois, je voulais vous prévenir que ça ne veut rien dire votre commentaire. Vous êtes extrêmement confus par rapport à toutes ces technologies. Java est un langage complètement orienté objet (OO). La plupart des articles scientifiques sur l'éducation en sciences informatiques (Standford, MIT, ...) présente Java comme un des meilleurs langages pour apprendre l'OO car il n'est pas un langage hybride comme C++ et donc force l'étudiant à entrevoir des concepts de l'OO. Si c'est pour apprendre des bases en réseau, tous les langages ont leurs points forts et leurs points faibles. Aussi non pour les interfaces hommes-machines, on ne parle rarement/jamais de "scénariser". On parle de métaphores, d'abstraction de la réalité, de modélisation conceptuelle, d'UML (Merise pour les Français ;-) - je n'ai pas pu m'en empêcher), ... Aussi non la bureautique existe et représente un travail conséquent aussi bien pour les employés de bureaux (secrétaire, ...) que pour les cadres. En entreprise, la plupart si pas l'ensemble du travail est documenté, sans compter toute la paperasse administrative de nos états modernes. On me disait souvent pendant mes études qu'on programme 1/10 de notre temps et les 9/10 de temps, qui restent, sont utilisés pour documenter l'implémentation.

CONNEXION UTILISATEUR