Le développeur de CheerpJ, une implémentation de la JVM en HTML5/WebAssembly, conçue pour exécuter des applications Java sur le navigateur, a annoncé mardi que la sortie de la version 3.0 de la plateforme est prévue pour la fin de l'été 2023. Cette nouvelle version introduira une nouvelle architecture JNI évolutive et devrait prendre en charge la compilation JIT. L'équipe affirme qu'en raison des avancées architecturales prévues dans CheerpJ 3.0, cette mouture peut être considérée comme un remplacement complet de la JVM basé sur WebAssembly, avec un environnement d'exécution OpenJDK complet. Plus d'informations devraient être disponibles à sa sortie.CheerpJ est un compilateur permettant de convertir une application client Java en HTML, JavaScript et WebAssembly standard, en travaillant à partir du bytecode Java sans avoir besoin d'accéder au code source. Il permet d'exécuter des applications et des applets Java à grande échelle et non modifiées dans le navigateur. L'exécution se fait entièrement côté client et aucun composant côté serveur n'est nécessaire en dehors d'un serveur HTTP standard. Le compilateur CheerpJ a été mis au point par Leaning Technologies, une entreprise technologique basée à Londres au Royaume-Uni, et compterait à ce jour plus de 100 000 utilisateurs dans le monde.
Selon le développeur, le succès de CheerpJ provient de sa capacité à exécuter efficacement des applications Java du monde réel avec un minimum d'effort, ce qui est très utile pour prolonger la durée de vie des applications Java côté client existantes. Cela est possible grâce à quelques fonctionnalités :
- aucun code source n'est requis : CheerpJ n'a pas besoin d'accéder au code source et fonctionne au niveau du bytecode Java dans les fichiers .class et .jar. Les bibliothèques tierces, les dépendances et le code obfusqué ne posent aucun problème ;
- prise en charge des fonctions Java avancées : toute application Java réelle, ainsi que le runtime OpenJDK lui-même, utilise la réflexion, le multithreading et les classes générées par le runtime (utilisées pour implémenter les lambdas/invokedynamic et les proxies). CheerpJ prend en charge l'ensemble de ces éléments, sans nécessiter d'adaptation de l'application ;
- compatibilité avec OpenJDK : CheerpJ est basé sur un environnement OpenJDK non modifié, garantissant le même comportement sur le navigateur par rapport à une JVM native. Il comprend de nombreuses couches d'émulation pour garantir le fonctionnement transparent du système de fichiers, du réseau, de l'impression, du presse-papiers et de nombreux autres sous-systèmes.
L'équipe a annoncé que la prochaine version du compilateur sera publiée à la fin de cet été et qu'elle sera livrée avec une nouvelle architecture. « Depuis un an, nous travaillons sur une nouvelle architecture pour CheerpJ. CheerpJ 3.0 sortira à la fin de l'été 2023 et sera plus facile à utiliser, plus rapide et plus compatible que jamais », a-t-elle déclaré. À la question de savoir pourquoi une nouvelle architecture était nécessaire, l'équipe a répondu : « bien que nous soyons fiers des résultats obtenus avec la version actuelle de CheerpJ, quelques lacunes sont apparues au fil des ans, tant en matière de capacités techniques que de facilité d'utilisation ».
Elle a ajouté : « nous avons décidé d'adopter une approche holistique pour résoudre tous ces problèmes, en redessinant l'architecture de CheerpJ depuis le début, tout en profitant des leçons tirées de CheerpX, notre machine virtuelle x86 basée sur un navigateur ». L'équipe cite notamment les problèmes suivants :
- modèle d'exécution : pour atteindre ses performances, CheerpJ inclut un compilateur AOT (Ahead-Of-Time) qui génère un fichier .jar.js optimisé pour chaque fichier .jar de l'application originale. Ces fichiers sont chargés par CheerpJ au moment de l'exécution avec leurs homologues .jar, et utilisés pour accélérer l'exécution. Ce modèle s'est avéré difficile à comprendre, à déployer et à intégrer. La nécessité d'ajouter CheerpJ en tant qu'étape de post-traitement dans une configuration de CI a souvent été ressentie comme un fardeau indésirable, et beaucoup d'utilisateurs en entreprise ont trouvé difficile d'exécuter les binaires du compilateur AOT dans leurs environnements contrôlés ;
- prise en charge limitée de ClassLoaders : la résolution des noms de classes Java en bytecode peut être entièrement contrôlée au moment de l'exécution via ClassLoaders. Le modèle de compilation AOT n'est pas vraiment compatible avec ce niveau de flexibilité. Dans les applications réelles, en particulier celles qui sont basées sur des cadres complexes, cette limitation s'est avérée plus importante que prévu. Le modèle de compilation AOT est également fragile lorsqu'il s'agit de classes dupliquées dans plusieurs fichiers jar, ce qui est assez courant pour les bibliothèques de journalisation (log4j, slf4j) ;
- temps de démarrage et taille des téléchargements : les applications Java ont tendance à être assez libérales dans l'ajout de dépendances, envoyant parfois un fichier jar entier alors qu'elles n'utilisent que quelques classes au moment de l'exécution. Dans le modèle actuel de CheerpJ, cela se traduit par le téléchargement, l'analyse et l'exécution de nombreux fichiers jar et jar.js au moment de l'exécution, ce qui ralentit le démarrage de l'application ;
- prise en charge de l'exécution limitée à Java 8 : le principal obstacle à l'ajout de la prise en charge de Java 9 et des versions ultérieures de l'exécution dans CheerpJ a été la mise en œuvre de méthodes "natives" de Java (via la JNI), qui aurait nécessité un effort répété considérable pour chaque version/sous-version supplémentaire de l'exécution.
Les principales caractéristiques de la nouvelle architecture de CheerpJ sont les suivantes :
- prise en charge de la compilation JIT : CheerpJ 3.0 propose un modèle d'exécution multiniveaux totalement transparent, qui commence par un interpréteur rapide pour le code rarement utilisé, et combine un compilateur JIT pour le code fréquemment utilisé. Avec ce nouveau modèle, aucun code n'est jamais exécuté ou généré pour les classes inutilisées, ce qui améliore les performances au démarrage. Parce qu'il n'y a pas de compilateur AOT ou de fichiers .jar.js, l'intégration et le déploiement de CheerpJ 3.0 est maintenant une question d'ajout de quelques lignes à une page HTML existante ;
- support complet de ClassLoaders : grâce à la nouvelle approche JIT, qui imite le fonctionnement normal de la JVM, l'équipe peut maintenant donner le contrôle total au ClassLoaders approprié pour la résolution des classes, y compris celles fournies par l'application. Cela élimine complètement les incompatibilités causées par des classes dupliquées ;
- une nouvelle architecture JNI évolutive : CheerpJ compile maintenant 100 % du code natif d'OpenJDK en WebAssembly, fournissant un chemin viable pour supporter les versions modernes de Java et potentiellement des versions ponctuelles spécifiques si un utilisateur le demande. Cela signifie également que CheerpJ utilise désormais une version complètement non modifiée d'OpenJDK, ce qui augmente encore son niveau de compatibilité ;
CheerpJ 3.0 est toujours en développement, mais selon l'équipe, la nouvelle plateforme est déjà suffisamment stable pour être utilisée dans sa démo JavaFiddle : un environnement entièrement côté client pour compiler, exécuter et partager du code Java dans le navigateur. La démo tire parti du fait que le compilateur Java lui-même est écrit en Java, et peut donc fonctionner dans CheerpJ également. « Grâce à ces avancées architecturales, CheerpJ 3.0 peut être considéré comme un remplacement complet de la JVM basé sur WebAssembly, avec un environnement d'exécution OpenJDK complet », a écrit l'équipe dans un billet de blogue mardi.
Source : CheerpJ 3.0
Et vous ?
Que pensez-vous de CheerpJ ? Que pensez-vous des nouveautés apportées par CheerpJ 3.0 ? Quels avantages apporte CheerpJ aux développeurs ? Selon vous, quels sont les limites de CheerpJ ? Avez-vous une expérience avec CheerpJ ? Si oui, partagez-là. Connaissez-vous ou utilisez-vous une alternative à CheerpJ ? Si oui, laquelle ?Voir aussi
Java 21 devrait inclure des collections séquencées et des modèles de chaînes de caractères, le framework des collections de Java manque d'un type de collection qui représente une séquence Oracle augmente fortement le prix des licences Java, s'appuyant désormais sur le nombre d'employés et non de processeurs. Une entreprise qualifie de « prédatrices » les stratégies d'Oracle État de JavaScript 2022 : React reste le framework front-end dominant mais est en perte de vitesse côté satisfaction, JQuery est la troisième bibliothèque la plus utilisée Une enquête sur les technologies web indique que WebAssembly serait surestimé, la quantité de code wasm dans les pages Web représente 0,06 % sur ordinateur de bureau et 0,04 % sur mobile