java package實驗

標籤：

我們先找一個目錄，比如C:\myjob
然後我們建立兩個目錄，一個叫做src，一個叫做bin

然後我們在src目錄中去寫程式
我們寫這麼4個java檔案

[java] view plain copy  print?

1. ////A.java  
2. package com.lightning;  
3. public class A{  
4. {System.out.println("com.lightning.A");}  
5. }  

[java] view plain copy  print?

1. ////B.java  
2. package com.lightning;  
3. public class B{  
4. {System.out.println("com.lightning.B");}  
5. }  

[java] view plain copy  print?

1. ////C.java  
2. package com;  
3. public class C{  
4. {System.out.println("com.C");}  
5. }  

[java] view plain copy  print?

1. ////Test.java  
2. package net.test;  
3. import com.lightning.*;  
4. import com.*;  
5. public class Test{  
6. public static void main(String[] args)  
7. {  
8. new A();new B();new C();  
9. System.out.println("net.test.Test");  
10. }  
11. }  

寫好之後就是這樣


然後我們建立com目錄，com\lightning\目錄，net\test\目錄
我們將Test.java放入net\test\中去
將A.java，B.java放入com\lightning\中去
將C.java放入com\中去

然後我們在c:\myjobs中發令：

C:\myjob>javac -sourcepath src -d bin src\net\test\Test.java
然後我們看看bin目錄中多了什麼

然後我們執行，同樣在c:\myjobs\下發令
C:\myjob>java -cp bin net.test.Test

 

2，從實踐到理論

剛才我用一個非常簡單但是非常完整的例子給大家示範了java的package機制。
為什麼以前腦海裡面那麼簡單的javac會搞得這麼複雜呢？

實際上它本就這麼複雜，
並不是一個.java，一行javac一個目前的目錄中的class這麼簡單。

首先我要打破一些東西，然後才好建立一些東西。
javac並非只是給一個.java編譯一個class的。javac內建有make機制，也就是說，如果在
javac的參數中java檔案使用到的任何類，javac首先會去找尋這個類的class檔案存在與否
，如果不存在，就會在sourcepath中找尋原始碼檔案來編譯。

什麼是sourcepath呢？sourcepath是javac的一個參數，如果你不加指定，那麼sourcepath
就是classpath。

比如我們裝好jdk之後，我說過不要設定classpath環境變數，因為大部分人一旦設定了
classpath，不是多此一舉把什麼dt.jar放進去。（我可以好好打擊你一下，告訴你一個可
悲的事實——jre永遠不會從你這個classpath中去尋找dt.jar。你完全是徒勞的！）就是
把"."搞不見了，搞得是冷水一盆盆的往自己身上潑，腦袋一點點的漲大。

不要設！classpath沒有你想象中那麼普適和強大，它只是命令列的簡化替代品。
你不設的話它就是"."。

回到sourcepath，sourcepath指的是你原始碼樹的存放地點。
為什麼是原始碼樹？而不是一個目錄的平板原始碼呢？
請大家將原本腦海中C的編譯過程完全砸掉！
java完全不同，java沒有標頭檔，每個.java都是要放在原始碼樹中的。
那麼這顆樹是怎麼組織的呢？
對了，就是package語句。
比如寫了package com.lightning;
那麼這個.java就必須放在原始碼樹根\的com\lighting\之下才行。

很多浮躁的初學者被default打包方式寵壞了。自我為中心，以為java就是一套庫，自己寫
的時候最多import進來就行了，代碼從不打包，直接javac，直接java，多麼方便。
孰不知自己寫的這個.java也不過是java大平台的其中一個小單元而已。如果不打包，
我寫一個Point，你寫一個Point，甚至更有甚者敢於給自己的類起名叫String等等。
全部都在平板式的目錄中，那jre該選哪一個？

一旦要使用package語句，就要使用代碼樹結構，當然，你要直接javac，也行。
不過javac出來的這個class要放在符合package結構的目錄中才能發揮正常作用，否則就是
廢物一坨。
而且，如果你這個.java還用到其它自己寫的有package語句的.java，那這個方法就回天乏
術了。

按照sun的想象，應該是寫好的.java放在符合package結構的目錄中，package語句保證了
正確放置，如果目錄位置和package語句中指示的不同，則會出錯。

所以按照剛才我們的那種package寫法，我們必然要將那幾個.java檔案放入相應的目錄中
才能讓javac順利找到他們來make。

有人說javac可不可以像java那樣 java aaa.bbb.c...java？
不可以
javac中的那個.java檔案參數必須是一個檔案系統的路徑檔案名稱形式。
然後如果用到其它的.java，javac會根據目前的sourcepath出發尋找目錄結構中的那些
java檔案。

當然了，既然打了包，在使用的時候。
要麼寫全名——包名.類名
或者使用import
不得不提的是，import就好比c++的using，它不負責做檔案操作，它只是方便你寫代碼。

另外import語句中的*代表的是類名，不代表包名片斷。
你import com.*; 
編譯器仍然找不到com.lightning中的任何類。
反之亦然。
就好象你告訴編譯器，我這裡面要用到姓諸葛的人。
那麼姓諸的人當然編譯器不會認為也包含在內。 

所以，如果程式一旦寫到一定規模。
就不得不使用ant來管理這些。
或者使用IDE，否則jdk就真的變成了java developer killer。

但是對於初學者，在瞭解為什麼會有ant之類的之前，還是要體會一下使用
jdk的艱辛。

這個和以前在unix上開發的人用gcc命令列到後來使用make之後使用ide
之類的時候的體會是類似的。

最後，javac的-d參數是指示編譯出來的class檔案放在哪裡的，如果你不指定的話，它們

和.java混在一起。當然也符合目錄結構。

 

longforus:

 

這2天被EditPlus只要加了包就出現  Could not find or load main class 的問題困擾了很久  看了這篇文章，雖然還是沒能完全理解，但是也搞清楚了一些問題，

 

在加了包的類 javac 和java的時候要加上完整的 包名加類名 的形式：

 

 

在Editplus中不能直接運行有package包名稱的Java類的問題已經找在網上到瞭解決方法 
用網上的方法整合了修改設定的editplus 下載即可使用：
連結：http://pan.baidu.com/s/1bpE1BZL 密碼：j7qd

java package實驗