Fermer le menu
 

Interview : quel avenir pour Java sur Mac ?

Christophe Laporte | | 17:31 |  38
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.

Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


38 Commentaires

avatar FloMo 08/12/2010 - 18:56

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 08/12/2010 - 19:38

...Et voilà... Alors, comme ça... Apple va acheter Oracle? Aah bon?! * Euh... Ça grattouille, ou ça chatouille? * = lol

avatar Ninety 08/12/2010 - 19:41

Java c'est pour les kikoolol.


avatar Nyx0uf 08/12/2010 - 20:01

Depuis quand Java c'est performant sérieux.

avatar totorino 08/12/2010 - 20:15

Oui. Java EST performant. Ceux qui disent le contraire ne travaillent souvent pas avec...

avatar YenoIwesa 08/12/2010 - 20:22

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 08/12/2010 - 21:04

Java > All :) Les développeurs savent...

avatar good loser 08/12/2010 - 23:07

[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 08/12/2010 - 23:43

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 08/12/2010 - 23:51

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 09/12/2010 - 00:03

Discours complaisant et langue de bois bref on y apprend pas grand chose à part le monde de oui oui :)

avatar ovea 09/12/2010 - 00:21

@flomo Merci pour ce brushing.

avatar ovea 09/12/2010 - 00:43

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 09/12/2010 - 06:17

@ 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 09/12/2010 - 06:33

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 09/12/2010 - 06:54

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 09/12/2010 - 07:04

@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 09/12/2010 - 09:34

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 09/12/2010 - 09:39

@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 09/12/2010 - 10:17

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 09/12/2010 - 11:01

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 09/12/2010 - 11:11

"- 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 09/12/2010 - 11:12

@Ninety > Java c'est pour les kikoolol. faux. Java est exactement pour la catégorie inverse de gens.

avatar fr1man 09/12/2010 - 11:33

@ 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 09/12/2010 - 11:43

@oomu je suis d'accord avec toi à 98%, ce n'est pas le lieu pour pinailler sur les 2% ;)

Pages