Sé que un navegador web Java es posible, pero ¿es práctico? He visto el proyecto Lobo y debo admitir que estoy impresionado, pero por lo que he reunido parece que el desarrollo se detuvo en 2009. ¿Un navegador codificado en Java puro (sin enlaces WebKit de Java de ningún tipo) podría competir con aquellos entre las filas de Chrome o Firefox, o sería inherentemente más lento, lo que dificultaría al usuario?
29
Respuestas:
Lo más probable es que el lenguaje de programación no sea el obstáculo. La gestión de memoria obligatoria de la JVM puede ser una desventaja en algunas partes críticas para el rendimiento (por ejemplo, falta de memoria; pero entonces, el GC de Java podría ser mejor para prevenir pérdidas de memoria que cualquier cosa que pueda rodar usted mismo), y hay algunas preocupaciones de seguridad adicionales, Pero aparte de eso, no veo obvios tapones de espectáculo.
Sin embargo.
Un navegador web en la escala de Firefox o Chromium es una tarea enorme , y ambos proyectos tienen una gran experiencia detrás de ellos: Mozilla se basa en décadas de construcción de navegadores (y algunas fallas famosas), y Chrome / Chromium tiene Google y Apple (una fuerza importante en el desarrollo de WebKit) detrás de él y absorbió una gran cantidad de conocimiento y experiencia de KDE y otros grandes proyectos de código abierto sólidos como una roca. Ambos hacen uso adicional de docenas de bibliotecas probadas en batalla, no solo motores de renderizado, sino todo tipo de cosas. Los gráficos vectoriales, la representación de fuentes, el análisis, la manipulación del árbol XML DOM, la creación de redes, el almacenamiento en caché, la criptografía, la lista sigue y sigue, y no desea reinventar todas esas ruedas usted mismo, porque son difíciles de hacer y fáciles de equivocar. .
En resumen, construir un navegador web de fuerza industrial es bastante difícil, y esa es la razón por la que solo hay un puñado de historias de éxito en este campo. El lenguaje de programación tiene relativamente poco que ver, aunque C y C ++ tienen una ventaja, tanto técnica como social.
fuente
En teoría, sin duda podría hacerse. Desde un punto de vista práctico, sin embargo, parece un poco más cuestionable.
loboni siquiera está cerca de la primera vez que se ha probado. De hecho, se suponía que uno de los primeros escaparates de la superioridad de Java era el navegador HotJava, que iba a cambiar el mundo y dejaría obsoletos a los navegadores de "generación mosaica" .Por supuesto, todos sabemos que lo contrario es cierto: HotJava está muerto y nunca fue realmente un competidor serio en las guerras de los navegadores (de hecho, si busca "HotJava browser", algunos de los mejores resultados son informes de errores sobre cómo no funcionó correctamente, incluso para las propias aplicaciones web de Sun).
Personalmente, creo que preguntarme si es posible o práctico es (principalmente) mirar y pensar en la dirección equivocada. La pregunta no es si Java conlleva sanciones tan masivas para que un proyecto de este tipo no sea práctico. La pregunta es si Java tiene suficientes ventajas para justificar tal proyecto.
El hecho simple es que webkit (para usar su ejemplo) es una pieza de código grande y compleja. Incluso si suponemos que Java es mucho más maravilloso que podríamos hacer lo mismo con, digamos, la mitad del tamaño y la complejidad, el resultado sigue siendo un código bastante grande y complejo (del mismo modo V8, etc.)
Creo que antes de duplicar esa cantidad de trabajo, la mayoría de la gente querría un poco más de seguridad que: "creemos que nuestro producto es probable que sea bastante competitivo".
Si comienza desde un conjunto de características visibles para el usuario para un navegador, y luego trata de determinar la forma más eficiente de producir un navegador con esas características, "Java" probablemente no será parte de esa respuesta, excepto como parte de " Javascript ". Si la historia hubiera funcionado de manera diferente, probablemente no haya razón para que no pueda (al menos en teoría) ser parte de la respuesta, pero dadas las circunstancias actuales, no lo es.
Además, veo muy pocas posibilidades de que ese cambio. Apenas puedo ver que suceda si Oracle (o posiblemente IBM) decidió que era útil mantener la posición competitiva de Java frente a (por un ejemplo obvio) Microsoft .NET, pero eso parece dudoso a menos que .NET comience a amenazar el mercado central de Java.
Fuera de eso, cualquier conjunto de características que pueda imaginar (fuera de "escrito en Java puro" como una característica en sí misma) casi con certeza se puede lograr de manera más rápida y fácil de otras maneras que escribiendo un navegador completamente en Java.
fuente
Sinceramente, creo que un equipo dedicado y conocedor podría crear un navegador web de alto rendimiento en Java. La verdadera pregunta es, ¿por qué? Tener el navegador escrito en un idioma específico no es realmente una característica. La gente usará Chrome porque es rápido o Firefox porque es extensible, pero no usarán JBrowser solo porque está escrito en Java. Entonces, la verdadera pregunta es: ¿qué problema estás tratando de resolver?
La siguiente pregunta, suponiendo que tenga una razón para escribir JBrowser es, "¿el uso de Java hace que la tarea sea más fácil o más difícil?" Google, al hacer Chrome, lo escribió principalmente en C / C ++ a pesar del hecho de que son una tienda muy pro-Java. Parece bastante probable que creyeran que los beneficios de Java no traerían una ganancia neta a tiempo.
fuente
Con Nashorn (el Javascript en la JVM reemplazando a Rhino) llegando a la JVM como parte de Java 8, esto es eminentemente factible. Sin embargo, como otros han señalado, un navegador web moderno tiene muchísimo y parece más fácil incrustar WebKit si necesita alojar capacidades de navegación dentro de una aplicación Java :-).
fuente
La respuesta principal actual es excelente. Sin embargo, agregaré que uno no necesita recodificar totalmente algo en Java. Existen herramientas que convierten la fuente nativa en códigos de bytes Java con diversos grados de interoperabilidad. A menudo crean una especie de intérprete o utilizan una representación similar a JVM como MIPS como un trampolín. Uno podría dividir el desarrollo de un navegador Java en muchos pasos al convertir bibliotecas nativas clave en código de bytes Java, integrarlas con la fuente pura del navegador Java e implementar gradualmente más código de biblioteca como fuente pura de Java.
Esto le permite contener todo dentro de la JVM más segura. Sin embargo, será un dolor en el trasero asegurando la eficiencia. Hay un precedente en la refactorización gradual de aplicaciones heredadas grandes, pre-Agile / OOP. Además, algunos de los componentes ya tienen buenas implementaciones de Java y también podrían usarse para reducir la mano de obra.
fuente
Tengo que decir que estoy un poco parcial aquí, pero aquí voy. No me gustan los predicadores de C / C ++, sé que hay algunas aplicaciones de ingeniería increíblemente buenas por ahí, pero es solo una herramienta, a menudo tengo la impresión, muchas personas solo mencionan C / C ++ para una solución que pierden más de un punto ( http://www.paulgraham.com/avg.html ver la paradoja del bulbo). Intento ver los hechos: Java es tan rápido C / C ++ pero requiere más memoria por lo tanto. O déjame reformular, puedes escribir código java que es tan rápido como C / C ++ pero ese programa consumirá más memoria. Espero que podamos estar de acuerdo en esto.
Si observa la productividad, puede crear soluciones Java para ciertos problemas (por ejemplo, Enterprise Java) relativamente fácil, en comparación con las soluciones C ++. Un navegador web es algo completamente diferente. Veo dos / tres requisitos principales:
Para resumir: sí, podría crear navegadores en casi cualquier lenguaje de programación con resultados casi idénticos en comparación con los buques de vapor C ++ actuales. Pero para hacerlo, necesitarías una cantidad extraordinaria de esfuerzo. No sé cuánto (en millones), no quisiera adivinar eso. Tal vez podríamos obtener este resultado final: a las personas no les gusta optimizar en lenguajes de alto nivel, o tal vez sea más barato obtener personas que les guste optimizar en C / C ++ porque hay muchos (en comparación con otros expertos en idiomas que pueden optimizar en un nivel similar)
fuente
Sería comparable al concepto en los días de Windows 9x de ejecución del software OpenGL frente a OpenGL acelerado por hardware. El problema con el uso de Java para algo así como un navegador web es que potencialmente usa muchos ciclos de reloj adicionales para hacer algo que puede ser posible en muchos menos en un idioma más nativo. Ese también era el concepto con OpenGL: se podía completar la tarea pero se requería mucho más procesamiento para hacerlo.
Entonces, ¿es posible? Potencialmente. ¿Sería competitivo? Improbable: algo en el código altamente optimizado y dependiente de la plataforma probablemente tendrá una ventaja de velocidad significativa.
Sin embargo, esto es meramente una especulación.
fuente
Sobre la viabilidad de un navegador web Java escrito en Java, tal vez se hizo una pregunta incorrecta.
No veo la necesidad de reinventar la rueda y escribir un navegador completo cuando la mayoría de los existentes son gratuitos y tienen muchas funciones.
Dicho esto, lo que yo (¿nosotros?) Deberíamos buscar es "algo" lo suficientemente bueno como para leer páginas web SIN toda la basura (publicidad, videos, gifs) que se acumula.
Google es el principal delincuente aquí con todos sus anuncios y tal.
Para abordar eso, escribí un navegador Java que usa el Java HTMLEditorKit con su implementación HTML 3.2 y lee una página web como texto, elimina todo el código javascript, el código de estilo, los enlaces, los metadatos (otra fuente de irritación con su auto reload) e intenta corregir algunos caracteres especiales y enlaces de imágenes establecidos mediante javascripts. Hipervínculos y trabajos de navegación. Para leer cosas como LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr que ofrece. Incluso Bing y las búsquedas de Google llegan. Finalmente o cuando me lo pida, lo pondré a disposición de forma gratuita. No es mucho pero es un comienzo.
fuente
Claro que se podría hacer. Y también tendría sentido. Ningún navegador admite los estándares completos de w3c por razones poco claras. Por parte del soporte de css3, las compañías de navegadores tampoco admiten estándares. -moz- * y -webkit- * nunca serán parte del estándar. Por lo tanto, un navegador que cumpla con los estándares completos debería ignorarlos. Uno de los mayores errores de w3c es la falta total de especificaciones de representación. Entonces, la misma página web que cumple con los estándares se vería diferente en cada navegador, una pesadilla de diseño gráfico. Otro error del w3c es la falta de velocidad. ¿5 años de discusión y todavía solo un borrador de estándar para html5? Entonces su organización está bloqueando cualquier innovación seria.
Creo que deberíamos ignorar w3c, ignorar sus especificaciones y hacer un estándar de la comunidad dentro de medio año para un lenguaje de marcado de aplicaciones web CON las especificaciones de representación y la seguridad en mente. Recuerde que HTML nunca fue diseñado para aplicaciones web, porque no había aplicaciones web en el momento en que se usaba sgml como base para HTML.
fuente