Navegador Java puro, é prático? [fechadas]

Sei que um navegador da Web Java é possível, mas é prático? Eu já vi o projeto Lobo e devo admitir que estou impressionado, mas pelo que eu deduzi, parece que o desenvolvimento foi interrompido em 2009. Um navegador codificado em Java puro (sem nenhuma ligação do WebKit a qualquer tipo) seria capaz de competir com aqueles entre as fileiras do Chrome ou Firefox, ou seria inerentemente mais lento, dificultando o usuário?

A linguagem de programação provavelmente não será a pedra de tropeço. O gerenciamento de memória obrigatório da JVM pode ser uma desvantagem em algumas partes críticas de desempenho (por exemplo, falta de memória; mas, em seguida, o GC do Java pode realmente ser melhor na prevenção de vazamentos de memória do que qualquer coisa que você possa fazer), e existem algumas preocupações adicionais de segurança, mas fora isso, não vejo rolhas óbvias.

Contudo.

Um navegador da Web na escala do Firefox ou do Chromium é um empreendimento enorme , e os dois projetos têm uma enorme experiência por trás deles - a Mozilla baseia-se em décadas de criação de navegadores (e algumas falhas famosas), e o Chrome / Chromium possui Google e Apple (uma força importante no desenvolvimento do WebKit) por trás dele e absorveu muito conhecimento e experiência do KDE e outros grandes projetos de código aberto sólidos. Além disso, os dois usam dezenas de bibliotecas comprovadas em batalha, não apenas renderizando mecanismos, mas todo o tipo de coisas. Gráficos vetoriais, renderização de fontes, análise, manipulação da árvore DOM XML, rede, cache, criptografia, a lista continua e você não deseja reinventar todas essas rodas, porque elas são difíceis de fazer e fáceis de errar .

Em suma, a construção de um navegador da Web com força de mercado é bastante difícil, e é por isso que há apenas algumas histórias de sucesso nessa arena. A linguagem de programação tem relativamente pouco a ver com isso, embora C e C ++ estejam em vantagem, tanto técnica quanto socialmente.

Em teoria, isso poderia, sem dúvida, ser feito. Do ponto de vista prático, no entanto, parece um pouco mais questionável. lobonão é nem perto da primeira vez que foi tentado. De fato, uma das primeiras exibições da superioridade do Java era o navegador HotJava - que mudaria o mundo e tornaria obsoletos os navegadores "Mosaic generation" .

Obviamente, todos sabemos que o oposto é verdadeiro: o HotJava está morto e nunca foi um concorrente sério nas guerras dos navegadores (na verdade, se você procurar pelo "navegador HotJava", alguns dos principais hits são para relatos de erros sobre como não funcionou corretamente, mesmo para os aplicativos da Web da Sun).

Pessoalmente, acho que saber se é possível ou prático é (principalmente) olhar e pensar na direção errada. A questão não é se o Java acarreta penalidades maciças para que esse projeto seja impraticável. A questão é se o Java tem vantagens suficientes para justificar esse projeto.

O simples fato é que o webkit (para usar seu exemplo) é um grande e complexo pedaço de código. Mesmo se assumirmos que o Java é muito mais maravilhoso que poderíamos fazer o mesmo com, digamos, metade do tamanho e da complexidade, o resultado ainda é um pedaço de código bastante grande e complexo (da mesma forma V8, etc.)

Acho que antes de duplicar essa quantidade de trabalho, a maioria das pessoas gostaria de ter um pouco mais de segurança do que: "achamos que nosso produto provavelmente será bastante competitivo".

Se você iniciar a partir de um conjunto de recursos visíveis ao usuário para um navegador e tentar determinar a maneira mais eficiente de produzir um navegador com esses recursos, "Java" provavelmente não fará parte dessa resposta, exceto como parte de " Javascript ". Se a história funcionou de maneira diferente, provavelmente não há razão para que não possa (pelo menos teoricamente) fazer parte da resposta, mas, dadas as circunstâncias atuais, não é.

Além disso, vejo muito pouca probabilidade dessa mudança. Eu mal consigo ver isso acontecendo se a Oracle (ou possivelmente a IBM) decidiu que era útil manter a posição competitiva de Java versus (para um exemplo óbvio) o Microsoft .NET, mas isso parece duvidoso, a menos que o .NET comece a ameaçar o mercado principal do Java.

Fora isso, qualquer conjunto de recursos que você possa imaginar (fora do "escrito em Pure Java" como um recurso em si) pode quase certamente ser alcançado de maneira mais rápida e fácil de outras maneiras do que escrever um navegador inteiramente em Java.

Sinceramente, acredito que uma equipe dedicada e experiente possa criar um navegador de alto desempenho em Java. A verdadeira questão é por quê? Ter o navegador escrito em um idioma específico não é realmente um recurso. As pessoas usarão o Chrome porque é rápido ou o Firefox porque é extensível, mas não usarão o JBrowser apenas porque é escrito em Java. Então a verdadeira questão se torna: qual problema você está tentando resolver?

A próxima pergunta, supondo que você tenha um motivo para escrever o JBrowser, é: "Usar Java facilita ou dificulta a tarefa?" O Google, ao criar o Chrome, o escreveu principalmente em C / C ++, apesar de ser uma loja muito pró-Java. Parece bastante provável que eles acreditassem que os benefícios do Java não trariam um ganho líquido com o tempo.

Com Nashorn (o Javascript na JVM substituindo o Rhino) chegando à JVM como parte do Java 8, isso é eminentemente possível. No entanto, como outros observaram - há muito em um navegador da Web moderno e parece mais fácil incorporar o WebKit se você precisar hospedar recursos de navegação em um aplicativo Java :-).

A principal resposta atual é excelente. Acrescentarei, no entanto, que não é necessário recodificar totalmente algo em Java. Existem ferramentas que convertem fonte nativa em bytecodes Java com graus variados de interoperabilidade. Eles geralmente criam um tipo de intérprete ou usam uma representação semelhante à JVM, como MIPS, como um trampolim. É possível dividir o desenvolvimento do navegador Java em várias etapas, convertendo as principais bibliotecas nativas em bytecode Java, integrando-as à fonte pura do navegador Java e implementando gradualmente mais código da biblioteca como fonte pura do Java.

Isso permite que você contenha tudo dentro da JVM mais segura. No entanto, será uma dor no traseiro, garantindo eficiência. Há algum precedente na refatoração gradual de grandes aplicativos legados pré-Agile / OOP. Além disso, alguns dos componentes já possuem boas implementações Java e podem ser usados ​​também para reduzir a mão-de-obra.

Devo dizer que sou um pouco tendenciosa aqui, mas aqui vou eu. Eu não gosto dos pregadores de C / C ++, sei que existem alguns aplicativos de engenharia incríveis por aí, mas é apenas uma ferramenta A, muitas vezes tive a impressão, muitas pessoas mencionando C / C ++ para uma solução perdem mais do que um ponto ( http://www.paulgraham.com/avg.html veja paradoxo da lâmpada). Eu tento olhar para os fatos: Java é tão rápido em C / C ++, mas requer mais memória. Ou deixe-me reformular que você pode escrever código java que é tão rápido quanto C / C ++, mas esse programa consumirá mais memória. Espero que possamos concordar com isso.

Se você observar a produtividade, poderá criar soluções java para certos problemas (por exemplo, java corporativo) relativamente fáceis, em comparação com as soluções C ++. Um navegador da web é algo completamente diferente. Eu vejo dois / três requisitos de prefeito:

• Ele precisa estar em conformidade com grandes especificações, HTML, JavaScript etc. Isso envolve problemas como APIs de desenho 2D. Ou como passar de uma chamada do sistema OS (como uma primitiva de desenho) para uma representação de texto ou fonte ("renderização"). Dê uma olhada em bibliotecas como cairo (C) e outras tentativas como gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Ele precisa “parecer” fluente, o que significa que certas operações só precisam de ms para serem executadas.
• Ele precisa formar um conceito de interface do usuário que forme uma experiência única, para competir nas 'guerras de navegadores' de hoje, o que é bastante desafiador.

Resumindo: sim, você poderia, poderia criar navegadores em quase qualquer linguagem de programação com resultados quase idênticos em comparação com os navios a vapor C ++ de hoje. Mas para fazer isso, você precisaria de uma quantidade extraordinária de esforço. Não sei quanto (em milhões), nem gostaria de adivinhar. Talvez possamos entender o seguinte: as pessoas não gostam de otimizar em linguagens de alto nível, ou talvez seja mais barato fazer com que as pessoas que desejam otimizar em C / C ++ porque existem muitas (em comparação com outros especialistas em linguagem que podem otimizar em um nível semelhante).

Seria comparável ao conceito nos dias 9x do Windows de executar o software OpenGL versus o OpenGL acelerado por hardware. O problema com o uso de Java para algo como um navegador da Web é que você potencialmente usa muitos ciclos de relógio extras para fazer algo que pode ser possível em muito menos em uma linguagem mais nativa. Esse também era o conceito do OpenGL - era possível concluir a tarefa, mas era preciso muito mais processamento para fazê-lo.

Então é possível? Potencialmente. Seria competitivo? Improvável - algo em código altamente otimizado e dependente da plataforma provavelmente terá uma vantagem de velocidade significativa.

Isso é apenas especulação.

Sobre a viabilidade de um navegador Java escrito em Java, talvez a pergunta errada tenha sido feita.

Não vejo necessidade de reinventar a roda e escrever um navegador completo quando a maioria dos existentes é gratuita e possui muitos recursos.

Dito isto, o que eu (nós?) Deveríamos procurar é "algo" bom o suficiente para ler páginas da Web SEM TODA A porcaria (re anúncios, vídeos, gifs) que é empilhada.

O Google é o principal infrator aqui com todos os seus anúncios e coisas do gênero.

Para endereçar que escrevi um navegador Java que usa o Java HTMLEditorKit com sua implementação HTML 3.2 e lê uma página da Web como texto, retira todo o código javascript, o código de estilo, os links e os metadados (outra fonte de irritação com seu auto recarregar) e tenta corrigir alguns caracteres especiais e links de imagem definidos por javascripts. Hiperlinks e trabalho de navegação. Para ler coisas como o LA Times, o NY Times, o Il Corriere.it, o ElPais.es, o LeMonde.fr, ele fornece. Até as pesquisas do Bing e do Google são apresentadas. Eventualmente ou quando solicitado, eu o disponibilizarei gratuitamente. Não é muito, mas é um começo.

Claro que isso poderia ser feito. E faria sentido também. Nenhum navegador suporta os padrões completos do w3c por razões pouco claras. Por parte do suporte a css3, as empresas de navegadores também não suportam padrões. -moz- * e -webkit- * nunca farão parte do padrão. Portanto, um navegador compatível com os padrões completos deve ignorá-los. Um dos maiores erros do w3c é a total falta de especificações de renderização. Portanto, a mesma página da Web compatível com os padrões pareceria diferente em todos os navegadores, um pesadelo de design gráfico. Outra falha do w3c é a falta de velocidade. 5 anos de discussão e ainda apenas um rascunho de padrão para html5? Então sua organização está bloqueando qualquer inovação séria.

Acho que devemos ignorar o w3c, ignorar suas especificações e criar um padrão de comunidade dentro de meio ano para uma linguagem de marcação de aplicativos da Web, considerando as especificações e a segurança. Lembre-se de que o HTML nunca foi projetado para aplicativos da Web, porque não havia aplicativos da Web no momento em que o sgml foi usado como base para o HTML.