以下是本人的一些分享，我熱愛編程，希望能多交編程的愛好者，如果你也是其中一名，那么請加好友，大家關注一下，下面的文章是自己覺得一些有用的東西，留下來給自己當筆記，當然也希望能幫助到你，首先感謝你的閱讀~！
筆者在觀看過Devoxx關于Jigsaw的一段演示后，我很興奮，覺得它應該會是針對復雜類路徑版本問題和JAR陷阱等問題的解決方案。開發者最終能夠使用他們所期望的任何Xalan版本，而無需被迫使用授權機制。不幸的是，通往更加有效的模塊系統的征途并不是很清晰。
在研究確實問題之前，我們先來看一些基本概念：
模塊化
模塊化是解決復雜性問題很重要的工具。把應用分成不同的部分（模塊、庫、包、子項目和組件），再分別進行計算，是行之有效的方式。模塊化的最終目的是能定義出一套API用于模塊間的溝通。
如果模塊間所有的通訊都只通過這種API來實現，那么模塊是松耦合的，于是：
改變某個模塊的實現會很容易
開發和測試各個模塊能很容易獨立開來
面向對象模式也是類似的道理。在OOP中，理想的狀況是擁有大量小的、可重用的、簡單并分離良好的對象。在模塊系統中，就可以完美地實現小的、可重用的、簡單并分離良好的模塊。它們的想法和最初的動機是完全一樣的，只是規模有所不同。
邏輯分離
傳統上，java中有兩種辦法來實現模塊化。邏輯分離是最自然的方式。它包括將應用程序分割成邏輯模塊（子項目），最后再部署成一個完整的應用。通過定義正確的包來實現邏輯分離也是可能的，但更通用的辦法是把應用分割成一些存檔文件（也就是JAR包）。邏輯分離里能促進模塊的重用，有助實現模塊間的松耦合。你甚至有可能定義一個API,然后宣布所有模塊間的通訊都要通過這個給定的API來實現。這樣的想法有個大問題，那就是你很難強破大家都采用這種限制性用法，而且沒有任何一種機制能夠確保這個API的用法。你也沒法把那些應用通過給定模塊來使用的類和作為公共API一部分的類區分開來。如果一個類是" 公共的",那它就可以被任何其他類使用，無論調用它的那個類屬于哪個模塊。另一方面，受保護的或者包級可見性的類在其模塊內部的調用也有限制。通常來說，涵蓋了一些包以及包中類的模塊需要能夠互相調用。因此即使某個應用是由一些邏輯模塊組成，但如果這些模塊是耦合的，那么分離也根本沒有用處。
物理分離
另外一個傳統的辦法就是物理上的分離。你可以通過將應用分割成不同的組件，然后把每個組件部署到不同的JVM上而實現分離。這些組件間通過遠程訪問機制進行通訊，比如RMI、CORBA或者WebServices.物理分離實現了分離，也實現了松耦合，但負面影響是開支很大。為實現分離而專門采用遠程訪問機制，有點殺雞用牛刀的味道。這會增加開發和部署不必要的復雜性，性能上所受到的影響也不能忽視的。
模塊系統
模塊系統的作用位于邏輯分離和物理分離之間。它強調模塊分離，但各個模塊仍然部署到同一個JVM中，而且模塊間的通訊由簡單傳統的方法調用組成，因此不會有運行時的開支負擔。在java生態系統中最流行的模塊框架是OSGi.它是一個成熟的規范，具有幾個不同的實現。在OSGi中，模塊被稱作bundle,每個bundle等同于一個JAR.每個bundle也包含一個 META-INF/MANIFEST.MF文件，這個文件會宣布導出哪些包（package）以及導入哪些包。只有那些導出包中的類才能被其他 bundle所使用，而其他包都只面向包的內部成員，包里的類也只能在自身bundle中使用。
比如下面這個聲明：
Manifest-Version: 1.0
Import-Package: net.krecan.spring.osgi.common
Export-Package: net.krecan.spring.osgi.dao
Bundle-Version: 1.0.0
Bundle-Name: demo-spring-osgi-dao
Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao
這個規范指定了名叫demo-spring-osgi-dao的bundle,它要導入包名為 net.krecan.spring.osgi.common中的類，并導出包名為net.krecan.spring.osgi.dao中的類。換句話說，這段聲明表明其他模塊只能使用net.krecan.spring.osgi.dao包。相反地，這個模塊要使用的則只是 net.krecan.spring.osgi.common包，而且也可能會由OSGi來提供專門的模塊負責導出這個包。當然你完全可以在導入和導出聲明中定義多個包名。
需要特別注意的是，OSGi的模塊化是構建在Java之上的。它不是語言的一部分！這里的模塊分離雖然可以由GUI來執行，但不可以由編譯器來執行。運行基于OSGi的應用時，你會需要一個OSGi的容器。這個容器可能是運行時環境的一部分，比如在Spring DM服務器中，也可能是嵌入在應用程序中的。這個容器不僅負責提供分離，也提供了其他諸如安全、模塊管理和生命周期管理之類的服務。OSGi還提供大量其他有趣的特性，但這些并不是本文所要關注的。
總結
當然，我相信Sun的工程師并不想要破壞Java本身。我想他們也是為了讓Java變得更好、更易于使用，但我擔心政治和市場因素會遠大于技術影響。再次聲明，這不會僅僅是個API的變化或者是特定于Sun的變化。這會是語言級別的變化！一旦語言被改變了，一旦添加了"module"關鍵字，就不會再有回頭路。到那時，Java中會有個模塊系統，無論喜不喜歡，我們都非得要用到這個模塊系統。真得很難想象帶模塊化的JVM,也很難想像Java語言中會有個 "module"關鍵字，而我們還要在這之上使用OSGi.
在互聯網時代，JAVA語言已經是使用最廣泛的服務器端語言。隨著3G、物聯網時代的到來，JAVA語言并不會“過時”，相反，JAVA語言會在新的業務領域有著更輝煌的發展前景。
學員，迅速成長為中國高端IT培訓領軍品牌。
筆者在觀看過Devoxx關于Jigsaw的一段演示后，我很興奮，覺得它應該會是針對復雜類路徑版本問題和JAR陷阱等問題的解決方案。開發者最終能夠使用他們所期望的任何Xalan版本，而無需被迫使用授權機制。不幸的是，通往更加有效的模塊系統的征途并不是很清晰。
在研究確實問題之前，我們先來看一些基本概念：
模塊化
模塊化是解決復雜性問題很重要的工具。把應用分成不同的部分（模塊、庫、包、子項目和組件），再分別進行計算，是行之有效的方式。模塊化的最終目的是能定義出一套API用于模塊間的溝通。
如果模塊間所有的通訊都只通過這種API來實現，那么模塊是松耦合的，于是：
改變某個模塊的實現會很容易
開發和測試各個模塊能很容易獨立開來
面向對象模式也是類似的道理。在OOP中，理想的狀況是擁有大量小的、可重用的、簡單并分離良好的對象。在模塊系統中，就可以完美地實現小的、可重用的、簡單并分離良好的模塊。它們的想法和最初的動機是完全一樣的，只是規模有所不同。
邏輯分離
傳統上，java中有兩種辦法來實現模塊化。邏輯分離是最自然的方式。它包括將應用程序分割成邏輯模塊（子項目），最后再部署成一個完整的應用。通過定義正確的包來實現邏輯分離也是可能的，但更通用的辦法是把應用分割成一些存檔文件（也就是JAR包）。邏輯分離里能促進模塊的重用，有助實現模塊間的松耦合。你甚至有可能定義一個API,然后宣布所有模塊間的通訊都要通過這個給定的API來實現。這樣的想法有個大問題，那就是你很難強破大家都采用這種限制性用法，而且沒有任何一種機制能夠確保這個API的用法。你也沒法把那些應用通過給定模塊來使用的類和作為公共API一部分的類區分開來。如果一個類是" 公共的",那它就可以被任何其他類使用，無論調用它的那個類屬于哪個模塊。另一方面，受保護的或者包級可見性的類在其模塊內部的調用也有限制。通常來說，涵蓋了一些包以及包中類的模塊需要能夠互相調用。因此即使某個應用是由一些邏輯模塊組成，但如果這些模塊是耦合的，那么分離也根本沒有用處。
物理分離
另外一個傳統的辦法就是物理上的分離。你可以通過將應用分割成不同的組件，然后把每個組件部署到不同的JVM上而實現分離。這些組件間通過遠程訪問機制進行通訊，比如RMI、CORBA或者WebServices.物理分離實現了分離，也實現了松耦合，但負面影響是開支很大。為實現分離而專門采用遠程訪問機制，有點殺雞用牛刀的味道。這會增加開發和部署不必要的復雜性，性能上所受到的影響也不能忽視的。
模塊系統
模塊系統的作用位于邏輯分離和物理分離之間。它強調模塊分離，但各個模塊仍然部署到同一個JVM中，而且模塊間的通訊由簡單傳統的方法調用組成，因此不會有運行時的開支負擔。在java生態系統中最流行的模塊框架是OSGi.它是一個成熟的規范，具有幾個不同的實現。在OSGi中，模塊被稱作bundle,每個bundle等同于一個JAR.每個bundle也包含一個 META-INF/MANIFEST.MF文件，這個文件會宣布導出哪些包（package）以及導入哪些包。只有那些導出包中的類才能被其他 bundle所使用，而其他包都只面向包的內部成員，包里的類也只能在自身bundle中使用。
比如下面這個聲明：
Manifest-Version: 1.0
Import-Package: net.krecan.spring.osgi.common
Export-Package: net.krecan.spring.osgi.dao
Bundle-Version: 1.0.0
Bundle-Name: demo-spring-osgi-dao
Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao
這個規范指定了名叫demo-spring-osgi-dao的bundle,它要導入包名為 net.krecan.spring.osgi.common中的類，并導出包名為net.krecan.spring.osgi.dao中的類。換句話說，這段聲明表明其他模塊只能使用net.krecan.spring.osgi.dao包。相反地，這個模塊要使用的則只是 net.krecan.spring.osgi.common包，而且也可能會由OSGi來提供專門的模塊負責導出這個包。當然你完全可以在導入和導出聲明中定義多個包名。
需要特別注意的是，OSGi的模塊化是構建在Java之上的。它不是語言的一部分！這里的模塊分離雖然可以由GUI來執行，但不可以由編譯器來執行。運行基于OSGi的應用時，你會需要一個OSGi的容器。這個容器可能是運行時環境的一部分，比如在Spring DM服務器中，也可能是嵌入在應用程序中的。這個容器不僅負責提供分離，也提供了其他諸如安全、模塊管理和生命周期管理之類的服務。OSGi還提供大量其他有趣的特性，但這些并不是本文所要關注的。
總結
當然，我相信Sun的工程師并不想要破壞Java本身。我想他們也是為了讓Java變得更好、更易于使用，但我擔心政治和市場因素會遠大于技術影響。再次聲明，這不會僅僅是個API的變化或者是特定于Sun的變化。這會是語言級別的變化！一旦語言被改變了，一旦添加了"module"關鍵字，就不會再有回頭路。到那時，Java中會有個模塊系統，無論喜不喜歡，我們都非得要用到這個模塊系統。真得很難想象帶模塊化的JVM,也很難想像Java語言中會有個 "module"關鍵字，而我們還要在這之上使用OSGi.
在互聯網時代，JAVA語言已經是使用最廣泛的服務器端語言。隨著3G、物聯網時代的到來，JAVA語言并不會“過時”，相反，JAVA語言會在新的業務領域有著更輝煌的發展前景。
學員，迅速成長為中國高端IT培訓領軍品牌。
