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égorie : 
Tags : 

38 Commentaires

avatar biniou 11/12/2010 - 13:27

@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.

avatar ovea 11/12/2010 - 03:09

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 Hindifarai 09/12/2010 - 23:53

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 eTeks 09/12/2010 - 19:05

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 biniou 09/12/2010 - 18:28

@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 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% ;)

avatar Hindifarai 09/12/2010 - 12:10

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

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

Excellent article !

avatar biniou 09/12/2010 - 15:36

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

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/

Pages

Connexion utilisateur