Чистый Java веб-браузер, это практично? [закрыто]


29

Я знаю, что веб-браузер Java возможен, но практичен ли он? Я видел проект Lobo и должен признать, что я впечатлен, но из того, что я собрал, кажется, что разработка остановилась в 2009 году. Будет ли браузер, закодированный на чистой Java (никаких Java-привязок WebKit любого типа), конкурировать с те, кто входит в число Chrome или Firefox, или это будет медленнее, мешая пользователю?


5
Интересный вопрос, потому что веб-браузер под названием HotJava был ранним демонстрационным приложением на Java.
user16764

3
Это было не просто демонстрационное приложение, это была ключевая часть коммерческой стратегии Sun Java в конце 90-х - начале 2000-х, и они довольно активно продвигали ее партнерам. Добавьте в список странностей Java от Sun той же эпохи: JavaOS / JavaStation.
JustinC

3
Технически говоря, не будут ли Android-версии Opera, Chrome и FF написаны на Java? Не пробовал FF, но, учитывая приличное устройство, Chrome и Opera работают довольно хорошо.
TC1

2
@ TC1 Я думаю, что они написаны на C \ C ++ с Android Native Development Kit.
Уэсли Мудрый

Снова закрыто из-за нелогичных рассуждений. Таким образом, вы (SE) ожидаете, что только «эксперты» ответят? И как бы ответили эксперты сейчас, когда вы это закрыли? Разве на форуме сообщества никто не должен отвечать? Разве это не на сайте, чтобы сначала показывать ответы «вверх»? Плохие и отрицательные ответы могут быть скрыты или заархивированы правильно. Вы не должны быть такими самоуверенными и авторитетными.
killjoy

Ответы:


44

Язык программирования, скорее всего, не станет камнем преткновения. Обязательное управление памятью JVM может быть недостатком в некоторых критически важных для производительности частях (например, голод памяти; но тогда, GC Java мог бы на самом деле лучше предотвращать утечки памяти, чем все, что вы могли бы сделать самостоятельно), и есть несколько дополнительных проблем безопасности, но кроме этого, я не вижу очевидных шоу-пробок.

Тем не мение.

Веб-браузер в масштабах Firefox или Chromium - это серьезное мероприятие, и оба проекта имеют огромный опыт работы: Mozilla опирается на десятилетия создания браузеров (и некоторые известные провалы), а Chrome / Chromium используют Google и Apple. (основная сила в разработке WebKit), стоящая за ним и использовавшая много знаний и опыта из KDE и других крупных проектов с открытым исходным кодом. Оба также используют десятки проверенных в сражении библиотек, не только движков рендеринга, но и всевозможных вещей. Векторная графика, рендеринг шрифтов, синтаксический анализ, XML DOM Манипулирование деревом, работа в сети, кэширование, криптография, список можно продолжать и продолжать, и вы не хотите изобретать все эти колеса самостоятельно, потому что их сложно сделать и легко ошибиться ,

Короче говоря, создать мощный веб-браузер довольно сложно, и именно поэтому на этой арене лишь несколько историй успеха. Язык программирования имеет относительно мало общего с ним, хотя C и C ++ имеют преимущества как в техническом, так и в социальном отношении.


11

Теоретически это, несомненно, можно сделать. Однако с практической точки зрения это кажется немного более сомнительным. loboдаже близко не в первый раз, когда его пытались. Фактически, одним из ранних примеров превосходства Java должен был быть браузер HotJava, который собирался изменить мир и сделать браузеры «поколения мозаики» устаревшими .

Конечно, мы все знаем, что верно и обратное: HotJava мертва и никогда не была серьезным конкурентом в войнах браузеров (на самом деле, если вы ищете «HotJava browser», некоторые из лучших хитов - это сообщения об ошибках). о том, как это работает не совсем корректно, даже для собственных веб-приложений Sun).

Лично я думаю, что интересно, возможно ли это или практично (в основном) смотреть и думать в неправильном направлении. Вопрос не в том, несет ли Java такие огромные штрафы за непрактичность такого проекта. Вопрос в том, обладает ли Java достаточными преимуществами, чтобы оправдать такой проект.

Простой факт заключается в том, что webkit (на вашем примере) - это большой, сложный кусок кода. Даже если мы предположим, что Java настолько замечательнее, что мы могли бы сделать то же самое, скажем, с половиной размера и сложности, результатом все равно будет довольно большой и сложный кусок кода (аналогично V8 и т. Д.)

Я думаю, что прежде чем дублировать этот объем работы, большинство людей хотели бы получить немного больше уверенности, чем: «мы думаем, что наш продукт, скорее всего, будет достаточно конкурентоспособным».

Если вы начинаете с набора видимых пользователю функций для браузера, а затем пытаетесь определить наиболее эффективный способ создания браузера с этими функциями, «Java», вероятно, не будет частью этого ответа, кроме как как часть «» Javascript». Если история сложилась иначе, вероятно, нет причины, по которой она не могла бы (хотя бы теоретически) быть частью ответа, но, учитывая текущие обстоятельства, это не так.

Кроме того, я вижу очень небольшую вероятность этого изменения. Я едва вижу, как это произойдет, если Oracle (или, возможно, IBM) решит, что полезно поддерживать конкурентную позицию Java по сравнению с (для очевидного примера) Microsoft .NET, но это кажется сомнительным, если только .NET не станет угрожать основному рынку Java.

Помимо этого, любой набор функций, которые вы можете себе представить (за исключением «написанного на Pure Java» как самой функции), почти наверняка может быть достигнут быстрее и проще другими способами, чем при написании браузера полностью на Java.


1
Я почувствовал запах старых книг в моем носу при чтении этой ссылки на HotJava
MarioDS

2
Давайте также помним, что во времена HotJava Java была слабой с точки зрения доступных библиотек, опыта разработчиков и скорости (иногда замедление в 10-15 раз). Сегодня это совершенно противоположно в каждой области. Там даже процессоры Java в настоящее время (можно сказать Java - браузер тонкий клиент на процессоре Java? Подмигнуть) Я думаю HotJava не удалось платформа просто б / с Java не было достаточно хорошо тогда .
Ник П

5

Я искренне верю, что преданная, знающая команда могла бы создать эффективный веб-браузер на Java. Реальный вопрос, почему? Наличие браузера, написанного на определенном языке, на самом деле не особенность. Люди будут использовать Chrome, потому что он быстрый, или Firefox, потому что он расширяемый, но они не будут использовать JBrowser только потому, что он написан на Java. Таким образом, возникает реальный вопрос: какую проблему вы пытаетесь решить?

Следующий вопрос, предполагая, что у вас есть причина написать JBrowser: «Использование Java делает задачу проще или сложнее?» Google, создавая Chrome, писал его в основном на C / C ++, несмотря на то, что они очень про-Java-магазин. Кажется вполне вероятным, что они полагали, что преимущества Java не принесут чистого выигрыша вовремя.


2

С появлением Nashorn (Javascript на JVM, заменяющем Rhino) в JVM как часть Java 8, это в высшей степени выполнимо. Однако, как уже отмечали другие, современному веб-браузеру очень много, и встраивать WebKit, если вам нужно разместить возможности просмотра в приложении Java, просто :-).


1

Текущий топ-ответ отлично. Я добавлю, однако, что не нужно полностью перекодировать что-то в Java. Существуют инструменты, которые преобразуют исходный код в байт-коды Java с различной степенью совместимости. Они часто создают своего рода интерпретатор или используют JVM-подобное представление, такое как MIPS, в качестве трамплина. Можно разбить разработку Java-браузера на несколько этапов, преобразовав ключевые нативные библиотеки в байт-код Java, интегрировав их с чистым исходным кодом браузера Java и постепенно внедрив больше библиотечного кода в качестве чистого Java-источника.

Это позволяет вам содержать все в более безопасной JVM. Тем не менее, это будет боль в прикладе, обеспечивающем эффективность. Есть некоторый прецедент в постепенном рефакторинге больших унаследованных приложений, предшествующих Agile / OOP. Кроме того, некоторые компоненты уже имеют хорошие реализации Java, и их также можно использовать для сокращения трудозатрат.


0

Я должен сказать, что здесь я немного предвзят, но я иду. Мне не нравятся проповедники C / C ++, я знаю, что есть несколько невероятно хороших инженерных приложений, но это просто инструмент, часто у меня складывается впечатление, что многие люди упоминают только C / C ++ для решения, упускают больше, чем точку ( http://www.paulgraham.com/avg.html см. парадокс лампочки). Я пытаюсь взглянуть на факты: Java так же быстро работает на C / C ++, но требует больше памяти. Или позвольте мне перефразировать, вы можете написать код Java, который работает так же быстро, как C / C ++, но эта программа будет занимать больше памяти. Я надеюсь, что мы можем договориться об этом.

Если вы посмотрите на производительность, вы можете создать Java-решения для определенных проблем (скажем, Enterprise Java) относительно легко, по сравнению с C ++ решениями. Веб-браузер - это нечто совершенно другое. Я вижу два / три требования мэра:

  • Он должен соответствовать огромным спецификациям, HTML, JavaScript и т. Д. Это связано с такими проблемами, как API-интерфейсы 2D-рисования. Или как перейти от системного вызова ОС (в качестве примитива рисования) к представлению текста или шрифта («рендеринг»). Посмотрите на библиотеки, такие как Каир (C) и другие попытки, такие как gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
  • Он должен «чувствовать» себя свободно, что означает, что для выполнения определенных операций требуется только мс.
  • Он должен сформировать концепцию пользовательского интерфейса, которая формирует уникальный опыт, чтобы конкурировать в сегодняшних «войнах браузеров», что довольно сложно.

Подводя итог: да, вы могли бы создать браузеры практически на любом языке программирования с почти идентичными результатами по сравнению с современными пароходами C ++. Но для этого вам понадобится довольно много усилий. Я не знаю, сколько (в миллионах), я бы не хотел даже догадываться об этом. Может быть, мы могли бы подвести итоги: людям не нравится оптимизировать на языках высокого уровня, или может быть дешевле получить людей, которые любят оптимизировать на C / C ++, потому что их так много (по сравнению с другими языковыми экспертами, которые могут оптимизировать на аналогичный уровень).


2
Я испытываю желание понизить голосование, потому что вы не разбили свой ответ на несколько параграфов Пожалуйста, разбейте стену текста пробелами.
Гилберт Ле Блан

2
Ну, я пишу с мобильного телефона, и это лучшее, что я могу сделать с мобильным интерфейсом, извините
AndreasScheinert

1
Пошел к ноутбуку и починил.
AndreasScheinert

2
«Или позвольте мне перефразировать, вы можете написать код Java, который работает так же быстро, как C / C ++, но эта программа будет занимать больше памяти. Я надеюсь, что мы сможем договориться об этом». Нет, мы не можем, по крайней мере, не во всех случаях. Java не позволит вам реализовать несколько пользовательских менеджеров памяти для разных шаблонов распределения памяти. Вы не можете отключить проверку границ массива, когда решите, что в этом нет необходимости, просто нужно надеяться, что JIT распознает, когда это не нужно. Эти проблемы не возникают в большинстве программ, но они могут иметь решающее значение в приложениях, которые требуют каждую последнюю наносекунду производительности.
Чарльз Грант

1
Ваши повторяющиеся аргументы здесь о том, что сборка мусора влияет на производительность. Я согласен с этим. Но это всего лишь один аспект.
AndreasScheinert

0

Это было бы сравнимо с концепцией в Windows 9x дней запуска программного обеспечения OpenGL против аппаратно-ускоренного OpenGL. Проблема с использованием Java для чего-то вроде веб-браузера заключается в том, что вы потенциально можете использовать много дополнительных тактов, чтобы сделать что-то, что может быть возможно намного меньше на более родном языке. Такова была концепция и с OpenGL - вы могли выполнить задачу, но для ее выполнения потребовалось гораздо больше обработки.

Так возможно ли это? Потенциально. Будет ли это конкурентоспособным? Маловероятно - что-то в высокооптимизированном, зависимом от платформы коде, вероятно, будет иметь значительное преимущество в скорости.

Это всего лишь предположение, хотя.


-1

О возможности веб-браузера Java, написанного на Java, возможно, был задан неправильный вопрос.

Я не вижу необходимости заново изобретать колесо и писать полноценный браузер, когда большинство существующих бесплатных и многофункциональных.

Тем не менее, то, что я (мы?) Должен искать, это «что-то» достаточно хорошее, чтобы читать веб-страницы БЕЗ всего дерьма (повторная реклама, видео, GIF-файлы), которое накапливается.

Google - главный преступник здесь со всеми их объявлениями и тому подобным.

Чтобы решить эту проблему, я написал браузер Java, который использует Java HTMLEditorKit с его реализацией HTML 3.2 и считывает веб-страницу как текст, удаляет весь код JavaScript, код стиля, ссылки, метаданные (еще один источник раздражения с его авто перезагрузить) и пытается исправить некоторые специальные символы и ссылки на изображения, установленные с помощью JavaScript. Гиперссылки и навигационные работы. Для чтения таких материалов, как LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr, он предоставляет. Даже поиски Bing и Google проходят. В конце концов или когда меня спросят, я сделаю это бесплатно. Это не так много, но это начало.


-4

Конечно, это можно сделать. И это тоже имело бы смысл. Ни один браузер не поддерживает полные стандарты w3c по непонятным причинам. Со стороны поддержки css3 браузерные компании также не поддерживают стандарты. -moz- * и -webkit- * никогда не будут частью стандарта. Поэтому браузер, полностью соответствующий стандартам, должен их игнорировать. Одна из самых больших ошибок в w3c - полное отсутствие спецификаций рендеринга. Таким образом, одна и та же веб-страница, соответствующая стандартам, будет выглядеть по-разному в каждом браузере - кошмар графического дизайна. Еще один сбой w3c - отсутствие скорости. 5 лет обсуждения и все еще только проект стандарта для html5? Тогда ваша организация блокирует любые серьезные инновации.

Я думаю, что мы должны игнорировать w3c, игнорировать их спецификации и сделать стандарт сообщества в течение полугода для языка разметки веб-приложений с учетом спецификаций и безопасности. Помните, что HTML никогда не был предназначен для веб-приложений, потому что в то время не было никаких веб-приложений в качестве основы для HTML.


1
Если это сарказм, это не достаточно ясно. Вы также не указываете на неизбежные подводные камни с тем, что предлагаете. Если это не сарказм, тогда я настоятельно рекомендую вам изучить, как создаются стандарты.

Да, это сарказм, но английский не является моим родным языком, и нет, это не сарказм, так как стандарты, требующие 5+ лет для доставки только черновика, никогда не могут быть полностью использованы в качестве стандарта на практике.
Вики Роннен

не принадлежит здесь, и при этом это не обращается к вопросу. даже с сарказмом.
Scravy
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.