Êtes-vous actuellement en train de débattre de l'opportunité d'utiliser Java pour votre prochaine application, ou d'utiliser des kits d'outils et des frameworks natifs ? Vous souhaitez connaître les avantages de Java par rapport à la programmation native pour une application ? Lisez la suite pour le savoir !
Une application native est un programme écrit spécifiquement pour un système d'exploitation (OS), et éventuellement pour le matériel spécifique exécutant ce système d'exploitation. Il est principalement écrit dans un langage tel que C/C++. Le code source C/C++ est compilé sous forme d'objet à l'aide d'un compilateur, qui est ensuite assemblé en un exécutable en liant les bibliothèques requises. Un programme construit de cette manière fonctionnera sur le matériel et le système d'exploitation spécifiques pour lesquels il est conçu, mais peut ne pas fonctionner correctement sur d'autres systèmes.
Un compilateur pour un langage tel que C/C++ traduit les instructions de code source en langage machine pour le processeur ciblé. Lorsque vous essayez d'exécuter ce code sur un processeur différent, le programme peut ne pas fonctionner correctement (ou ne pas fonctionner du tout) car les instructions en langage machine dans le code compilé peuvent ne pas être prises en charge par ce processeur.
De plus, le nouveau système d'exploitation peut être différent de celui d'origine et peut même ne pas reconnaître le fichier programme en tant qu'exécutable. Cela est dû aux différents formats de fichiers utilisés pour les exécutables sur différents systèmes d'exploitation (tels que Windows, Linux, MacOS, etc.).
La portabilité est un si gros problème avec les applications natives que la simple mise à niveau du compilateur vers la prochaine version peut introduire des changements avec rupture. Votre code devra peut-être être corrigé pour fonctionner avec le nouveau compilateur. En tant que tel, éclabousser le code source avec ce qu'on appelle ifdef les instructions pour isoler les solutions de contournement spécifiques au matériel, au système d'exploitation ou au compilateur sont courantes.
Ce qui suit est un petit extrait de code de la bibliothèque de compression BZLib qui illustre l'utilisation de ifdef s pour isoler les particularités de la plateforme :
#ifdef _WIN32
# inclure
# ifdef petit
/* windows.h définit petit en char */
# undef petit
# fin si
# ifdef BZ_EXPORT
# définir BZ_API(func) WINAPI func
# définir BZ_EXTERN externe
# autre
/* importe dynamiquement la dll windows */
# définir BZ_API(fonc) (WINAPI * func)
# définir BZ_EXTERN
# fin si
#autre
# définir la fonction BZ_API(func)
# définir BZ_EXTERN externe
#fin si
Cette situation peut être atténuée dans une certaine mesure en recompilant le code source C/C++ sur le nouveau CPU. Cependant, le système d'exploitation du nouveau processeur peut être différent. Et le code source peut ne pas être compilé sans modifications, qu'elles soient majeures ou mineures. Même des changements mineurs dans les versions du système d'exploitation peuvent nécessiter des modifications du code source.
Et lorsque vous considérez des systèmes d'exploitation dissemblables tels que Windows et Linux/UNIX, la portabilité est un tout nouveau jeu de balle. À moins que vous n'utilisiez une boîte à outils ou un framework qui vous isole complètement du système d'exploitation, la portabilité du code source est impossible. En effet, l'interface du système d'exploitation est complètement différente entre ces systèmes. Si vous, dans les coins les plus reculés de votre code, utilisez directement des primitives de système d'exploitation, votre code ne sera pas portable sur ces divers systèmes d'exploitation.
C'est dans ce scénario que Java propose un nouveau paradigme, une nouvelle façon de créer des logiciels. Lors de la programmation en java, vous ciblez une machine virtuelle . Une telle machine existe en tant que concept, et le langage java fournit des interfaces pour programmer sur cette machine. Par exemple, vous pouvez interroger la quantité de mémoire disponible, le nombre de CPU, les interfaces réseau, etc. de la machine virtuelle.
Le langage java fournit un compilateur java qui traduit le code source en code objet. Le code objet est ensuite exécuté par la machine virtuelle Java , qui est un programme distinct du compilateur. Le système d'exploitation, à son tour, considère la machine virtuelle Java comme un simple programme s'exécutant sur ce système d'exploitation.
Le fardeau de la portabilité est désormais passé du programmeur d'applications au fournisseur de machines virtuelles Java. Le programmeur d'application écrit le logiciel en utilisant les primitives du langage Java, et la machine virtuelle Java est responsable de la traduction de ces primitives vers les installations du système d'exploitation hôte. Lorsqu'une nouvelle version du système d'exploitation sort, il est de la responsabilité du fournisseur de mettre à jour la machine virtuelle Java afin qu'elle fonctionne correctement sur le nouveau système d'exploitation.
Comme mentionné précédemment, la machine virtuelle Java fournit une vue virtuelle du système d'exploitation et du matériel au programmeur d'applications. Cette vue virtuelle se présente sous la forme de diverses interfaces et méthodes, et sert à isoler le programmeur d'application des différences entre le système d'exploitation hôte et le matériel sous-jacent. Ainsi, le programmeur d'application peut accéder à des fonctionnalités telles qu'une boîte à outils de fenêtrage, une mise en réseau, des graphiques 3D, plusieurs processeurs, etc. sans avoir à recourir à des appels de bas niveau qui finissent par rendre le programme non portable.
Un programme java est écrit et compilé à l'aide du compilateur java. Le code objet résultant (appelé byte code ) peut être transporté vers un système d'exploitation hôte différent exécuté sur un matériel différent et devrait fonctionner sans problème.
La machine virtuelle Java utilise un compilateur JIT pour optimiser le code d'octet spécifiquement pour le CPU cible. JIT signifie juste à temps et fait référence aux optimisations d'exécution que la JVM applique au bytecode pour qu'il fonctionne mieux sur le CPU actuel.
Un autre avantage de l'utilisation de la machine virtuelle Java est qu'elle peut appliquer différentes optimisations pour différents cas d'utilisation, toutes avec le même code d'octet. Par exemple, la JVM Oracle propose deux options pour exécuter le bytecode :un mode serveur et un mode client. Le mode serveur optimise les programmes serveur de longue durée, tandis que le mode JVM client optimise les temps de réponse rapides car il est probablement utilisé en mode interactif.
Pour résumer, une application native est conçue pour un matériel et un système d'exploitation spécifiques. Une application Java, en revanche, suit un processus Build Once Run Anywhere philosophie, en demandant à une JVM d'exécuter les instructions de code d'octet compilées. Bien que les applications natives soient traditionnellement considérées comme plus performantes que les applications Java, cela peut ne pas toujours être vrai en raison de l'utilisation d'un compilateur JIT par la JVM.
Avez-vous développé une application native et avez-vous dû passer à Java en raison de la portabilité ? Ou vice versa en raison de problèmes de performances ? Faites-le nous savoir dans les commentaires ci-dessous.
Crédit image :Profit_Image via Shutterstock.com