Navigateur Web Java pur, est-ce pratique? [fermé]

Je sais qu'un navigateur Web Java est possible, mais est-ce pratique? J'ai vu le projet Lobo et je dois admettre que je suis impressionné, mais d'après ce que j'ai rassemblé, il semble que le développement s'est arrêté en 2009. Un navigateur codé en Java pur (pas de liaisons Java WebKit de tout type) pourrait-il rivaliser avec ceux parmi les rangs de Chrome ou Firefox, ou serait-ce intrinsèquement plus lent, gênant l'utilisateur?

Le langage de programmation ne sera probablement pas la pierre d'achoppement. La gestion de la mémoire obligatoire de la JVM peut être un inconvénient dans certaines parties critiques pour les performances (par exemple, la faim de mémoire; mais alors, le GC de Java pourrait en fait mieux prévenir les fuites de mémoire que tout ce que vous pourriez faire vous-même), et il y a quelques problèmes de sécurité supplémentaires, mais à part ça, je ne vois aucun bouchon de show évident.

Toutefois.

Un navigateur Web à l'échelle de Firefox ou de Chromium est une entreprise énorme , et les deux projets ont une énorme expérience derrière eux - Mozilla s'appuie sur des décennies de construction de navigateur (et certains échecs célèbres), et Chrome / Chromium a à la fois Google et Apple (une force majeure dans le développement de WebKit) derrière elle et a absorbé beaucoup de connaissances et d'expérience de KDE et d'autres grands projets Open Source solides comme le roc. Les deux utilisent en outre des dizaines de bibliothèques éprouvées au combat, non seulement des moteurs de rendu, mais toutes sortes de choses. Graphiques vectoriels, rendu de police, analyse, manipulation d'arbre XML DOM, mise en réseau, mise en cache, cryptographie, la liste s'allonge encore et encore, et vous ne voulez pas réinventer toutes ces roues vous-même, car elles sont difficiles à faire et faciles à se tromper .

En bref, la construction d'un navigateur Web de niveau industriel est sacrément difficile, et c'est la raison pour laquelle il n'y a qu'une poignée d'histoires de réussite dans ce domaine. Le langage de programmation a relativement peu à voir avec cela, bien que le C et le C ++ soient avantagés, à la fois techniquement et socialement.

En théorie, cela pourrait sans aucun doute être fait. D'un point de vue pratique, cependant, cela semble un peu plus discutable. lobon'est même pas proche de la première fois qu'il a été essayé. En fait, l'une des premières vitrines de la supériorité de Java était censée être le navigateur HotJava - qui allait changer le monde et rendre les navigateurs de la «génération Mosaic» obsolètes .

Bien sûr, nous savons tous que le contraire est vrai: HotJava est mort et n'a jamais vraiment été un concurrent sérieux dans les guerres des navigateurs (en fait, si vous recherchez "Navigateur HotJava", certains des meilleurs résultats sont des rapports de bogues). comment cela ne fonctionnait pas correctement, même pour les propres applications Web de Sun).

Personnellement, je pense que se demander si c'est possible ou pratique, c'est (principalement) regarder et penser dans la mauvaise direction. La question n'est pas de savoir si Java comporte des sanctions aussi massives pour qu'un tel projet soit impraticable. La question est de savoir si Java a suffisamment d'avantages pour justifier un tel projet.

Le simple fait est que le webkit (pour utiliser votre exemple) est un gros morceau de code complexe. Même si nous supposons que Java est tellement plus merveilleux que nous pourrions faire de même avec, disons, la moitié de la taille et de la complexité, le résultat est toujours un morceau de code assez grand et complexe (de même V8, etc.)

Je pense qu'avant de dupliquer cette quantité de travail, la plupart des gens voudraient un peu plus d'assurance que: "nous pensons que notre produit est susceptible d'être assez compétitif."

Si vous commencez à partir d'un ensemble de fonctionnalités visibles par l'utilisateur pour un navigateur, puis essayez de déterminer la manière la plus efficace de produire un navigateur avec ces fonctionnalités, "Java" ne fera probablement pas partie de cette réponse, sauf dans le cadre de " Javascript ". Si l'histoire avait fonctionné différemment, il n'y a probablement aucune raison qu'elle ne puisse pas (au moins théoriquement) faire partie de la réponse, mais compte tenu des circonstances actuelles, ce n'est pas le cas.

De plus, je vois très peu de chances que cela change. Je peux à peine voir cela se produire si Oracle (ou peut-être IBM) a décidé qu'il était utile de maintenir la position concurrentielle de Java par rapport à (pour un exemple évident) Microsoft .NET, mais cela semble douteux à moins que .NET ne commence à menacer le marché principal de Java.

En dehors de cela, tout ensemble de fonctionnalités que vous pouvez imaginer (en dehors de "écrit en Java pur comme une fonctionnalité en soi) peut presque certainement être réalisé plus rapidement et plus facilement par d'autres moyens qu'en écrivant un navigateur entièrement en Java.

Je crois honnêtement qu'une équipe dévouée et compétente pourrait créer un navigateur Web performant en Java. La vraie question est "pourquoi? Avoir le navigateur écrit dans une langue spécifique n'est pas vraiment une fonctionnalité. Les gens utiliseront Chrome parce qu'il est rapide ou Firefox parce qu'il est extensible, mais ils n'utiliseront pas JBrowser simplement parce qu'il se trouve être écrit en Java. Alors la vraie question devient, quel problème essayez-vous de résoudre?

La question suivante, en supposant que vous ayez une raison d'écrire JBrowser est, "l'utilisation de Java rend-elle la tâche plus facile ou plus difficile?" Google, lors de la création de Chrome, l'a écrit principalement en C / C ++ malgré le fait qu'il s'agit d'une boutique très pro-Java. Il semble très probable qu'ils croyaient que les avantages de Java n'apporteraient pas un gain net à temps.

Avec Nashorn (le Javascript sur la JVM remplaçant Rhino) arrivant sur la JVM dans le cadre de Java 8, c'est éminemment faisable. Cependant, comme d'autres l'ont noté - il y a énormément de choses dans un navigateur Web moderne et il semble simplement plus facile d'intégrer WebKit si vous avez besoin d'héberger des capacités de navigation dans une application Java :-).

La meilleure réponse actuelle est excellente. J'ajouterai, cependant, que l'on n'a pas besoin de recoder totalement quelque chose en Java. Il existe des outils qui convertissent la source native en bytecodes Java avec différents degrés d'interopérabilité. Ils créent souvent un interpréteur de toutes sortes ou utilisent une représentation de type JVM comme MIPS comme tremplin. Il est possible de diviser un développement de navigateur Java en plusieurs étapes en convertissant les bibliothèques natives clés en code byte Java, en les intégrant à une source de navigateur Java pure et en implémentant progressivement plus de code de bibliothèque en tant que source Java pure.

Cela vous permet de tout contenir dans la JVM plus sûre. Cependant, ce sera une douleur dans le cul assurant l'efficacité. Il existe un précédent dans la refactorisation progressive des grandes applications héritées pré-Agile / OOP. De plus, certains des composants ont déjà de bonnes implémentations Java et ceux-ci pourraient également être utilisés pour réduire le travail.

Je dois dire que je suis un peu biaisé ici, mais c'est parti. Je n'aime pas les prédicateurs C / C ++, je sais qu'il existe d'incroyables bonnes applications d'ingénierie, mais c'est juste un outil, j'ai souvent l'impression que beaucoup de gens ne mentionnant C / C ++ pour une solution manquent plus qu'un point ( http://www.paulgraham.com/avg.html voir paradoxe de l'ampoule). J'essaie de regarder les faits: Java est aussi rapide C / C ++ mais nécessite donc plus de mémoire. Ou laissez-moi reformuler, vous pouvez écrire du code java qui est aussi rapide que C / C ++ mais ce programme consommera plus de mémoire. J'espère que nous pourrons nous mettre d'accord là-dessus.

Si vous regardez la productivité, vous pouvez créer des solutions java pour certains problèmes (par exemple java d'entreprise) relativement facilement, par rapport aux solutions C ++. Un navigateur Web est quelque chose de complètement différent. Je vois deux / trois exigences du maire:

• Il doit être conforme à des spécifications énormes, HTML, JavaScript, etc. Cela implique des problèmes tels que les API de dessin 2D. Ou comment passer d'un appel système OS (en tant que primitive de dessin) à une représentation de texte ou de police («rendu»). Jetez un œil aux bibliothèques comme le Caire (C) et à d'autres tentatives comme gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Il doit "se sentir" fluide, ce qui signifie que certaines opérations n'ont besoin que de ms pour être exécutées.
• Il doit former un concept d'interface utilisateur qui forme une expérience unique, pour participer aux «guerres de navigateur» d'aujourd'hui, ce qui est assez difficile.

Pour résumer: oui, vous pouvez créer des navigateurs dans presque tous les langages de programmation avec des résultats presque identiques par rapport aux navires à vapeur C ++ d'aujourd'hui. Mais pour ce faire, vous auriez besoin de beaucoup d'efforts. Je ne sais pas combien (en millions), je ne voudrais même pas deviner cela. Peut-être que nous pourrions obtenir ce résultat: les gens n'aiment pas optimiser dans des langages de haut niveau, ou peut-être que c'est moins cher d'obtenir des gens qui aiment optimiser en C / C ++ parce qu'il y en a tellement (par rapport à d'autres experts en langues qui peuvent optimiser sur un niveau similaire).

Il serait comparable au concept de Windows 9x jours d'exécution de logiciels OpenGL vs OpenGL à accélération matérielle. Le problème avec l'utilisation de Java pour quelque chose comme un navigateur Web est que vous utilisez potentiellement de nombreux cycles d'horloge supplémentaires pour faire quelque chose qui peut être possible en beaucoup moins dans une langue plus native. C'était aussi le concept avec OpenGL - vous pouviez terminer la tâche mais il fallait beaucoup plus de traitement pour le faire.

Alors, est-ce possible? Potentiellement. Serait-ce compétitif? Peu probable - quelque chose dans un code hautement optimisé et dépendant de la plate-forme aura probablement un avantage de vitesse significatif.

Mais ce n'est que de la spéculation.

À propos de la faisabilité d'un navigateur Web Java écrit en Java, une mauvaise question a peut-être été posée.

Je ne vois pas la nécessité de réinventer la roue et d'écrire un navigateur à part entière lorsque la plupart des navigateurs existants sont gratuits et riches en fonctionnalités.

Cela dit, ce que je (nous?) Devrions rechercher est «quelque chose» assez bon pour lire des pages Web SANS toutes les conneries (re publicités, vidéos, gifs) qui s'accumulent.

Google est le principal délinquant ici avec toutes leurs annonces et autres.

Pour résoudre ce problème, j'ai écrit un navigateur Java qui utilise Java HTMLEditorKit avec son implémentation HTML 3.2 et lit une page Web sous forme de texte, supprime tout le code javascript, le code de style, les liens, les métadonnées (une autre source d'irritation avec son auto recharger) et tente de corriger certains caractères spéciaux et liens d'image définis via javascripts. Hyperliens et travaux de navigation. Pour lire des trucs comme le LA Times, le NY Times, Il Corriere.it, ElPais.es, LeMonde.fr ça livre. Même les recherches Bing et Google apparaissent. Finalement ou à la demande, je le rendrai disponible gratuitement. Ce n'est pas beaucoup mais c'est un début.

Bien sûr, cela pourrait être fait. Et cela aurait également du sens. Aucun navigateur ne prend en charge les normes complètes du W3C pour des raisons peu claires. De la part du support css3, les sociétés de navigation ne prennent pas en charge les normes non plus. -moz- * et -webkit- * ne feront jamais partie de la norme. Un navigateur conforme aux normes doit donc les ignorer. L'une des plus grandes erreurs du w3c est l'absence totale de spécifications de rendu. Ainsi, la même page Web conforme aux normes serait différente dans chaque navigateur, un cauchemar de conception graphique. Un autre échec du w3c est le manque de vitesse. 5 ans de discussion et toujours seulement un projet de norme pour html5? Ensuite, votre organisation bloque toute innovation sérieuse.

Je pense que nous devrions ignorer le w3c, ignorer leurs spécifications et créer une norme communautaire dans un délai d'un demi-an pour un langage de balisage d'application Web AVEC les spécifications de rendu et la sécurité à l'esprit. N'oubliez pas que le HTML n'a jamais été conçu pour les applications Web, car il n'y avait aucune application Web au moment où sgml était utilisé comme base pour HTML.