Si le code Java peut fonctionner sur n’importe quelle plateforme, pourquoi les développeurs iOS utilisent-ils Objective C et non Java pour fonctionner sur l’iPhone ?


La réponse est compliquée. Il n'y a aucune raison technique pour laquelle on ne pourrait pas porter une VM Java sur iOS. Mais il faut tenir compte du fait que la machine virtuelle nécessite l'accès aux appels système au niveau du système d'exploitation, en faisant correspondre l'implémentation des classes de base du JDK aux fonctionnalités natives du système d'exploitation. Obtenir des performances est un autre défi, car la plupart des JVM utilisent un JIT pour se rapprocher des performances du niveau natif. Ces compilateurs JIT sont complexes et leur portage nécessite l'intervention d'un spécialiste, ce qui n'est pas un projet de fin de semaine, sauf si c'est votre métier. Et la plupart des personnes qui utilisent Java se soucient des performances, surtout dans le contexte d'un appareil aux ressources limitées. Le nombre de personnes dans le monde qui se spécialisent dans ce domaine est assez faible par rapport au développeur d'applications typique, ce qui nécessite des connaissances en C/C++, en Assemblage pour l'appareil cible, en architecture VM, en analyse des performances, en sysroot avancé de la chaîne d'outils, etc. Ces personnes comptent parmi les plus brillantes et les plus talentueuses que vous pourrez rencontrer. Si vous souhaitez en savoir plus sur les efforts existants autour du JDK et du portage de la plateforme JavaSE vers le mobile, consultez : iOS Platform Implementation Details


Voici la réponse non technique, dictée par le marché, du monopole : Apple bloque le déploiement de runtimes alternatifs sur iOS. Vous ne pourriez pas, par exemple, soumettre un JDK à l'App store pour obtenir une approbation. Apple le rejetterait. L'intégration de moteurs d'exécution dans votre application était autrefois très strictement interdite, et Apple en parle dans ses directives iOS. Il existe une notion selon laquelle Apple ne veut pas soutenir les écosystèmes concurrents, et je pourrais m'étendre sur un fil entier sur les nombreuses façons dont cela se manifeste dans le processus actuel d'approbation des applications. Cependant, il semble que certaines de ces règles aient été assouplies. Pourtant, je m'attendrais à ce qu'une application aux performances lentes (en supposant que vous exécutez une VM au sein d'une application iOS) soit effectivement rejetée pour cause de violation des directives en matière de performances. Lire la suite : AppStore / Applications iOS et code interprété - où se situe la limite ? Il peut y avoir un lien historique ici aussi, il y avait une rumeur selon laquelle Steve Jobs détestait Java et a fait en sorte qu'il soit retiré de Mac OS (nous avions l'habitude de profiter d'une implémentation Java quelque peu minable sur le vieux Mac OS 8 ou plus), et il est possible que cela se soit répercuté dans l'espace iOS, bien que, qui sait. Pour des raisons techniques, il n'était probablement pas possible de l'envisager à l'époque des appareils iOS Gen1 et Gen2, en raison des ressources limitées de ces appareils. Les appareils d'aujourd'hui pourraient très certainement gérer la tâche d'exécuter une JVM.