So che un browser Java è possibile, ma è pratico? Ho visto il progetto Lobo e devo ammettere che sono impressionato, ma da quello che ho raccolto sembra che lo sviluppo sia cessato nel 2009. Sarebbe un browser codificato in puro Java (nessun binding java WebKit di qualsiasi tipo) essere in grado di competere con quelli tra i ranghi di Chrome o Firefox, o sarebbe intrinsecamente più lento, ostacolando l'utente?
Il linguaggio di programmazione è, molto probabilmente, non un ostacolo. La gestione obbligatoria della memoria della JVM può essere uno svantaggio in alcune parti critiche per le prestazioni (ad esempio la fame di memoria, ma il GC di Java potrebbe effettivamente essere migliore nel prevenire perdite di memoria rispetto a qualsiasi cosa tu possa rotolare), e ci sono alcuni problemi di sicurezza aggiuntivi, ma a parte questo, non vedo alcun fermo show evidente.
Comunque.
Un browser web sulla scala di Firefox o Chromium è un'impresa massiccia ed entrambi i progetti hanno una grande esperienza dietro di loro - Mozilla si basa su decenni di creazione di browser (e su alcuni famosi fallimenti) e Chrome / Chromium ha alle spalle sia Google sia Apple (una forza importante nello sviluppo di WebKit) e ha assorbito molte conoscenze ed esperienze da KDE e altri grandi progetti Open Source solidi. Entrambi utilizzano inoltre dozzine di librerie collaudate, non solo i motori di rendering, ma ogni sorta di cose. Grafica vettoriale, rendering dei font, analisi, manipolazione XML DOM Tree, networking, caching, 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 è abbastanza dannatamente difficile, e questo è il motivo per cui ci sono solo una manciata di storie di successo in questa arena. Il linguaggio di programmazione ha relativamente poco a che fare con esso, sebbene C e C ++ siano avvantaggiati, sia dal punto di vista tecnico che sociale.
In teoria, potrebbe indubbiamente essere fatto. Da un punto di vista pratico, tuttavia, sembra un po 'più discutibile. lobo non è nemmeno vicino alla prima volta che è stato provato. In effetti, una delle prime vetrine della superiorità di Java doveva essere il browser HotJava - che stava per cambiare il mondo, e renderà obsoleti i browser di" Generazione mosaico ".
Naturalmente, sappiamo tutti che è vero il contrario: HotJava è morto , e non è mai stato un serio concorrente nelle guerre dei browser (infatti, se si cerca "HotJava browser", alcuni dei migliori successi sono per segnalazioni di bug su come non ha funzionato abbastanza correttamente , anche per le app Web di Sun.
Personalmente, penso che chiedermi se è possibile o pratico è (soprattutto) guardare e pensare nella direzione sbagliata. La domanda è non se Java comporta pene così massicce per un progetto di questo tipo da risultare poco pratico. La domanda è se Java abbia sufficienti vantaggi per giustificare un tale progetto.
Il semplice fatto è che il webkit (per usare il tuo esempio) è un pezzo di codice grande e complesso. Anche supponendo che Java sia tanto più meraviglioso che potremmo fare lo stesso con, ad esempio, metà delle dimensioni e della complessità, il risultato è ancora un pezzo di codice piuttosto grande e complesso (allo stesso modo V8, ecc.)
Penso che prima di duplicare quella quantità di lavoro, la maggior parte delle persone vorrebbe un po 'più di sicurezza che: "pensiamo che il nostro prodotto sia probabilmente abbastanza competitivo."
Se si avvia da una serie di funzionalità visibili all'utente per un browser e si tenta di determinare il modo più efficiente per produrre un browser con tali caratteristiche, "Java" probabilmente non farà parte di tale risposta, tranne che come parte di "Javascript". Se la storia ha funzionato in modo diverso, probabilmente non c'è motivo per cui non potrebbe (almeno teoricamente) essere parte della risposta, ma date le circostanze attuali, non lo è.
Inoltre, vedo pochissime probabilità che questo cambiamento. Riesco a malapena a vederlo accadere se Oracle (o forse IBM) ha deciso che è 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. p>
Al di fuori di questo, qualsiasi insieme di funzionalità che si possano immaginare (al di fuori di "scritto in Pure Java" come funzionalità in sé) può quasi sicuramente essere realizzato in modo più rapido e semplice in altri modi rispetto alla scrittura di un browser interamente in Java.
Credo onestamente 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é è scritto in Java. Quindi la vera domanda diventa, che problema stai cercando di risolvere?
La prossima domanda, supponendo che tu abbia un motivo per scrivere JBrowser è, "l'uso di Java rende l'attività più facile o più difficile?" Google, quando creava Chrome, lo scriveva principalmente in C / C ++ nonostante fossero un negozio molto pro-Java. Sembra abbastanza probabile che credessero che i benefici di Java non avrebbero portato un guadagno netto in tempo.
Con Nashorn (il Javascript sulla JVM che sostituisce Rhino) arrivando alla JVM come parte di Java 8, questo è eminentemente fattibile. Tuttavia, come altri hanno notato, c'è un sacco di cose da fare per un browser web moderno e sembra proprio più semplice incorporare WebKit se hai bisogno di ospitare le funzionalità di navigazione all'interno di un'app Java: -).
L'attuale risposta migliore è eccellente. Aggiungerò, tuttavia, che non è necessario ricodificare completamente qualcosa in Java. Esistono strumenti che convertono codice sorgente nativo in bytecode Java con vari gradi di interoperabilità. Spesso creano un interprete di sorta o usano una rappresentazione simile a JVM come MIPS come trampolino di lancio. Si potrebbe interrompere lo sviluppo di un browser Java in molti passaggi convertendo le librerie native chiave nel bytecode Java, integrandole con la pura sorgente del browser Java e implementando gradualmente più codice di libreria come pura sorgente Java.
Ciò consente di contenere tutto all'interno della JVM più sicura. Tuttavia, sarà un dolore al culo garantendo efficienza. Ci sono alcuni precedenti nel refactoring graduale di applicazioni legacy di grandi dimensioni, pre-Agile / OOP. Inoltre, alcuni componenti hanno già buone implementazioni Java e anche quelli potrebbero essere utilizzati per ridurre il lavoro.
Devo dire che sono un po 'di parte qui, ma ci vado. Non mi piacciono i predicatori di C / C ++, so che ci sono alcune incredibili applicazioni ben progettate, ma è solo uno strumento, spesso ho avuto l'impressione, molte persone menzionano solo C / C ++ per una soluzione che manca più di un punto ( http://www.paulgraham.com/avg.html vedi il paradosso della lampadina). Provo a guardare i fatti: Java è veloce quanto C / C ++ ma richiede quindi più memoria. Oppure fammi 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 aziendale) relativamente facili, rispetto alle soluzioni C ++. Un browser Web è qualcosa di completamente diverso. Vedo due / tre requisiti principali:
Per riassumere: sì, si potrebbe, è possibile creare i browser in quasi tutti i linguaggi di programmazione con risultati quasi identici rispetto alle attuali navi a vapore C ++. Ma per farlo, ti occorrerebbe una quantità straordinaria di sforzi. Non so quanto (in milioni), non vorrei nemmeno indovinare. Forse potremmo ottenere questo risultato: le persone non amano ottimizzare nei linguaggi di alto livello, o forse è più economico ottenere persone che amano ottimizzare in C / C ++ perché ce ne sono così tante (rispetto agli altri esperti linguistici che possono ottimizzare su un livello simile).
Sarebbe paragonabile al concetto in Windows 9x giorni di software in esecuzione OpenGL vs OpenGL con accelerazione hardware. Il problema con l'utilizzo di Java per qualcosa come un browser web è che potenzialmente usi molti cicli di clock aggiuntivi per fare qualcosa che potrebbe essere possibile in molti meno in una lingua più nativa. Anche questo era il concetto di OpenGL: potresti completare l'operazione, ma per eseguirla è stata necessaria molta più elaborazione.
Quindi, è possibile? Potenzialmente. Sarebbe competitivo? Improbabile: è probabile che qualcosa in un codice altamente ottimizzato e dipendente dalla piattaforma abbia un significativo vantaggio in termini di velocità.
Questo è puramente speculazione.
Informazioni sulla fattibilità di un browser Java scritto in Java, forse è stata posta la domanda sbagliata.
Non vedo la necessità di re-inventare la ruota e scrivere un browser a tutti gli effetti quando la maggior parte di quelli esistenti sono gratuiti e ricchi di funzionalità.
Questo ha detto che quello che io (noi?) dovremmo cercare è "qualcosa" abbastanza buono per leggere le pagine web SENZA tutte le schifezze (pubblicità, video, gif) che vengono ammucchiate.
Google è il principale autore di reati qui con tutti i suoi annunci e così.
Per indirizzo ho scritto un browser Java che utilizza Java HTMLEditorKit con la sua implementazione HTML 3.2 e legge una pagina web come testo, spoglia tutto il codice javascript, il codice di stile, i link, i meta dati (un'altra fonte di irritazione con la sua ricarica automatica) e tenta di correggere alcuni caratteri speciali e collegamenti immagine impostati tramite javascript. Collegamenti ipertestuali e navigazione. Per la lettura di cose come il LA Times, il NY Times, Il Corriere.it, ElPais.es, LeMonde.fr offre. Persino le ricerche di Bing e Google. Alla fine o quando richiesto lo renderò disponibile gratuitamente. Non è molto ma è un inizio.
Certo che potrebbe essere fatto. E avrebbe anche un senso. Nessun browser supporta gli standard W3C per motivi non chiari. Da parte del supporto css3, anche le compagnie browser non supportano gli standard. -moz- * e -webkit- * non faranno mai parte dello standard. Quindi un browser conforme agli standard dovrebbe ignorarli. Uno dei più grandi errori di w3c è la totale mancanza di specifiche di rendering. Quindi la stessa pagina web conforme agli standard sarebbe diversa in ogni browser, un incubo di design grafico. Un altro errore di w3c è la mancanza di velocità. Discussione di 5 anni 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 fare uno standard di comunità entro un anno e mezzo per un linguaggio di marcatura delle applicazioni Web con il rendering di specifiche e sicurezza in mente. Ricorda che HTML non è mai stato progettato per le applicazioni Web, perché non esistevano applicazioni Web al momento in cui veniva utilizzato SGML come base per HTML.