Peramban web Java murni, apakah praktis? [Tutup]

Saya tahu bahwa browser web Java dimungkinkan, tetapi apakah ini praktis? Saya telah melihat proyek Lobo dan harus mengakui bahwa saya terkesan, tetapi dari apa yang telah saya kumpulkan tampaknya bahwa pembangunan berhenti pada tahun 2009. Apakah browser dikodekan dalam Java murni (tidak ada binding java WebKit dari jenis apa pun) dapat bersaing dengan mereka yang berada di antara barisan Chrome atau Firefox, atau apakah itu secara inheren lebih lambat, menghalangi pengguna?

Bahasa pemrograman, kemungkinan besar, tidak akan menjadi batu sandungan. Manajemen memori wajib JVM mungkin menjadi kerugian di beberapa bagian yang kritis terhadap kinerja (mis. Kelaparan memori; tetapi kemudian, Java GC mungkin sebenarnya lebih baik dalam mencegah kebocoran memori daripada apa pun yang dapat Anda lakukan sendiri), dan ada beberapa masalah keamanan tambahan, tapi selain itu, saya tidak melihat penghenti pertunjukan yang jelas.

Namun.

Peramban web dengan skala Firefox atau Chromium adalah pekerjaan besar , dan kedua proyek memiliki pengalaman besar di belakangnya - Mozilla dibangun berdasarkan dekade pembangunan peramban (dan beberapa kegagalan terkenal), dan Chrome / Chromium memiliki Google dan Apple (kekuatan utama dalam pengembangan WebKit) di belakangnya dan menyerap banyak pengetahuan dan pengalaman dari KDE dan proyek Open Source besar lainnya. Keduanya juga menggunakan puluhan perpustakaan yang terbukti pertempuran, tidak hanya membuat mesin, tetapi segala macam hal. Grafik vektor, render font, parsing, manipulasi XML DOM Tree, jaringan, caching, kriptografi, daftarnya terus-menerus, dan Anda tidak ingin menemukan kembali semua roda itu sendiri, karena sulit dilakukan dan mudah salah .

Singkatnya, membangun browser web kekuatan industri sangat sulit, dan itulah sebabnya hanya ada beberapa kisah sukses di arena ini. Bahasa pemrograman relatif tidak ada hubungannya dengan hal itu, meskipun C dan C ++ lebih diuntungkan, baik secara teknis maupun sosial.

Secara teori, itu pasti bisa dilakukan. Dari sudut pandang praktis, tampaknya sedikit lebih dipertanyakan. lobobahkan tidak mendekati pertama kali dicoba. Faktanya, salah satu pameran awal tentang keunggulan Jawa seharusnya adalah peramban HotJava - yang akan mengubah dunia, dan menjadikan peramban "generasi Mosaik" menjadi usang .

Tentu saja, kita semua tahu yang sebaliknya adalah benar: HotJava sudah mati , dan tidak pernah benar-benar pesaing serius dalam perang browser (pada kenyataannya, jika Anda mencari "browser HotJava", beberapa hit top adalah untuk laporan bug tentang bagaimana itu tidak bekerja dengan benar, bahkan untuk aplikasi web Sun sendiri).

Secara pribadi, saya pikir bertanya-tanya apakah itu mungkin atau praktis (kebanyakan) melihat dan berpikir ke arah yang salah. Pertanyaannya bukan apakah Jawa membawa hukuman yang sedemikian besar untuk proyek semacam itu menjadi tidak praktis. Pertanyaannya adalah apakah Java memiliki cukup kelebihan untuk membenarkan proyek semacam itu.

Fakta sederhananya adalah bahwa webkit (untuk menggunakan contoh Anda) adalah bagian kode yang besar dan kompleks. Bahkan jika kita berasumsi bahwa Java jauh lebih hebat sehingga kita dapat melakukan hal yang sama dengan, katakanlah, setengah dari ukuran dan kompleksitas, hasilnya masih berupa potongan kode yang cukup besar dan rumit (demikian juga V8, dll.)

Saya pikir sebelum menduplikasi jumlah pekerjaan itu, kebanyakan orang menginginkan sedikit lebih banyak jaminan daripada: "kami pikir produk kami kemungkinan akan cukup kompetitif."

Jika Anda mulai dari serangkaian fitur yang terlihat oleh pengguna untuk browser, dan kemudian mencoba menentukan cara paling efisien untuk menghasilkan browser dengan fitur-fitur itu, "Java" mungkin tidak akan menjadi bagian dari jawaban itu, kecuali sebagai bagian dari " Javascript ". Jika sejarah berjalan dengan cara yang berbeda, mungkin tidak ada alasan mengapa itu tidak bisa (setidaknya secara teoritis) menjadi bagian dari jawaban, tetapi mengingat keadaan saat ini, itu tidak terjadi.

Lebih jauh, saya melihat sangat sedikit kemungkinan perubahan itu. Saya hampir tidak bisa melihat itu terjadi jika Oracle (atau mungkin IBM) memutuskan itu berguna untuk mempertahankan sikap kompetitif Java vs (untuk contoh yang jelas) Microsoft .NET, tetapi itu tampaknya diragukan kecuali. NET mulai mengancam pasar inti Jawa.

Di luar itu, setiap rangkaian fitur yang dapat Anda bayangkan (di luar "ditulis dalam Java Murni" sebagai fitur itu sendiri) hampir pasti dapat dicapai lebih cepat dan lebih mudah dengan cara lain daripada dengan menulis browser sepenuhnya di Jawa.

Jujur saya percaya bahwa tim yang berdedikasi dan berpengetahuan luas dapat membuat browser web berkinerja di Jawa. Pertanyaan sebenarnya adalah, mengapa? Memiliki peramban yang ditulis dalam bahasa tertentu sebenarnya bukan fitur. Orang-orang akan menggunakan Chrome karena itu cepat atau Firefox karena itu dapat diperluas, tetapi mereka tidak akan menggunakan JBrowser hanya karena kebetulan ditulis di Jawa. Jadi pertanyaan sebenarnya menjadi, masalah apa yang Anda coba selesaikan?

Pertanyaan selanjutnya, dengan asumsi Anda memiliki alasan untuk menulis JBrowser adalah, "apakah menggunakan Java membuat tugas lebih mudah atau lebih sulit?" Google, ketika membuat Chrome, menulisnya terutama dalam C / C ++ terlepas dari kenyataan bahwa mereka adalah toko yang sangat pro-Jawa. Tampaknya sangat mungkin bahwa mereka percaya bahwa manfaat Jawa tidak akan mendatangkan keuntungan bersih tepat waktu.

Dengan Nashorn (Javascript pada JVM menggantikan Badak) datang ke JVM sebagai bagian dari Java 8, ini sangat bisa dilakukan. Namun, seperti yang telah dicatat oleh orang lain - ada banyak sekali browser web modern dan itu sepertinya lebih mudah untuk menanamkan WebKit jika Anda perlu meng-host kemampuan browsing dalam aplikasi Java :-).

Jawaban teratas saat ini sangat bagus. Saya akan menambahkan, bahwa seseorang tidak perlu sepenuhnya recode sesuatu ke Jawa. Ada alat yang mengubah sumber asli ke bytecode Java dengan berbagai tingkat interoperabilitas. Mereka sering membuat semacam juru bahasa atau menggunakan representasi seperti JVM seperti MIPS sebagai batu loncatan. Orang mungkin memecah pengembangan browser Java menjadi banyak langkah dengan mengubah pustaka kunci utama menjadi bytecode Java, mengintegrasikannya dengan sumber browser Java murni, dan secara bertahap menerapkan lebih banyak kode perpustakaan sebagai sumber Java murni.

Ini memungkinkan Anda untuk memuat semuanya dalam JVM yang lebih aman. Namun, ini akan menjadi masalah dalam memastikan efisiensi. Ada beberapa preseden dalam secara bertahap refactoring aplikasi warisan besar, pra-Agile / OOP. Plus, beberapa komponen sudah memiliki implementasi Java yang baik dan itu bisa digunakan juga untuk mengurangi tenaga kerja.

Saya harus mengatakan saya sedikit bias di sini, tapi di sini saya pergi. Saya tidak suka pengkhotbah C / C ++, saya tahu ada beberapa aplikasi rekayasa luar biasa yang bagus di luar sana tapi itu hanya alat, sering saya mendapat kesan, banyak orang hanya menyebut C / C ++ untuk solusi lebih dari titik A ( http://www.paulgraham.com/avg.html lihat paradoks bulb). Saya mencoba untuk melihat fakta: Java secepat C / C ++ tetapi membutuhkan lebih banyak memori karenanya. Atau izinkan saya ulangi Anda dapat menulis kode java yang secepat C / C ++ tetapi program itu akan mengkonsumsi lebih banyak memori. Saya harap kita bisa menyetujui ini.

Jika Anda melihat produktivitas, Anda dapat membuat solusi java untuk masalah tertentu (katakanlah enterprise java) relatif mudah, dibandingkan dengan solusi C ++. Peramban web adalah sesuatu yang sangat berbeda. Saya melihat dua / tiga persyaratan walikota:

• Itu harus sesuai dengan spesifikasi besar, HTML, JavaScript, dll. Ini melibatkan masalah seperti 2D Drawing APIs. Atau bagaimana mendapatkan panggilan sistem OS (sebagai primitif gambar) ke representasi teks atau font ("rendering"). Lihatlah perpustakaan seperti cairo (C) dan upaya lain seperti gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Itu harus "merasa" lancar, yang berarti operasi tertentu hanya memiliki ms untuk dieksekusi.
• Itu harus membentuk Konsep UI yang membentuk pengalaman unik, untuk bersaing dalam 'perang browser' hari ini yang cukup menantang.

Singkatnya: ya Anda bisa, Anda bisa membuat browser di hampir semua bahasa pemrograman dengan hasil yang hampir sama dibandingkan kapal uap C ++ hari ini. Tetapi untuk melakukannya Anda akan membutuhkan usaha yang luar biasa. Saya tidak tahu berapa banyak (dalam jutaan), saya tidak ingin menebaknya. Mungkin kita bisa mendapatkan garis bawah ini: orang tidak suka mengoptimalkan dalam bahasa tingkat tinggi, atau mungkin lebih murah untuk membuat orang yang suka mengoptimalkan dalam C / C ++ karena ada begitu banyak (dibandingkan dengan ahli bahasa lain yang dapat mengoptimalkan pada tingkat yang sama).

Ini akan sebanding dengan konsep pada Windows 9x hari menjalankan perangkat lunak OpenGL vs OpenGL yang dipercepat perangkat keras. Masalah dengan menggunakan Java untuk sesuatu seperti browser web adalah bahwa Anda berpotensi menggunakan banyak siklus-jam ekstra untuk melakukan sesuatu yang mungkin dilakukan dalam jumlah yang lebih sedikit dalam bahasa yang lebih asli. Itu adalah konsep dengan OpenGL juga - Anda bisa menyelesaikan tugas tetapi butuh lebih banyak pemrosesan untuk melakukannya.

Jadi, apakah mungkin? Berpotensi. Apakah akan kompetitif? Tidak mungkin - sesuatu dalam kode yang sangat dioptimalkan dan tergantung pada platform kemungkinan akan memiliki keunggulan kecepatan yang signifikan.

Ini hanyalah spekulasi.

Tentang kelayakan browser web Java yang ditulis dalam Java, mungkin pertanyaan yang salah diajukan.

Saya melihat tidak perlu menemukan kembali roda dan menulis browser yang lengkap ketika sebagian besar yang ada adalah gratis dan kaya fitur.

Yang mengatakan apa yang saya (kita?) Harus cari adalah "sesuatu" yang cukup baik untuk membaca halaman web TANPA semua omong kosong (ulang iklan, video, gif) yang ditumpuk.

Google adalah pelaku utama di sini dengan semua iklan mereka dan semacamnya.

Untuk mengalaminya saya menulis peramban Java yang menggunakan Java HTMLEditorKit dengan implementasi HTML 3.2 dan membaca halaman web sebagai teks, menghapus semua kode javascript, kode gaya, tautan, data meta (sumber iritasi lain dengan otomatisnya) ulang) dan upaya untuk memperbaiki beberapa karakter khusus dan tautan gambar yang ditetapkan melalui javascripts. Hyperlink dan pekerjaan navigasi. Untuk membaca hal-hal seperti LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr yang diberikannya. Bahkan pencarian Bing dan Google pun datang. Akhirnya atau ketika ditanya, saya akan membuatnya tersedia secara gratis. Tidak banyak tetapi ini adalah awal.

Tentu itu bisa dilakukan. Dan itu juga masuk akal. Tidak ada browser yang mendukung standar w3c lengkap untuk alasan yang tidak jelas. Pada bagian dukungan css3, perusahaan browser juga tidak mendukung standar. -moz- * dan -webkit- * tidak akan pernah menjadi bagian dari standar. Jadi browser yang memenuhi standar standar harus mengabaikannya. Salah satu kesalahan terbesar dari w3c adalah tidak adanya spesifikasi render. Jadi halaman web yang memenuhi standar yang sama akan terlihat berbeda di setiap browser, mimpi buruk desain grafis. Kegagalan w3c lainnya adalah kurangnya kecepatan. Diskusi 5 tahun dan masih hanya konsep standar untuk HTML5? Kemudian organisasi Anda memblokir inovasi serius.

Saya pikir kita harus mengabaikan w3c, mengabaikan spesifikasi mereka dan membuat standar komunitas dalam waktu setengah tahun untuk bahasa markup aplikasi web DENGAN rendering spesifikasi dan keamanan dalam pikiran. Ingat HTML tidak pernah dirancang untuk aplikasi web, karena tidak ada aplikasi web pada saat itu sgml digunakan sebagai dasar untuk HTML.