Browser Web Pure Java, è pratico? [chiuso]

So che è possibile un browser Web Java, ma è pratico? Ho visto il progetto Lobo e devo ammettere che sono rimasto colpito, ma da quello che ho raccolto sembra che lo sviluppo si sia fermato nel 2009. Un browser codificato in Java puro (nessun bind WebKit java di alcun tipo) sarebbe in grado di competere con quelli tra i ranghi di Chrome o Firefox, o sarebbero intrinsecamente più lenti, ostacolando l'utente?

Molto probabilmente il linguaggio di programmazione non sarà il ostacolo. La gestione obbligatoria della memoria della JVM potrebbe essere uno svantaggio in alcune parti critiche per le prestazioni (ad es. Fame di memoria; ma poi, il GC di Java potrebbe effettivamente essere più efficace nel prevenire perdite di memoria rispetto a qualsiasi altra cosa che potresti farti), e ci sono alcuni problemi di sicurezza aggiuntivi, ma a parte questo, non vedo tappi di spettacolo ovvi.

Tuttavia.

Un browser Web su scala di Firefox o Chromium è un'impresa enorme , ed entrambi i progetti hanno alle spalle una vasta esperienza: Mozilla si basa su decenni di sviluppo del browser (e alcuni errori famosi) e Chrome / Chromium ha sia Google che Apple (una delle principali forze nello sviluppo di WebKit) e assorbito molta conoscenza ed esperienza da KDE e altri grandi progetti Open Source solidi come una roccia. Entrambi fanno inoltre uso di dozzine di librerie comprovate dalla battaglia, non solo rendono i motori, ma ogni sorta di cose. Grafica vettoriale, rendering dei caratteri, analisi, manipolazione dell'albero DOM DOM XML, networking, memorizzazione nella cache, crittografia, l'elenco potrebbe continuare all'infinito e non si desidera reinventare tutte quelle ruote da soli, perché sono difficili da fare e facili da sbagliare .

In breve, costruire un browser Web di livello industriale è piuttosto difficile, ed è per questo che ci sono solo poche storie di successo in questo campo. Il linguaggio di programmazione ha relativamente poco a che fare con esso, sebbene C e C ++ siano vantaggiosi, sia tecnicamente che socialmente.

In teoria, potrebbe senza dubbio essere fatto. Da un punto di vista pratico, tuttavia, sembra un po 'più discutibile. lobonon è nemmeno vicino alla prima volta che è stato provato. In effetti, una delle prime vetrine della superiorità di Java doveva essere il browser HotJava - che avrebbe cambiato il mondo e reso obsoleti i browser "generazione Mosaic" .

Ovviamente, sappiamo tutti che è vero il contrario: HotJava è morto e non è mai stato un serio concorrente nelle guerre del browser (in effetti, se cerchi "HotJava browser", alcuni dei risultati migliori sono segnalazioni di bug su come non ha funzionato correttamente, anche per le app Web di Sun).

Personalmente, penso che chiedermi se sia possibile o pratico sia (principalmente) guardare e pensare nella direzione sbagliata. La domanda non è se Java comporti sanzioni così ingenti per un progetto del genere che non è pratico. La domanda è se Java ha abbastanza vantaggi per giustificare un simile progetto.

Il semplice fatto è che webkit (per usare il tuo esempio) è un pezzo di codice grande e complesso. Anche se supponiamo che Java sia molto più meraviglioso che potremmo fare lo stesso con, diciamo, metà dimensioni e complessità, il risultato è ancora un pezzo di codice piuttosto grande e complesso (come V8, ecc.)

Penso che prima di duplicare quella quantità di lavoro, la maggior parte delle persone vorrebbe un po 'più di sicurezza rispetto a: "pensiamo che il nostro prodotto sarà probabilmente abbastanza competitivo".

Se inizi da una serie di funzionalità visibili all'utente per un browser e poi provi a determinare il modo più efficiente per produrre un browser con tali funzionalità, "Java" probabilmente non farà parte di quella risposta, tranne che come parte di " Javascript". Se la storia avesse funzionato diversamente, probabilmente non c'è motivo per cui (almeno teoricamente) non potesse far parte della risposta, ma date le circostanze attuali, non lo è.

Inoltre, vedo ben poche probabilità di questo cambiamento. Riesco a malapena a vederlo accadere se Oracle (o forse IBM) decidesse che era utile mantenere la posizione competitiva di Java rispetto (per un esempio ovvio) a Microsoft .NET, ma ciò sembra dubbio a meno che .NET non inizi a minacciare il mercato principale di Java.

Oltre a ciò, qualsiasi set di funzionalità che si possa immaginare (al di fuori di "scritto in Pure Java" come funzionalità in sé) può quasi sicuramente essere raggiunto più velocemente e più facilmente in altri modi rispetto alla scrittura di un browser interamente in Java.

Credo sinceramente che un team dedicato e competente possa creare un browser Web performante in Java. La vera domanda è: perché? Avere il browser scritto in una lingua specifica non è davvero una caratteristica. Le persone useranno Chrome perché è veloce o Firefox perché è estensibile, ma non useranno JBrowser solo perché sembra essere scritto in Java. Quindi la vera domanda diventa: quale problema stai cercando di risolvere?

La domanda successiva, supponendo che abbiate un motivo per scrivere JBrowser, è "usare Java rende l'attività più facile o più difficile?" Google, durante la creazione di Chrome, lo ha scritto principalmente in C / C ++ nonostante sia un negozio molto pro-Java. Sembra abbastanza probabile che credessero che i benefici di Java non avrebbero portato in tempo un guadagno netto.

Con Nashorn (il Javascript sulla JVM che sostituisce Rhino) che arriva alla JVM come parte di Java 8, questo è eminentemente fattibile. Tuttavia, come altri hanno notato, c'è molto da dire in un moderno browser Web e sembra più semplice integrare WebKit se è necessario ospitare le funzionalità di navigazione all'interno di un'app Java :-).

L'attuale risposta migliore è eccellente. Aggiungerò, tuttavia, che non è necessario ricodificare totalmente qualcosa in Java. Esistono strumenti che convertono l'origine nativa in bytecode Java con vari gradi di interoperabilità. Spesso creano un tipo di interprete o usano una rappresentazione simile alla JVM come MIPS come trampolino di lancio. Si potrebbe spezzare lo sviluppo di un browser Java in molti passaggi convertendo le librerie native chiave in bytecode Java, integrandole con una fonte browser Java pura e implementando gradualmente più codice libreria come fonte Java pura.

Ciò consente di contenere tutto all'interno della JVM più sicura. Tuttavia, sarà un dolore nel sedere garantendo efficienza. C'è qualche precedente nel refactoring graduale di applicazioni legacy pre-Agile / OOP di grandi dimensioni. Inoltre, alcuni dei componenti hanno già buone implementazioni Java e potrebbero essere utilizzati anche per ridurre la manodopera.

Devo dire che sono un po 'di parte qui, ma qui vado. Non mi piacciono i predicatori C / C ++, so che ci sono alcune incredibili applicazioni ingegnerizzate là fuori ma è solo uno strumento, spesso ho avuto l'impressione, molte persone che menzionano solo C / C ++ per una soluzione mancano più di un punto ( http://www.paulgraham.com/avg.html vedi paradosso della lampadina). Provo a guardare ai fatti: Java è veloce come C / C ++ ma richiede quindi più memoria. O lasciami riformulare puoi scrivere codice java che è veloce come C / C ++ ma quel programma consumerà più memoria. Spero che possiamo essere d'accordo su questo.

Se si considera la produttività, è possibile creare soluzioni Java per determinati problemi (ad esempio Java Enterprise) relativamente semplice, rispetto alle soluzioni C ++. Un browser Web è qualcosa di completamente diverso. Vedo due / tre requisiti del sindaco:

• Deve essere conforme a enormi specifiche, HTML, JavaScript, ecc. Ciò comporta problemi come le API di disegno 2D. O come passare da una chiamata di sistema del sistema operativo (come primitiva di disegno) alla rappresentazione di testo o font ("rendering"). Dai un'occhiata a biblioteche come il Cairo (C) e altri tentativi come Gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Deve "sentirsi" fluente, il che significa che alcune operazioni devono essere eseguite solo da ms.
• Deve formare un concetto di interfaccia utente che formi un'esperienza unica, per competere nelle "guerre dei browser" di oggi, il che è piuttosto impegnativo.

Per riassumere: sì, potresti creare browser in quasi tutti i linguaggi di programmazione con risultati quasi identici rispetto ai piroscafi C ++ di oggi. Ma per fare ciò occorrerebbe uno sforzo davvero straordinario. Non so quanto (in milioni), non vorrei nemmeno immaginarlo. Forse potremmo ottenere questo risultato: alle persone non piace ottimizzare in linguaggi di alto livello, o forse è più economico ottenere persone a cui piace ottimizzare in C / C ++ perché ce ne sono così tante (rispetto ad altri esperti di lingue che possono ottimizzare su un livello simile).

Sarebbe paragonabile al concetto nei giorni 9x di Windows di eseguire il software OpenGL contro OpenGL con accelerazione hardware. Il problema con l'utilizzo di Java per qualcosa come un browser Web è che potenzialmente si utilizzano molti cicli di clock extra per fare qualcosa che potrebbe essere possibile in molti meno in una lingua più nativa. Questo era il concetto anche con OpenGL: potevi completare l'operazione ma ci volle molto più elaborazione per farlo.

Quindi è possibile? Potenzialmente. Sarebbe competitivo? Improbabile: qualcosa nel codice altamente ottimizzato e dipendente dalla piattaforma avrà probabilmente un vantaggio di velocità significativo.

Questa è solo una speculazione.

Sulla fattibilità di un browser Web Java scritto in Java, forse è stata posta la domanda sbagliata.

Non vedo la necessità di reinventare la ruota e scrivere un browser completo quando la maggior parte di quelli esistenti sono gratuiti e ricchi di funzionalità.

Detto questo, ciò che io (noi?) Dovremmo cercare è "qualcosa" abbastanza buono da leggere pagine Web SENZA tutte le schifezze (ri-pubblicità, video, gif) su cui si accumulano.

Google è il principale trasgressore qui con tutti i suoi annunci e così via.

Per rispondere a ciò che ho scritto un browser Java che utilizza Java HTMLEditorKit con la sua implementazione HTML 3.2 e legge una pagina Web come testo, elimina tutto il codice javascript, il codice di stile, i collegamenti, i metadati (un'altra fonte di irritazione con la sua auto ricaricare) e tenta di correggere alcuni caratteri speciali e collegamenti immagine impostati tramite javascript. Collegamenti ipertestuali e navigazione. Per leggere cose come LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr offre. Persino Bing e le ricerche di Google arrivano. Alla fine o quando richiesto lo renderò disponibile gratuitamente. Non è molto ma è un inizio.

Sicuro che potrebbe essere fatto. E avrebbe anche senso. Nessun browser supporta gli standard w3c completi per motivi poco chiari. Da parte del supporto css3, le società di browser non supportano neanche gli standard. -moz- * e -webkit- * non faranno mai parte dello standard. Quindi un browser conforme agli standard completi dovrebbe ignorarli. Uno dei maggiori errori di w3c è la totale mancanza di specifiche di rendering. Quindi la stessa pagina web conforme agli standard apparirebbe diversa in ogni browser, un incubo grafico di design. Un altro errore del w3c è la mancanza di velocità. 5 anni di discussione e ancora solo una bozza di standard per html5? Quindi la tua organizzazione sta bloccando qualsiasi innovazione seria.

Penso che dovremmo ignorare W3C, ignorare le loro specifiche e creare uno standard della community entro un anno e mezzo per un linguaggio di markup per le applicazioni Web tenendo conto delle specifiche di rendering e della sicurezza. Ricorda che l'HTML non è mai stato progettato per le applicazioni web, perché non c'erano applicazioni web al momento in cui sgml veniva utilizzato come base per l'HTML.