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

Я знаю, що веб-браузер Java можливий, але чи це практично? Я бачив проект Lobo і мушу визнати, що я вражений, але з того, що я зібрав, схоже, що розвиток зупинився в 2009 році. Чи зможе браузер, закодований у чистій Java (жодних прив’язків Java Java не будь-якого типу), зможе скласти конкуренцію тих, хто входить до лав Chrome або Firefox, чи це буде за своєю суттю повільніше, заважаючи користувачеві?

Мова програмування, швидше за все, не стане каменем спотикання. Обов'язкове управління пам'яттю JVM може бути недоліком у деяких важливих для продуктивності частинах (наприклад, голодування пам’яті; але тоді, GC Java може насправді краще запобігти витоку пам’яті, ніж все, що ви могли самостійно закатати), і є кілька додаткових проблем щодо безпеки, окрім цього, я не бачу очевидних пробників шоу.

Однак.

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

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

Теоретично це можна було, безперечно, зробити. Однак, з практичної точки зору, це здається дещо сумнівнішим. loboнавіть не близький до першого разу, коли його судили. Насправді, однією з перших вітрин переваги Java повинен був стати браузер HotJava - який мав змінити світ і заставити браузери "Покоління мозаїк" застарілими .

Звичайно, ми всі знаємо майже навпаки: HotJava мертвий і ніколи не був серйозним конкурентом у війнах за браузер (адже якщо ви шукаєте "браузер HotJava", деякі найкращі хіти - це повідомлення про помилки. про те, як це не працювало зовсім коректно, навіть для власних веб-додатків Sun).

Особисто мені здається, що цікаво, чи можливо це чи практично (в основному) дивитись і думати в неправильному напрямку. Питання полягає не в тому, чи Java несе такі масштабні штрафи за такий проект, що це недоцільно. Питання в тому, чи має у Java достатньо переваг для виправдання такого проекту.

Простий факт полягає в тому, що webkit (щоб використовувати ваш приклад) - це великий, складний фрагмент коду. Навіть якщо ми припустимо, що Java настільки прекрасніше, що ми могли б зробити те ж саме, скажімо, на половину розміру та складності, результат все- таки є досить великим, складним кодом (так само V8 тощо).

Думаю, перед тим, як дублювати цю кількість роботи, більшість людей хотіли б трохи більше впевненості, ніж: "ми думаємо, що наш продукт, ймовірно, буде досить конкурентоспроможним".

Якщо ви починаєте з набору видимих ​​для користувача функцій для браузера, а потім намагаєтеся визначити найефективніший спосіб створення браузера з цими функціями, "Java", ймовірно, не буде частиною цієї відповіді, за винятком частини " Javascript ". Якби історія склалася по-іншому, напевно, немає причин, щоб вона не могла бути (принаймні теоретично) частиною відповіді, але, враховуючи сучасні обставини, це не так.

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

Крім цього, будь-який набір функцій, який ви можете уявити (за винятком "написаного в чистому Яві" як особливості), майже напевно може бути досягнуто швидше та простіше іншими способами, ніж написання браузера повністю на Java.

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

Наступне питання, якщо припустити, що у вас є причина писати JBrowser, - це "використання Java полегшує чи важче завдання?" Google, створюючи Chrome, писав це головним чином на C / C ++, незважаючи на те, що вони дуже про-Java-магазин. Здається, цілком ймовірно, що вони вважали, що переваги Java не будуть приносити чистий прибуток вчасно.

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

Поточна відповідь є чудовою. Додам, що не потрібно повністю перекодувати щось на Java. Існують інструменти, які перетворюють нативне джерело в байт-коди Java з різним ступенем сумісності. Вони часто створюють своєрідний перекладач або використовують JVM-подібне представлення, таке як MIPS, як трамплін. Можна перервати розробку браузера Java на багато кроків, перетворивши основні бібліотеки в байт-код Java, інтегруючи їх з чистим джерелом браузера Java та поступово впроваджуючи більше бібліотечного коду як чистого джерела Java.

Це дозволяє містити все в безпечнішому JVM. Однак це буде біль в області задника, що забезпечує ефективність. Існує певний прецедент у поступовому рефакторингу великих, попередніх програм / OOP. Крім того, деякі компоненти вже мають гарну реалізацію Java, і їх можна використовувати також для зменшення затрат праці.

Треба сказати, що я тут трохи упереджений, але ось я йду. Мені не подобаються проповідники C / C ++, я знаю, що там є кілька неймовірних хороших інженерних програм, але це просто A Інструмент, часто я маю враження, що багато людей згадують лише C / C ++ за рішенням пропускають більше, ніж бал ( http://www.paulgraham.com/avg.html див. парадокс лампочки). Я намагаюся дивитись на факти: Java настільки ж швидкий C / C ++, але для цього потрібно більше пам'яті. Або дозвольте мені перефразовувати, що ви можете написати код Java, який настільки ж швидкий, як C / C ++, але ця програма буде споживати більше пам'яті. Я сподіваюся, що ми можемо з цим погодитися.

Якщо ви подивитеся на продуктивність, ви можете створити Java-рішення для певних проблем (скажімо, підприємство java) порівняно легко, порівняно з рішеннями C ++. Веб-браузер - це щось зовсім інше. Я бачу два / три вимоги мера:

• Він повинен відповідати величезним специфікаціям, HTML, JavaScript тощо. Це пов'язано з проблемами, такими як 2D API малювання. Або як перейти від системного виклику ОС (як примітивного малюнка) до подання тексту чи шрифту ("візуалізація"). Перегляньте такі бібліотеки, як cairo (C) та інші спроби на зразок gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Він повинен "відчувати себе вільно", що означає, що певні операції мають виконувати лише повідомлення.
• Він повинен сформувати Концепцію інтерфейсу користувача, яка створює унікальний досвід, щоб конкурувати в сучасних "війнах за браузер", що є досить складним завданням.

Підсумовуючи: так, ви могли, ви могли створити браузери практично на будь-якій мові програмування з майже однаковими результатами порівняно сьогоднішніх пароплавів C ++. Але для цього вам знадобиться досить надзвичайна кількість зусиль. Я не знаю, скільки (у мільйонах), я б не хотів навіть здогадуватися про це. Можливо, ми могли б отримати цей підсумок: людям не подобається оптимізувати мови високого рівня, або, можливо, дешевше - людям, які люблять оптимізувати C / C ++, тому що їх так багато (порівняно з іншими мовними експертами, які можуть оптимізувати аналогічний рівень).

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

Отже, чи можливо? Потенційно. Чи буде це конкурентоспроможним? Навряд чи - щось із високооптимізованим, залежним від платформи кодом, ймовірно, матиме значну перевагу у швидкості.

Це лише спекуляція.

Про доцільність веб-браузера Java, написаного на Java, можливо, було задано неправильне запитання.

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

Це говорить про те, що я (ми?) Мусимо шукати - це "щось" досить добре, щоб читати веб-сторінки БЕЗ усіх лайно (повторної реклами, відео, gifs), на яку потрапляють.

Google є головним правопорушником у всіх своїх рекламних оголошеннях тощо.

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

Звичайно, це можна зробити. І це теж мало б сенс. Жоден браузер не підтримує повних стандартів w3c з незрозумілих причин. З боку підтримки css3 браузерні компанії також не підтримують стандартів. -moz- * і -webkit- * ніколи не будуть частиною стандарту. Таким чином, повний стандарт, який відповідає стандартам, повинен їх ігнорувати. Однією з найбільших помилок w3c є повна відсутність специфікацій візуалізації. Тож однакові веб-сторінки, що відповідають стандартам, виглядали б різними у кожному браузері, кошмаром із графічним дизайном. Ще одна невдача w3c - це відсутність швидкості. 5 років обговорення та ще лише проект стандарту для html5? Тоді ваша організація блокує будь-які серйозні нововведення.

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