Apple abandonne Java pour le développement Cocoa.

maousse

Membre expert
Club iGen
20 Avril 2002
7 226
445
43
Paris
orbl.eu
Ça parait assez étrange. Quelle pourrait être la raison (ou les raisons) de cette mise entre parentèses de java :
- coût de développement : ça doit évidemment jouer mais j'ai du mal à croire que le développement de quelques API java représente un coût réellement important, me trompè-je ?
- peu de développeurs en java ?
- optimisation de processeurs/circuits pour objective C : ça, ça relève de madame Irma et au moment où apple tend à s'appuyer sur des standards, c'est curieux

À votre avis, c'est juste une question de petites économies ?
 
Je comprends l'attitude d'Apple. Il y a déjà tellement d'API à maintenir.

Java, c'est surtout bien avec SWING pour du multiplateforme. Pour du Cocoa, c'est plutôt plus lent, et pas multiplateforme.

Autant garder Cocoa avec ObjectiveC et SWING avec Java.

Pour info, Carbon est aussi en train de disparaitre petit à petit...
Je trouve ça plus simple d'avoir une seule bonne API. En plus pour le coté FAT binaries, c'est quand même plus simple pour Apple d'avoir à ne faire évoluer qu'une seule API.
 
SuperCed a dit:
Je comprends l'attitude d'Apple. Il y a déjà tellement d'API à maintenir.

Java, c'est surtout bien avec SWING pour du multiplateforme. Pour du Cocoa, c'est plutôt plus lent, et pas multiplateforme.

Autant garder Cocoa avec ObjectiveC et SWING avec Java.

Pour info, Carbon est aussi en train de disparaitre petit à petit...
Je trouve ça plus simple d'avoir une seule bonne API. En plus pour le coté FAT binaries, c'est quand même plus simple pour Apple d'avoir à ne faire évoluer qu'une seule API.


Tu sais Sueperced, quand tu as vu comment les apis OpenStep (Cocoa aujourd'hui), laissaient sur le tapis les apis Win32 sur plateforme Intel, tu comprends alors pourquoi. En effet, NeXT avait fait une optimisation d'objective-C sur Intel qui est assez phénoménale. Même la version PPC ne lui arrive pas à la cheville.
Je m'en appercois lorsque je m'amuse de tmps en temps avec ma machine sous NeXTStep.

Je crois pas que Carbon disparaisse. Par contre Carbon est entrain d'être cocoa-iser c'est sûr.
D'ailleur les technologies CoreFoundation sont une direction dans ce sens. Entre nous, Cocoa est tllement élégant et simple!!! On arrive en très peu de temps à faire des choses extraordinaires.
Pas pour rien que les applis phares d'Apple (sauf peut être shake), sont développées en cocoa. Les apis Cocoa sont celles qui évoluent très vite. Une bonne partie des APIS quicktime sous Tiger est en cocoa. et j'ai réussis à faire des trucs avec core image et quicktime assez amusants avec en codant un minimum. Tellement les apis cocoa sont puissantes.
J'ai toujours dit à quiconque veut développer sous Mac d'apprendre Cocoa il ne sera vraiment pas déçu.
Cocoa est l'environnement de developpement objet le meilleur actuellement. Il y a pas photo.
 
Il y a un peu tout et n'importe quoi dans ce post, faudrait pas tout confondre.

Manu a dit:
Tu sais Sueperced, quand tu as vu comment les apis OpenStep (Cocoa aujourd'hui), laissaient sur le tapis les apis Win32 sur plateforme Intel, tu comprends alors pourquoi. En effet, NeXT avait fait une optimisation d'objective-C sur Intel qui est assez phénoménale. Même la version PPC ne lui arrive pas à la cheville.
Je m'en appercois lorsque je m'amuse de tmps en temps avec ma machine sous NeXTStep.

Déjà, je suis assez sceptique là dessus. La seule chose optimisable qui soit spécifique à l'Obj-C, c'est l'appel de fonctions par passage de méthodes. Hors, depuis longtemps, toute cette partie de l'Obj-C est faite en assembleur, que ce soit sur x86 ou PPC. Si vraiment il y a une différence de performance à ce niveau-là (ce qui reste à prouver), c'est donc uniquement du au hard.

Manu a dit:
Je crois pas que Carbon disparaisse. Par contre Carbon est entrain d'être cocoa-iser c'est sûr.
D'ailleur les technologies CoreFoundation sont une direction dans ce sens. Entre nous, Cocoa est tllement élégant et simple!!! On arrive en très peu de temps à faire des choses extraordinaires.
Pas pour rien que les applis phares d'Apple (sauf peut être shake), sont développées en cocoa. Les apis Cocoa sont celles qui évoluent très vite. Une bonne partie des APIS quicktime sous Tiger est en cocoa. et j'ai réussis à faire des trucs avec core image et quicktime assez amusants avec en codant un minimum. Tellement les apis cocoa sont puissantes.

Là encore, c'est un peu rapide comme description :
- toutes les applis phares d'Apple ne sont pas du tout faites en Cocoa. Leurs interfaces graphiques, éventuellement, mais on ne peut certainement pas généraliser. Beaucoup d'applications pro utilisent des moteurs internes codés avec d'autres choses que du Cocoa-ObjC pur. Par exemple, DVD Studio Pro, Shake, Motion utilisent beaucoup de C++. Donc dire que tout est fait en Cocoa, c'est complètement faux. Cocoa est très bien pour beaucoup de choses (et notamment les interfaces graphiques), mais ce n'est pas la panacée.

- De la même manière, QuickTime est toujours codé en C pur. Les API ObjC qui sont apparus dans Tiger ne font que répondre à un souhait légitime des développeurs de pouvoir accéder aux fonctionnalités de QuickTime directement depuis l'ObjC. Donc encore une fois, c'est vrai qu'Apple met beaucoup en avant l'utilisation de l'ObjC et que les nouveautés seront désormais très centrées sur l'ObjC, mais ce n'est pas une raison pour gober le discours marketing d'Apple et dire que c'est adapté pour tout et n'importe quoi.
 
Didier Guillion a dit:
Diable ! Mais où as tu vu cela ?

Cordialement
En me relisant, j'ai vu que ce que j'avais écrit était idiot.

En fait, je voulais parler des anciennes API compatible avec les version antérieures à MacOS X. J'ai juste l'impression qu'Apple met en avant Cocoa et un peu moins les API en C.

Pour tout ce qui est CF, bien sur, ça va continuer aussi.

En fait, je ne sais plus trop quoi mettre sous le terme Carbon... Est-ce toutes les API C ou est-ce seulement l'API qui reste compatible avec MacOS 9?...
Est-ce que les KPI font partie de Carbon?

Tout ce que je sais, c'est qu'Apple met en avant les API ObjectiveC, qu'elles fonctionnent plutôt bien d'après ce que j'avais pu tester, qu'elles sont faciles à apprendre, relativement documentées, et rapides à utiliser pour le développement.
 
Bobbus a dit:
I



Là encore, c'est un peu rapide comme description :
- toutes les applis phares d'Apple ne sont pas du tout faites en Cocoa. Leurs interfaces graphiques, éventuellement, mais on ne peut certainement pas généraliser. Beaucoup d'applications pro utilisent des moteurs internes codés avec d'autres choses que du Cocoa-ObjC pur. Par exemple, DVD Studio Pro, Shake, Motion utilisent beaucoup de C++. Donc dire que tout est fait en Cocoa, c'est complètement faux. Cocoa est très bien pour beaucoup de choses (et notamment les interfaces graphiques), mais ce n'est pas la panacée.

- De la même manière, QuickTime est toujours codé en C pur. Les API ObjC qui sont apparus dans Tiger ne font que répondre à un souhait légitime des développeurs de pouvoir accéder aux fonctionnalités de QuickTime directement depuis l'ObjC. Donc encore une fois, c'est vrai qu'Apple met beaucoup en avant l'utilisation de l'ObjC et que les nouveautés seront désormais très centrées sur l'ObjC, mais ce n'est pas une raison pour gober le discours marketing d'Apple et dire que c'est adapté pour tout et n'importe quoi.

Je ne vois pas en quoi ce que j'ai dit est faux. les softs dont tu parles sont ceux qui ont été rachetés mais ne sont pas des développements Apple à l'origine. Ce que j'ai dit c'est tout simplement qu'Apple encourage le port des applis en cocoa qui ne l'oublions pas est présenté aux développeurs comme l'environnement de prédilection pour développer les applis pour OS X. A tel point qu'ils présentent en exemple ici chronos qui a fait la migration de leur appli de carbon à cocoa.

Le fait que les applis cocoa tournent mieux sur Intel est un fait connu. C'est surement du à une meilleure optimisation de gcc par Intel. Ce que n'a pas visiblement réussi ou voulu IBM.
Je ne vois pas où tu vois du marketing là dedans. surtout quand il s'agit de développement.
 
Je développe en cocoa depuis belle lurette. En fait depuis OpenStep à l'époque de NeXT. La force des apis cocoa c'est non seulement leur aspect objet. Mais surtout que le système OS X qui est basé sur Mach a lui aussi une structure objet. C'est ainsi que chaque élément de l'OS, thread, objet mémoire, port , etc a son pendant cocoa NSTread, NSPort, etc. C'est cette symbiose qui a longtemps susciter l'admiration de la part des connaisseurs.
En tout cas j'ai mieux apréhender l'approche objet en faisant du cocoa que par java. Java qui ne l'oublions pas a été inspiré par cocoa. D'ailleurs les inventeurs de Java sont ceux là même qui avaient participé à l'époque au portage d'openstep sur Solaris de Sun.
Bref chez NeXT on développait en objet en 1988 aors que même C++ n'était qu'à ses balbutiements.
C'est assez étonnant de voir qu'un concept comme le MVC utilisé depuis belle lurette sur NeXTSTEP, être promu dans des environnements de dev comme Eclipse aujourd'hui.

Tout cela pour dire que pour un débutant en développement sur Mac OS X, je conseille d'apprendre le C puis passer à cocoa. En effet objective-C c'est du C avec une syntaxe à la smalltalk.
 
Je viens de retrouver cette discussion par hasard... Finalement, j'avais raison... 12 ans avant ! Carbon a été abandonné en 2012.
 
Je viens de retrouver cette discussion par hasard... Finalement, j'avais raison... 12 ans avant ! Carbon a été abandonné en 2012.
Cela a quand même mis le temps. :rolleyes:

L'API Carbon est toujours présente dans macOS. Cocoa-Java était out dès Leopard (2007).

L'évolution de Carbon dans les années qui ont suivit donne plutôt raison à Manu. Elle a accompagné les changements de Cocoa jusqu'à l'avènement de Mountain Lion.

Carbon va sans doute réellement disparaître de macOS avec l'abandon du 32 bits dans deux ans.

Cocoa a aussi pas mal évolué depuis 2005. :cool:

Tout cela ne nous rajeuni pas. :D
 
Oui oui, j'étais sarcastique dans ma première réponse. Ça n'est pas disparu si vite au final...