Trình duyệt web thuần Java, nó có thực tế không? [đóng cửa]

Tôi biết rằng một trình duyệt web Java là có thể, nhưng nó có thực tế không? Tôi đã xem dự án Lobo và phải thừa nhận rằng tôi rất ấn tượng, nhưng từ những gì tôi đã thu thập được thì dường như sự phát triển đã dừng lại vào năm 2009. Một trình duyệt được mã hóa bằng Java thuần túy (không có ràng buộc java WebKit nào) có thể cạnh tranh với những người trong số các cấp bậc của Chrome hoặc Firefox, hoặc nó sẽ chậm hơn, gây trở ngại cho người dùng?

Ngôn ngữ lập trình, rất có thể, sẽ không phải là trở ngại. Quản lý bộ nhớ bắt buộc của JVM có thể là một bất lợi trong một số phần quan trọng về hiệu năng (ví dụ như đói bộ nhớ; nhưng sau đó, GC của Java thực sự có thể tốt hơn trong việc ngăn chặn rò rỉ bộ nhớ hơn bất cứ thứ gì bạn có thể tự cuộn) và có thêm một số vấn đề bảo mật, nhưng khác hơn, tôi thấy không có nút chặn hiển thị rõ ràng.

Tuy nhiên.

Một trình duyệt web có quy mô Firefox hoặc Chromium là một công việc khổng lồ và cả hai dự án đều có một kinh nghiệm khổng lồ đằng sau chúng - Mozilla xây dựng qua hàng thập kỷ xây dựng trình duyệt (và một số thất bại nổi tiếng), và Chrome / Chromium có cả Google và Apple (một lực lượng chính trong sự phát triển của WebKit) đằng sau nó và tiếp thu rất nhiều kiến ​​thức và kinh nghiệm từ KDE và các dự án Nguồn mở lớn vững chắc khác. Cả hai đều sử dụng hàng tá thư viện đã được chứng minh bằng trận chiến, không chỉ kết xuất các công cụ, mà còn đủ thứ. Đồ họa vectơ, kết xuất phông chữ, phân tích cú pháp, thao tác XML DOM Tree, kết nối mạng, lưu trữ, mã hóa, danh sách cứ lặp đi lặp lại và bạn không muốn tự mình phát minh lại tất cả các bánh xe đó, vì chúng khó làm và dễ bị sai .

Nói tóm lại, xây dựng một trình duyệt web có sức mạnh công nghiệp khá khó khăn và đó là lý do chỉ có một số câu chuyện thành công trong lĩnh vực này. Ngôn ngữ lập trình tương đối ít liên quan đến nó, mặc dù C và C ++ là một lợi thế, cả về mặt kỹ thuật và xã hội.

Về lý thuyết, nó chắc chắn có thể được thực hiện. Từ quan điểm thực tế, tuy nhiên, có vẻ như một chút nghi vấn. lobothậm chí không gần với lần đầu tiên nó được thử. Trên thực tế, một trong những màn trình diễn đầu tiên về sự vượt trội của Java được cho là trình duyệt HotJava - thứ sẽ thay đổi thế giới và khiến trình duyệt "thế hệ khảm" trở nên lỗi thời .

Tất nhiên, tất cả chúng ta đều biết khá nhiều điều ngược lại là đúng: HotJava đã chết và chưa bao giờ thực sự là đối thủ nặng ký trong các cuộc chiến trình duyệt (thực tế, nếu bạn tìm kiếm "trình duyệt HotJava", một số lượt truy cập hàng đầu là cho các báo cáo lỗi về cách nó không hoạt động khá chính xác, ngay cả đối với các ứng dụng web của Sun).

Cá nhân, tôi nghĩ rằng tự hỏi về việc nó có thể hoặc thực tế là (chủ yếu) nhìn và suy nghĩ sai hướng. Câu hỏi không phải là liệu Java có mang những hình phạt lớn như vậy đối với một dự án như vậy là không thực tế hay không. Câu hỏi đặt ra là liệu Java có đủ lợi thế để biện minh cho một dự án như vậy không.

Một thực tế đơn giản là webkit (để sử dụng ví dụ của bạn) là một đoạn mã lớn, phức tạp. Ngay cả khi chúng ta cho rằng Java tuyệt vời hơn nhiều đến mức chúng ta có thể làm tương tự với, bằng một nửa kích thước và độ phức tạp, kết quả vẫn là một đoạn mã khá lớn, phức tạp (tương tự V8, v.v.)

Tôi nghĩ trước khi nhân đôi số lượng công việc đó, hầu hết mọi người sẽ muốn đảm bảo hơn một chút so với: "chúng tôi nghĩ rằng sản phẩm của chúng tôi có khả năng cạnh tranh khá cao."

Nếu bạn bắt đầu từ một tập hợp các tính năng người dùng có thể nhìn thấy cho trình duyệt và sau đó thử xác định cách hiệu quả nhất để tạo trình duyệt với các tính năng đó, "Java" có thể sẽ không phải là một phần của câu trả lời đó, ngoại trừ là một phần của " Javascript ". Nếu lịch sử đã diễn ra khác đi, có lẽ không có lý do gì nó không thể (ít nhất là về mặt lý thuyết) là một phần của câu trả lời, nhưng với hoàn cảnh hiện tại, thì không.

Hơn nữa, tôi thấy rất ít khả năng thay đổi đó. Tôi hầu như không thể thấy điều đó xảy ra nếu Oracle (hoặc có thể là IBM) quyết định duy trì lập trường cạnh tranh của Java so với (ví dụ rõ ràng) Microsoft .NET, nhưng điều đó có vẻ nghi ngờ trừ khi .NET bắt đầu đe dọa thị trường cốt lõi của Java.

Ngoài ra, bất kỳ bộ tính năng nào bạn có thể tưởng tượng (bên ngoài "được viết bằng Pure Java" như một tính năng) gần như chắc chắn có thể đạt được nhanh hơn và dễ dàng hơn bằng cách viết một trình duyệt hoàn toàn bằng Java.

Tôi thành thật tin rằng một đội ngũ tận tâm, hiểu biết có thể tạo ra một trình duyệt web hiệu quả trong Java. Câu hỏi thực sự là, tại sao? Có trình duyệt được viết bằng một ngôn ngữ cụ thể không thực sự là một tính năng. Mọi người sẽ sử dụng Chrome vì nó nhanh hoặc Firefox vì nó có thể mở rộng, nhưng họ sẽ không sử dụng JBrowser chỉ vì nó được viết bằng Java. Vì vậy, câu hỏi thực sự trở thành, vấn đề gì bạn đang cố gắng giải quyết?

Câu hỏi tiếp theo, giả sử bạn có một lý do để viết JBrowser là, "sử dụng Java có làm cho nhiệm vụ dễ hơn hay khó hơn không?" Google, khi tạo Chrome, đã viết nó chủ yếu bằng C / C ++ mặc dù thực tế rằng họ là một cửa hàng rất ủng hộ Java. Có vẻ như họ tin rằng những lợi ích của Java sẽ không mang lại lợi nhuận ròng đúng hạn.

Với Nashorn (Javascript trên JVM thay thế Rhino) đến với JVM như một phần của Java 8, điều này hoàn toàn có thể thực hiện được. Tuy nhiên, như những người khác đã lưu ý - có rất nhiều trình duyệt web hiện đại và việc nhúng WebKit có vẻ dễ dàng hơn nếu bạn cần lưu trữ các khả năng duyệt trong ứng dụng Java :-).

Câu trả lời hàng đầu hiện nay là tuyệt vời. Tuy nhiên, tôi sẽ thêm rằng người ta không cần phải hoàn toàn mã hóa lại một cái gì đó vào Java. Có những công cụ chuyển đổi nguồn gốc thành mã byte Java với mức độ tương tác khác nhau. Họ thường tạo một trình thông dịch các loại hoặc sử dụng một biểu diễn giống như JVM như MIPS làm bước đệm. Người ta có thể phá vỡ sự phát triển trình duyệt Java thành nhiều bước bằng cách chuyển đổi các thư viện gốc chính thành mã byte Java, tích hợp chúng với nguồn trình duyệt Java thuần túy và dần dần triển khai thêm mã thư viện dưới dạng nguồn Java thuần túy.

Điều này cho phép bạn chứa mọi thứ trong JVM an toàn hơn. Tuy nhiên, nó sẽ là một cơn đau ở mông đảm bảo hiệu quả. Có một số tiền lệ trong việc tái cấu trúc dần các ứng dụng kế thừa lớn, tiền Agile / OOP. Thêm vào đó, một số thành phần đã có các triển khai Java tốt và chúng cũng có thể được sử dụng để giảm lao động.

Tôi phải nói rằng tôi hơi thiên vị ở đây, nhưng ở đây tôi đi. Tôi không thích các nhà giảng thuyết C / C ++, tôi biết có một số ứng dụng được thiết kế tốt đáng kinh ngạc ngoài đó nhưng nó chỉ là một công cụ, tôi thường có ấn tượng, nhiều người chỉ đề cập đến C / C ++ cho một giải pháp bỏ lỡ nhiều hơn Điểm A ( http://www.paulgraham.com/avg.html xem nghịch lý bóng đèn). Tôi cố gắng nhìn vào sự thật: Java nhanh như C / C ++ nhưng đòi hỏi nhiều bộ nhớ hơn. Hoặc để tôi viết lại, bạn có thể viết mã java nhanh như C / C ++ nhưng chương trình đó sẽ tiêu tốn nhiều bộ nhớ hơn. Tôi hy vọng chúng ta có thể đồng ý về điều này.

Nếu bạn nhìn vào năng suất, bạn có thể tạo các giải pháp java cho một số vấn đề nhất định (giả sử java doanh nghiệp) tương đối dễ dàng, so với các giải pháp C ++. Một trình duyệt web là một cái gì đó hoàn toàn khác nhau. Tôi thấy hai / ba yêu cầu của thị trưởng:

• Nó phải tuân theo các thông số kỹ thuật lớn, HTML, JavaScript, v.v ... Điều này liên quan đến các vấn đề như API vẽ 2D. Hoặc làm thế nào để có được từ một cuộc gọi hệ thống hệ điều hành (như một bản vẽ nguyên thủy) để thể hiện văn bản hoặc phông chữ (kết xuất hình ảnh). Hãy xem các thư viện như cairo (C) và các nỗ lực khác như gezira (www.youtube.com/watch?v=P97O8osukZ0, https://github.com/damelang/gezira )
• Nó phải cảm nhận thành thạo tiếng Nhật, có nghĩa là các hoạt động nhất định chỉ có ms được thực thi.
• Nó phải hình thành một Khái niệm giao diện người dùng tạo thành một trải nghiệm độc đáo, để cạnh tranh trong 'cuộc chiến trình duyệt' ngày nay khá khó khăn.

Tóm lại: có, bạn có thể tạo các trình duyệt ở hầu hết mọi ngôn ngữ lập trình với kết quả gần như giống hệt nhau so với các tàu hơi nước C ++ ngày nay. Nhưng để làm như vậy bạn sẽ cần một nỗ lực khá lớn. Tôi không biết bao nhiêu (trong hàng triệu), tôi thậm chí không muốn đoán điều đó. Có lẽ chúng ta có thể có được điểm mấu chốt này: mọi người không muốn tối ưu hóa bằng ngôn ngữ cấp cao hoặc có thể rẻ hơn để có được những người thích tối ưu hóa trong C / C ++ vì có rất nhiều (so với các chuyên gia ngôn ngữ khác có thể tối ưu hóa một mức độ tương tự).

Nó sẽ tương đương với khái niệm trong Windows 9x ngày chạy phần mềm OpenGL so với OpenGL được tăng tốc phần cứng. Vấn đề với việc sử dụng Java cho một cái gì đó giống như trình duyệt web là bạn có khả năng sử dụng nhiều chu kỳ xung nhịp bổ sung để làm một cái gì đó có thể có thể bằng nhiều ngôn ngữ bản địa hơn. Đó cũng là khái niệm với OpenGL - bạn có thể hoàn thành nhiệm vụ nhưng phải xử lý nhiều hơn để thực hiện.

Vì vậy, nó có thể? Có khả năng. Nó sẽ cạnh tranh? Không có khả năng - một cái gì đó trong mã phụ thuộc nền tảng, được tối ưu hóa cao có thể sẽ có lợi thế tốc độ đáng kể.

Đây chỉ là suy đoán.

Về tính khả thi của một trình duyệt web Java được viết bằng Java, có thể câu hỏi sai đã được hỏi.

Tôi thấy không cần phải phát minh lại bánh xe và viết một trình duyệt hoàn chỉnh khi hầu hết những cái hiện có đều miễn phí và có nhiều tính năng.

Điều đó nói rằng những gì tôi (chúng ta?) Nên tìm kiếm là "một cái gì đó" đủ tốt để đọc các trang web mà KHÔNG CÓ tất cả những thứ nhảm nhí (quảng cáo lại, video, gifs) được chất đống.

Google là người phạm tội chính ở đây với tất cả các quảng cáo của họ và như vậy.

Để giải quyết rằng tôi đã viết một trình duyệt Java sử dụng Java HTMLEditorKit với triển khai HTML 3.2 của nó và đọc một trang web dưới dạng văn bản, loại bỏ tất cả mã javascript, mã kiểu, liên kết, dữ liệu meta (một nguồn kích thích khác với tự động của nó tải lại) và cố gắng sửa một số ký tự đặc biệt và liên kết hình ảnh được đặt qua javascripts. Siêu liên kết và điều hướng làm việc. Để đọc những thứ như LA Times, NY Times, Il Corriere.it, ElPais.es, LeMonde.fr nó cung cấp. Ngay cả các tìm kiếm Bing và Google cũng đi qua. Cuối cùng hoặc khi được hỏi tôi sẽ làm cho nó miễn phí. Nó không nhiều nhưng nó là một sự khởi đầu.

Chắc chắn nó có thể được thực hiện. Và nó cũng có ý nghĩa. Không có trình duyệt nào hỗ trợ các tiêu chuẩn w3c đầy đủ vì những lý do không rõ ràng. Về phía css3, các công ty trình duyệt cũng không hỗ trợ các tiêu chuẩn. -moz- * và -webkit- * sẽ không bao giờ là một phần của tiêu chuẩn. Vì vậy, một trình duyệt tuân thủ tiêu chuẩn đầy đủ nên bỏ qua chúng. Một trong những sai lầm lớn nhất từ ​​w3c là thiếu thông số kỹ thuật kết xuất. Vì vậy, cùng một trang web tuân thủ các tiêu chuẩn sẽ trông khác nhau trong mỗi trình duyệt, một cơn ác mộng thiết kế đồ họa. Một w3c thất bại là thiếu tốc độ. 5 năm thảo luận và vẫn chỉ là một tiêu chuẩn dự thảo cho html5? Sau đó, tổ chức của bạn đang chặn bất kỳ sự đổi mới nghiêm trọng.

Tôi nghĩ rằng chúng ta nên bỏ qua w3c, bỏ qua thông số kỹ thuật của họ và tạo tiêu chuẩn cộng đồng trong vòng nửa năm cho ngôn ngữ đánh dấu ứng dụng web VỚI thông số kỹ thuật và bảo mật. Hãy nhớ rằng HTML không bao giờ được thiết kế cho các ứng dụng web, vì không có ứng dụng web tại thời điểm sgml được sử dụng làm cơ sở cho HTML.