OSGi, Java Modularity và Jigsaw

Vì vậy, cho đến sáng hôm qua, tôi vẫn chưa biết OSGi là gì. OSGi chỉ là một số từ thông dụng mà tôi cứ thấy bị cắt xén nhiều lần, và vì vậy cuối cùng tôi đã dành ra một khoảng thời gian để nghiên cứu về nó.

Nó thực sự có vẻ như là một thứ khá thú vị, vì vậy tôi muốn bắt đầu bằng cách nói rõ (cho hồ sơ) rằng tôi không phản đối OSGi về bất kỳ khía cạnh nào, cũng không phải là một số câu hỏi "OSGi-bashing".

Vào cuối ngày, có vẻ như OSGi - về cơ bản - đã giải quyết JSR 277 trên Java Modularity, nhận ra rằng có những thiếu sót với JARđặc tả tệp có thể dẫn đến vấn đề phân giải vùng tên và tải lớp trong một số trường hợp góc nhất định. OSGi cũng làm rất nhiều thứ thực sự thú vị khác, nhưng từ những gì tôi có thể chắc chắn, đó là điểm thu hút lớn nhất của nó (hoặc một trong số chúng).

Đối với tôi - với tư cách là một nhà phát triển Java EE khá mới (một vài năm nay), thật đáng kinh ngạc khi chúng ta đang ở vào năm 2011 và hiện đang sống trong kỷ nguyên của Java 7, và những vấn đề về tải lớp này vẫn còn tồn tại; đặc biệt là trong môi trường doanh nghiệp, nơi một máy chủ ứng dụng có thể có hàng trăm JAR trên đó, với nhiều JAR trong số đó tùy thuộc vào các phiên bản khác nhau của nhau và tất cả đều chạy (nhiều hơn hoặc ít hơn) đồng thời.

Câu hỏi của tôi:

Tôi quan tâm đến OSGi và tôi muốn bắt đầu tìm hiểu về nó để xem nó có thể được sử dụng ở đâu / nếu nó có thể được sử dụng cho các dự án của tôi, tôi chỉ không có thời gian để ngồi xuống và tìm hiểu một số thứ lớn như vậy, ít nhất là bây giờ.

Vậy các nhà phát triển không sử dụng OSGi phải làm gì khi những vấn đề này phát sinh? Những giải pháp Java (Oracle / Sun / JCP) nào hiện đang tồn tại, nếu có? Tại sao Jigsaw bị cắt khỏi J7? Cộng đồng chắc chắn rằng Jigsaw sẽ được triển khai vào năm tới trong J8 như thế nào? Có thể tải Jigsaw cho dự án của bạn mặc dù nó chưa phải là một phần của nền tảng Java không?

Tôi đoán những gì tôi đang hỏi ở đây là sự kết hợp của sự hoảng loạn, âm mưu và một màn che mặt. Bây giờ tôi cuối cùng đã hiểu OSGi là gì, tôi chỉ không "hiểu" làm thế nào mà một thứ như Jigsaw đã mất hơn 20 năm để thành hiện thực, và sau đó làm thế nào mà có thể được đóng hộp từ một bản phát hành. Nó chỉ có vẻ cơ bản.

Và, là một nhà phát triển, tôi cũng tò mò không biết các giải pháp của tôi là gì, sans OSGi.

Ngoài ra, Lưu ý : Tôi biết đây không phải là một câu hỏi kiểu " lập trình thuần túy ", nhưng trước khi một số bạn bị cong mũi ra khỏi hình dạng, tôi muốn nói (một lần nữa, để lưu ý) rằng tôi đã cố tình đặt câu hỏi này VÌ THẾ. Đó là bởi vì tôi không có gì khác ngoài sự tôn trọng tối đa dành cho các SOer đồng nghiệp của mình và tôi đang tìm kiếm câu trả lời ở cấp độ kiến ​​trúc từ một số "Vị thần CNTT" mà tôi thấy ẩn nấp quanh đây mỗi ngày.

Tuy nhiên, đối với những người bạn hoàn toàn khăng khăng rằng một câu hỏi SO được hỗ trợ bằng một số đoạn mã:

int x = 9;

(Cảm ơn bất kỳ ai có thể cân nhắc trên OSGi / Jigsaw / classloader / namespace / JAR hell này!)

Trước tiên, hãy hiểu rằng trường hợp sử dụng chính của Jigsaw là modularise chính JRE. Là một mục tiêu phụ, nó sẽ cung cấp một hệ thống mô-đun có thể được sử dụng bởi các thư viện và ứng dụng Java khác.

Quan điểm của tôi là thứ gì đó như Jigsaw có lẽ chỉ cần thiết cho JRE, nhưng nó sẽ tạo ra nhiều vấn đề hơn nhiều so với những gì nó tuyên bố sẽ giải quyết nếu được sử dụng bởi các thư viện hoặc ứng dụng Java khác.

JRE là một trường hợp rất khó và đặc biệt. Nó đã hơn 12 tuổi và là một mớ hỗn độn đáng sợ, đầy rẫy những chu kỳ phụ thuộc và những phụ thuộc vô nghĩa. Đồng thời được sử dụng bởi khoảng 9 triệu nhà phát triển và có lẽ hàng tỷ hệ thống đang chạy. Do đó, bạn hoàn toàn không thể cấu trúc lại JRE nếu việc tái cấu trúc đó tạo ra những thay đổi đột phá.

OSGi là một hệ thống mô-đun giúp bạn (hoặc thậm chí buộc bạn) tạo phần mềm theo mô-đun. Bạn không thể chỉ cần rắc mô-đun lên trên một cơ sở mã không phải mô-đun hiện có. Việc biến một cơ sở mã không theo mô-đun thành một cơ sở mô-đun chắc chắn đòi hỏi một số cấu trúc lại: chuyển các lớp vào gói chính xác, thay thế việc khởi tạo trực tiếp bằng việc sử dụng các dịch vụ đã tách rời, v.v.

Điều này gây khó khăn cho việc áp dụng OSGi trực tiếp vào cơ sở mã JRE, tuy nhiên chúng tôi vẫn có yêu cầu chia JRE thành các phần hoặc "mô-đun" riêng biệt để có thể phân phối các phiên bản cắt giảm của JRE.

Do đó, tôi coi Jigsaw là một loại " biện pháp cực đoan " để giữ cho mã JRE tồn tại trong khi tách nó ra. Nó không giúp mã trở nên mô-đun hơn, và tôi tin rằng nó thực sự sẽ tăng cường bảo trì cần thiết để phát triển bất kỳ thư viện hoặc ứng dụng nào sử dụng nó.

Cuối cùng: OSGi tồn tại trong khi Jigsaw chưa tồn tại và có thể không bao giờ tồn tại. Cộng đồng OSGi có 12 năm kinh nghiệm trong việc phát triển các ứng dụng mô-đun. Nếu bạn thực sự quan tâm đến việc phát triển các ứng dụng mô-đun, OSGi là trò chơi duy nhất trong thị trấn.

Thật đơn giản, nếu bạn muốn phát triển dựa trên thành phần thực sự trong Java ngày nay thì OSGi là trò chơi duy nhất trong thị trấn.

Theo ý kiến ​​của tôi, Jigsaw là sự kết hợp của sự dung hòa giữa những gì có thể làm được trong JDK và mối quan hệ tồi tệ trước đó giữa SUN và những kẻ OSGi. Có thể nó sẽ xuất xưởng với Java 8, nhưng chúng ta phải chờ xem.

OSGi không phải là thuốc chữa bách bệnh nếu bạn đang làm việc trong một cài đặt doanh nghiệp điển hình và bạn sẽ cần phải làm quen với cách hoạt động của việc tải lớp vì một số thư viện nổi tiếng (nhìn vào bạn, Hibernate) đã đưa ra các giả định về khả năng hiển thị của lớp không còn hợp lệ bên trong OSGi.

Tôi thích OSGi, nhưng tôi sẽ không thử và trang bị thêm cho hệ thống hiện có. Tôi cũng sẽ cân nhắc những ưu và khuyết điểm về mặt phát triển greenfield - Tôi khuyên bạn nên xem xét các sản phẩm Apache hoặc Eclipse giúp đơn giản hóa cuộc sống cho OSGi và không tự mình làm tất cả.

Nếu bạn không sử dụng OSGi, thì thật là may mắn nếu bạn đã nghĩ ra một hệ thống có sự phụ thuộc vào các phiên bản khác nhau của cùng một thư viện - tất cả những gì bạn có thể làm là thử và tránh sự cố, mặc dù cần nhiều phiên bản của một thư viện có vẻ giống như một 'mùi' kiến ​​trúc đối với tôi.

Tôi thích việc bạn sử dụng cụm từ "trường hợp góc" để mô tả tình hình hiện tại.

có những thiếu sót với đặc tả tệp JAR có thể dẫn đến vấn đề phân giải vùng tên và tải lớp trong một số trường hợp góc nhất định

Nhưng dù sao, từ nhiều năm nay, tôi đã quan tâm đến các công cụ và kỹ thuật hỗ trợ việc tạo và thậm chí tốt hơn, thực thi, mã rõ ràng hơn, tách rời hơn, mạch lạc hơn và dễ bảo trì hơn những gì có lẽ sẽ là kết quả nếu không có chúng. Test Driven Design và Junit là một sự kết hợp như vậy.

Sau khi đã dành một vài tháng để chuyển một phần đáng kể cơ sở mã của chúng tôi sang OSGi, tôi sẽ nói rằng OSGi là một công cụ thậm chí còn tốt hơn về mặt này. Và đó thực sự là một lý do đủ để chuyển sang OSGi. Về lâu dài nó sẽ giúp bạn tiết kiệm rất nhiều tiền.

Và, như một phần thưởng, nó sẽ mang lại cho bạn cơ hội làm được nhiều điều thú vị. Hãy tưởng tượng, trong một bản demo, nâng cấp liền mạch mô-đun xác thực mà không bị mất lưu lượng truy cập, để hỗ trợ OAuth ... đột nhiên bạn lại thấy vui khi tạo ra nội dung!