Wiem, że przeglądarka Java jest możliwa, ale czy jest praktyczna? Widziałem projekt Lobo i muszę przyznać, że jestem pod wrażeniem, ale z tego, co zebrałem, wydaje się, że rozwój zatrzymał się w 2009 roku. Czy przeglądarka zakodowana w czystej Javie (bez żadnych powiązań Java WebKit jakiegokolwiek typu) byłaby w stanie konkurować z w szeregach Chrome lub Firefox, czy też byłoby to z natury wolniejsze, utrudniające użytkownikowi?
29
Odpowiedzi:
Język programowania najprawdopodobniej nie będzie przeszkodą. Obowiązkowe zarządzanie pamięcią przez JVM może być wadą w niektórych częściach krytycznych pod względem wydajności (np. Głodu pamięci; ale wtedy GC Java może faktycznie lepiej zapobiegać wyciekom pamięci niż wszystko, co można samemu zwinąć), i istnieje kilka dodatkowych obaw związanych z bezpieczeństwem, ale poza tym nie widzę żadnych oczywistych ograniczeń.
Jednak.
Przeglądarka internetowa w skali Firefox lub Chromium to ogromne przedsięwzięcie, a oba projekty mają za sobą ogromne doświadczenie - Mozilla opiera się na dziesięcioleciach tworzenia przeglądarki (i niektórych znanych awarii), a Chrome / Chromium ma zarówno Google, jak i Apple (główna siła w rozwoju WebKit) za nią i pochłonęło wiele wiedzy i doświadczenia z KDE i innych dużych solidnych projektów Open Source. Obie wykorzystują dodatkowo dziesiątki sprawdzonych bibliotek, nie tylko renderowania silników, ale wszelkiego rodzaju rzeczy. Grafika wektorowa, renderowanie czcionek, parsowanie, manipulowanie drzewem XML DOM, tworzenie sieci, buforowanie, kryptografia, lista jest długa i długa, a ty nie chcesz na nowo wymyślać wszystkich tych kół, ponieważ są trudne do zrobienia i łatwo się pomylić .
Krótko mówiąc, zbudowanie silnej w branży przeglądarki internetowej jest cholernie trudne i to jest powód, istnieje tylko kilka sukcesów w tej dziedzinie. Język programowania ma stosunkowo niewiele wspólnego z nim, chociaż C i C ++ mają przewagę, zarówno techniczną, jak i społeczną.
źródło
Teoretycznie można to bez wątpienia zrobić. Jednak z praktycznego punktu widzenia wydaje się to nieco bardziej wątpliwe.
lobo
nie jest nawet blisko pierwszego użycia. W rzeczywistości jedną z pierwszych prezentacji wyższości Javy była przeglądarka HotJava, która miała zmienić świat i sprawić, że przeglądarki „generacji mozaiki” stały się przestarzałe .Oczywiście wszyscy wiemy, że jest wręcz odwrotnie: HotJava nie żyje i nigdy nie był tak naprawdę poważnym konkurentem w wojnach przeglądarkowych (w rzeczywistości, jeśli wyszukujesz „przeglądarkę HotJava”, niektóre z największych hitów dotyczą zgłoszeń błędów o tym, jak to nie działało całkiem poprawnie, nawet w przypadku własnych aplikacji internetowych Sun).
Osobiście myślę, że zastanawianie się nad tym, czy jest to możliwe czy praktyczne, to (głównie) patrzenie i myślenie w złym kierunku. Pytanie brzmi nie tego, czy Java nakłada tak ogromne kary, aby taki projekt był niepraktyczny. Pytanie brzmi, czy Java ma wystarczające zalety, aby uzasadnić taki projekt.
Prostym faktem jest to, że webkit (na przykład) jest dużym, złożonym fragmentem kodu. Nawet jeśli założymy, że Java jest o wiele wspanialsza, że moglibyśmy zrobić to samo z, powiedzmy, połową wielkości i złożoności, wynik nadal dość duży, złożony fragment kodu (podobnie V8 itp.)
Myślę, że zanim powielę tę ilość pracy, większość ludzi będzie chciała nieco więcej pewności niż: „uważamy, że nasz produkt może być dość konkurencyjny”.
Jeśli zaczniesz od zestawu widocznych dla użytkownika funkcji przeglądarki, a następnie spróbujesz określić najbardziej efektywny sposób na stworzenie przeglądarki z tymi funkcjami, „Java” prawdopodobnie nie będzie częścią tej odpowiedzi, z wyjątkiem części „ JavaScript ”. Gdyby historia potoczyła się inaczej, prawdopodobnie nie ma powodu, by nie mogła (przynajmniej teoretycznie) być częścią odpowiedzi, ale biorąc pod uwagę obecne okoliczności, nie jest.
Co więcej, widzę bardzo małe prawdopodobieństwo takiej zmiany. Ledwo widzę, że tak się dzieje, jeśli Oracle (lub ewentualnie IBM) zdecyduje, że użyteczne byłoby utrzymanie konkurencyjnej pozycji Javy w stosunku do (na oczywisty przykład) Microsoft .NET, ale wydaje się to wątpliwe, chyba że .NET zacznie zagrażać kluczowemu rynkowi Javy.
Poza tym każdy zestaw funkcji, które możesz sobie wyobrazić (poza „napisanym w Pure Java” jako cechą samą w sobie) można prawie na pewno osiągnąć szybciej i łatwiej na inne sposoby niż przez napisanie przeglądarki całkowicie w Javie.
źródło
Szczerze wierzę, że oddany, kompetentny zespół mógłby stworzyć wydajną przeglądarkę internetową w Javie. Prawdziwe pytanie brzmi: dlaczego? Posiadanie przeglądarki w określonym języku nie jest tak naprawdę funkcją. Ludzie będą używać Chrome, ponieważ jest szybki lub Firefox, ponieważ jest rozszerzalny, ale nie będą używać JBrowser tylko dlatego, że jest napisany w Javie. Tak więc prawdziwe pytanie brzmi: jaki problem próbujesz rozwiązać?
Następnym pytaniem, zakładając, że masz powód, aby napisać JBrowser, jest: „czy używanie Java czyni zadanie łatwiejszym lub trudniejszym?” Google, tworząc Chrome, napisał go przede wszystkim w C / C ++, mimo że jest to bardzo pro-Java sklep. Wydaje się całkiem prawdopodobne, że wierzyli, że korzyści płynące z Javy nie przyniosą zysku netto na czas.
źródło
Ponieważ Nashorn (JavaScript w JVM zastępuje Rhino) przybywa do JVM jako część Java 8, jest to wyjątkowo wykonalne. Jednak, jak zauważyli inni - nowoczesna przeglądarka internetowa ma bardzo dużo zalet i WebKit wydaje się łatwiejszy, jeśli potrzebujesz hostować możliwości przeglądania w aplikacji Java :-).
źródło
Obecna najwyższa odpowiedź jest doskonała. Dodam jednak, że nie trzeba całkowicie przekodowywać czegoś do Javy. Istnieją narzędzia, które konwertują natywne źródła na kody bajtowe Java o różnym stopniu interoperacyjności. Często tworzą swego rodzaju tłumacza lub używają reprezentacji podobnej do JVM, takiej jak MIPS, jako odskocznia. Można podzielić rozwój przeglądarki Java na wiele etapów, przekształcając kluczowe biblioteki natywne w kod bajtowy Java, integrując je z czystym źródłem przeglądarki Java i stopniowo wdrażając więcej kodu biblioteki jako czystego źródła Java.
Dzięki temu możesz przechowywać wszystko w bezpieczniejszej JVM. Będzie to jednak ból w tyłek zapewniający wydajność. Jest pewien precedens w stopniowym refaktoryzowaniu dużych, wcześniejszych / zwinniejszych aplikacji OOP. Ponadto niektóre komponenty mają już dobre implementacje Java, a te mogą być również wykorzystane do zmniejszenia robocizny.
źródło
Muszę powiedzieć, że jestem tu trochę stronniczy, ale proszę bardzo. Nie lubię kaznodziejów C / C ++, wiem, że jest tam kilka niesamowicie dobrze zaprojektowanych aplikacji, ale jest to po prostu narzędzie, często mam wrażenie, że wiele osób mówi tylko o C / C ++ dla rozwiązania, które brakuje więcej niż punktu ( http://www.paulgraham.com/avg.html patrz paradoks żarówki). Próbuję spojrzeć na fakty: Java jest równie szybka w C / C ++, ale wymaga więcej pamięci. Albo pozwólcie, że sformułuję inaczej, możesz napisać kod Java, który jest tak szybki jak C / C ++, ale ten program zużywa więcej pamięci. Mam nadzieję, że możemy się z tym zgodzić.
Jeśli spojrzysz na wydajność, możesz stworzyć rozwiązania Java dla niektórych problemów (powiedzmy Java Enterprise) stosunkowo łatwo, w porównaniu do rozwiązań C ++. Przeglądarka internetowa to coś zupełnie innego. Widzę dwa / trzy wymagania burmistrza:
Podsumowując: tak, możesz tworzyć przeglądarki w prawie każdym języku programowania z prawie identycznymi wynikami w porównaniu z dzisiejszymi statkami parowymi C ++. Ale aby to zrobić, będziesz potrzebować niezwykłego wysiłku. Nie wiem ile (w milionach), nie chciałbym nawet zgadywać. Być może moglibyśmy uzyskać następujący wynik: ludzie nie lubią optymalizować w językach wysokiego poziomu, a może taniej jest zdobyć osoby, które lubią optymalizować w C / C ++, ponieważ jest ich tak wiele (w porównaniu do innych ekspertów językowych, którzy mogą optymalizować na podobny poziom).
źródło
Byłoby to porównywalne z koncepcją Windows 9x dni uruchamiania oprogramowania OpenGL w porównaniu z akcelerowanym sprzętowo OpenGL. Problem z używaniem Javy do czegoś takiego jak przeglądarka internetowa polega na tym, że potencjalnie używasz wielu dodatkowych cykli zegara, aby zrobić coś, co może być możliwe o wiele mniej w bardziej rodzimym języku. Taka była też koncepcja OpenGL - można było wykonać zadanie, ale wykonanie tego wymagało znacznie więcej przetwarzania.
Czy to możliwe? Potencjalnie Czy byłoby konkurencyjne? Mało prawdopodobne - coś w wysoce zoptymalizowanym, zależnym od platformy kodzie prawdopodobnie będzie miało znaczącą przewagę szybkości.
To jednak tylko spekulacja.
źródło
Jeśli chodzi o wykonalność przeglądarki Java napisanej w Javie, może zadano niewłaściwe pytanie.
Nie widzę potrzeby, aby od nowa wymyślać koło i pisać pełnoprawną przeglądarkę, gdy większość istniejących jest darmowa i ma bogate funkcje.
To powiedziawszy, czego powinienem (my?) Szukać, to „coś” wystarczająco dobrego, aby czytać strony internetowe BEZ wszystkich bzdur (ponownych reklam, filmów, gifów), które się nakładają.
Google jest tutaj głównym przestępcą ze wszystkimi ich reklamami i tym podobne.
Aby rozwiązać ten problem, napisałem przeglądarkę Java, która używa Java HTMLEditorKit z implementacją HTML 3.2 i czyta stronę internetową jako tekst, usuwa cały kod javascript, kod stylu, linki, metadane (inne źródło irytacji z jego auto reload) i próbuje naprawić niektóre znaki specjalne i linki do obrazów ustawione za pomocą skryptów javascript. Hiperłącza i nawigacja. Do czytania takich rzeczy jak LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr, które dostarcza. Przychodzą nawet wyszukiwania Bing i Google. W końcu lub na prośbę udostępnię go za darmo. To niewiele, ale to początek.
źródło
Pewnie, że da się to zrobić. I to też miałoby sens. Żadna przeglądarka nie obsługuje pełnych standardów w3c z niejasnych powodów. Ze strony obsługi css3 firmy przeglądające również nie obsługują standardów. -moz- * i -webkit- * nigdy nie będą częścią standardu. Dlatego przeglądarka zgodna ze standardami powinna je zignorować. Jednym z największych błędów w3c jest całkowity brak specyfikacji renderowania. Tak więc strona internetowa zgodna z tymi samymi standardami wyglądałaby inaczej w każdej przeglądarce, koszmar projektowania graficznego. Innym błędem w3c jest brak prędkości. 5 lat dyskusji i wciąż tylko projekt standardu dla HTML5? Twoja organizacja blokuje wszelkie poważne innowacje.
Myślę, że powinniśmy zignorować w3c, zignorować ich specyfikacje i w ciągu pół roku ustanowić standard społecznościowy dla języka znaczników aplikacji WWW Z renderowaniem specyfikacji i bezpieczeństwa. Pamiętaj, że HTML nigdy nie został zaprojektowany dla aplikacji internetowych, ponieważ nie było żadnych aplikacji internetowych w momencie, gdy sgml był używany jako podstawa dla HTML.
źródło