Interview : quel avenir pour Java sur Mac ?
par Christophe Laporte le Mercredi 08 Décembre 2010 à 17:31
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.
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.
| |
3
2
1
Vos réactions (38 réactions)
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.
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.
Almux
[08/12/2010 19:38]
...Et voilà... Alors, comme ça... Apple va acheter Oracle? Aah bon?! *
Euh... Ça grattouille, ou ça chatouille?
* = lol
...Et voilà... Alors, comme ça... Apple va acheter Oracle? Aah bon?! *
Euh... Ça grattouille, ou ça chatouille?
* = lol
Ninety
[08/12/2010 19:41]
Java c'est pour les kikoolol.
Java c'est pour les kikoolol.
Nyx0uf
[08/12/2010 20:01]
Depuis quand Java c'est performant sérieux.
Depuis quand Java c'est performant sérieux.
totorino
[08/12/2010 20:15]
Oui. Java EST performant. Ceux qui disent le contraire ne travaillent souvent pas avec...
Oui. Java EST performant. Ceux qui disent le contraire ne travaillent souvent pas avec...
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.
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.
Superboy58
[08/12/2010 21:04]
Java > All :) Les développeurs savent...
Java > All :) Les développeurs savent...
good loser
[08/12/2010 23:07]
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.
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.
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.
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.
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é.
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é.
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.
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.
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 :)
Discours complaisant et langue de bois bref on y apprend pas grand chose à part le monde de oui oui :)
ovea
[09/12/2010 00:43]
via MacG Mobile
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 !!!
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 !!!
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...
@ 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...
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...
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...
3
2
1
Réagir
Il n'est pas possible de réagir à cette dépêche. Si vous souhaitez toutefois réagir, n'hésitez pas à faire un tour dans nos forums.






Mai 2013
