1.先安裝一個Subclipse，地址：http://subclipse.tigris.org/ 
    2.可以通過Eclipse的Update Site安裝方式：http://subclipse.tigris.org/update_1.4.x或者下載下來之后，解壓縮復制到Eclipse目錄即可。
    3.啟動程序后在Eclipse配置項的Team里面就會多出SVN，就可以進行配置了。
    4.想要提交一個項目，對項目點擊右鍵Team——Share project就可以將項目導入SVN了。
    需要注意的是，請不要將動態生成的目錄添加到SVN，否則其他人Check out的之后，再Update容易出錯，例如classes目錄，不需要提交上去，本地就可以了。
    想要對比本地和服務器上的源代碼，請使用Team——Synchronize with Repository，列出不同的文件之后，雙擊，既可以對比兩個文件。
    WebService項目會生成一個。apt_generated目錄，里面包含了一些源代碼，提交的時候不需要提交上去，MyEclipse在獲得SVN的項目之后，會自動生成這個目錄和底下的文件。 1) Assigned
      主鍵由外部程序負責生成，無需Hibernate參與。
2) hilo
      通過hi/lo 算法實現的主鍵生成機制，需要額外的數據庫表保存主鍵生成歷史狀態。
3) seqhilo
      與hilo 類似，通過hi/lo 算法實現的主鍵生成機制，只是主鍵歷史狀態保存在Sequence中，適用于支持Sequence的數據庫，如Oracle。
4) increment
      主鍵按數值順序遞增。此方式的實現機制為在當前應用實例中維持一個變量，以保存著當前的最大值，之后每次需要生成主鍵的時候將此值加1作為主鍵。
      這種方式可能產生的問題是：如果當前有多個實例訪問同一個數據庫，那么由于各個實例各自維護主鍵狀態，不同實例可能生成同樣的主鍵，從而造成主鍵重復異常。因此，如果同一數據庫有多個實例訪問，此方式必須避免使用。
5) identity
       采用數據庫提供的主鍵生成機制。如DB2、SQL Server、MySQL中的主鍵生成機制。
6) sequence
       采用數據庫提供的sequence 機制生成主鍵。如Oralce 中的Sequence。
7) native
       由Hibernate根據底層數據庫自行判斷采用identity、hilo、sequence其中一種作為主鍵生成方式。
8) uuid.hex
       由Hibernate基于128 位唯一值產生算法生成16 進制數值（編碼后以長度32 的字符串表示）作為主鍵。
9) uuid.string
       與uuid.hex 類似，只是生成的主鍵未進行編碼（長度16）。在某些數據庫中可能出現問題（如PostgreSQL）。
10) foreign
       使用外部表的字段作為主鍵。

　　JAR 文件是什么？
　　JAR 文件格式以流行的 ZIP 文件格式為基礎，用于將許多個文件聚集為一個文件。與 ZIP 文件不同的是，JAR 文件不僅用于壓縮和發布，而且還用于部署和封裝庫、組件和插件程序，并可被像編譯器和 JVM 這樣的工具直接使用。在 JAR 中包含特殊的文件，如 manifests 和部署描述符，用來指示工具如何處理特定的 JAR。

　　一個 JAR 文件可以用于：
　　□ 用于發布和使用類庫
　　□ 作為應用程序和擴展的構建單元
　　□ 作為組件、applet 或者插件程序的部署單位
　　□ 用于打包與組件相關聯的輔助資源

　　JAR 文件格式提供了許多優勢和功能，其中很多是傳統的壓縮格式如 ZIP 或者 TAR 所沒有提供的。它們包括：

　　☆ 安全性。 可以對 JAR 文件內容加上數字化簽名。這樣，能夠識別簽名的工具就可以有選擇地為您授予軟件安全特權，這是其他文件做不到的，它還可以檢測代碼是否被篡改過。

　　☆ 減少下載時間。 如果一個 applet 捆綁到一個 JAR 文件中，那么瀏覽器就可以在一個 HTTP 事務中下載這個 applet 的類文件和相關的資源，而不是對每一個文件打開一個新連接。

　　☆ 壓縮。JAR 格式允許您壓縮文件以提高存儲效率。

　　☆ 傳輸平臺擴展。 Java 擴展框架(Java Extensions Framework)提供了向 Java 核心平臺添加功能的方法，這些擴展是用 JAR 文件打包的(Java 3D 和 JavaMail 就是由 Sun 開發的擴展例子)。

　　☆ 包密封。 存儲在 JAR 文件中的包可以選擇進行密封，以增強版本一致性和安全性。密封一個包意味著包中的所有類都必須在同一 JAR 文件中找到。

　　☆ 包版本控制。 一個 JAR 文件可以包含有關它所包含的文件的數據，如廠商和版本信息。

　　☆ 可移植性。 處理 JAR 文件的機制是 Java 平臺核心 API 的標準部分。

　　壓縮的和未壓縮的 JAR
　　jar 工具在默認情況下壓縮文件。未壓縮的 JAR 文件一般可以比壓縮過的 JAR 文件更快地裝載，因為在裝載過程中要解壓縮文件，但是未壓縮的文件在網絡上的下載時間可能更長。

　　META-INF 目錄
　　大多數 JAR 文件包含一個 META-INF 目錄，它用于存儲包和擴展的配置數據，如安全性和版本信息。Java 2 平臺識別并解釋 META-INF 目錄中的下述文件和目錄，以便配置應用程序、擴展和類裝載器：

　　☆ MANIFEST.MF。 這個 manifest 文件定義了與擴展和包相關的數據。

　　☆ INDEX.LIST。 這個文件由 jar 工具的新選項 -i 生成，它包含在應用程序或者擴展中定義的包的位置信息。它是 JarIndex 實現的一部分，并由類裝載器用于加速類裝載過程。

　　☆ xxx.SF。 這是 JAR 文件的簽名文件。占位符 xxx 標識了簽名者。

　　☆ xxx.DSA。 與簽名文件相關聯的簽名程序塊文件，它存儲了用于簽名 JAR 文件的公共簽名。

　　jar 工具
　　為了用 JAR 文件執行基本的任務，要使用作為Java Development Kit 的一部分提供的 Java Archive Tool (jar 工具)。用 jar 命令調用 jar 工具。表 1 顯示了一些常見的應用：

表 1. 常見的 jar 工具用法

功能	命令
用一個單獨的文件創建一個 JAR 文件	jar cf jar-file input-file...
用一個目錄創建一個 JAR 文件	jar cf jar-file dir-name
創建一個未壓縮的 JAR 文件	jar cf0 jar-file dir-name
更新一個 JAR 文件	jar uf jar-file input-file...
查看一個 JAR 文件的內容	jar tf jar-file
提取一個 JAR 文件的內容	jar xf jar-file
從一個 JAR 文件中提取特定的文件	jar xf jar-file archived-file...
運行一個打包為可執行 JAR 文件的應用程序	java -jar app.jar

　　可執行的 JAR
　　一個可執行的 jar 文件是一個自包含的 Java 應用程序，它存儲在特別配置的JAR 文件中，可以由 JVM 直接執行它而無需事先提取文件或者設置類路徑。要運行存儲在非可執行的 JAR 中的應用程序，必須將它加入到您的類路徑中，并用名字調用應用程序的主類。但是使用可執行的 JAR 文件，我們可以不用提取它或者知道主要入口點就可以運行一個應用程序。可執行 JAR 有助于方便發布和執行 Java 應用程序。

　　創建可執行 JAR
　　創建一個可執行 JAR 很容易。首先將所有應用程序代碼放到一個目錄中。假設應用程序中的主類是 com.mycompany.myapp.Sample。您要創建一個包含應用程序代碼的 JAR 文件并標識出主類。為此，在某個位置(不是在應用程序目錄中)創建一個名為 manifest 的文件，并在其中加入以下一行：

　　Main-Class: com.mycompany.myapp.Sample

　　然后，像這樣創建 JAR 文件：

　　jar cmf manifest ExecutableJar.jar application-dir

　　所要做的就是這些了 -- 現在可以用 java -jar 執行這個 JAR 文件 ExecutableJar.jar。

　　一個可執行的 JAR 必須通過 menifest 文件的頭引用它所需要的所有其他從屬 JAR。如果使用了 -jar 選項，那么環境變量 CLASSPATH 和在命令行中指定的所有類路徑都被 JVM 所忽略。

　　啟動可執行 JAR
　　既然我們已經將自己的應用程序打包到了一個名為 ExecutableJar.jar 的可執行 JAR 中了，那么我們就可以用下面的命令直接從文件啟動這個應用程序：

　　java -jar ExecutableJar.jar

　　包密封
　　密封 JAR 文件中的一個包意味著在這個包中定義的所有類都必須在同一個 JAR 文件中找到。這使包的作者可以增強打包類之間的版本一致性。密封還提供了防止代碼篡改的手段。

　　要密封包，需要在 JAR 的 manifest 文件中為包添加一個 Name 頭，然后加上值為“true”的 Sealed 頭。與可執行的 JAR 一樣，可以在創建 JAR 時，通過指定一個具有適當頭元素的 manifest 文件密封一個 JAR，如下所示：

　　Name: com/samplePackage/
　　Sealed: true

　　Name 頭標識出包的相對路徑名。它以一個“/”結束以與文件名區別。在 Name 頭后面第一個空行之前的所有頭都作用于在 Name 頭中指定的文件或者包。在上述例子中，因為 Sealed 頭出現在 Name 頭后并且中間沒有空行，所以 Sealed 頭將被解釋為只應用到包 com/samplePackage 上。

　　如果試圖從密封包所在的 JAR 文件以外的其他地方裝載密封包中的一個類，那么 JVM 將拋出一個 SecurityException。

　　擴展打包
　　擴展為 Java 平臺增加了功能，在 JAR 文件格式中已經加入了擴展機制。擴展機制使得 JAR 文件可以通過 manifest 文件中的 Class-Path 頭指定所需要的其他 JAR 文件。

　　假設 extension1.jar 和 extension2.jar 是同一個目錄中的兩個 JAR 文件，extension1.jar 的 manifest 文件包含以下頭：

　　Class-Path: extension2.jar

　　這個頭表明 extension2.jar 中的類是 extension1.jar 中的類的擴展類。extension1.jar 中的類可以調用 extension2.jar 中的類，并且不要求 extension2.jar 處在類路徑中。

　　在裝載使用擴展機制的 JAR 時，JVM 會高效而自動地將在Class-Path 頭中引用的 JAR 添加到類路徑中。不過，擴展 JAR 路徑被解釋為相對路徑，所以一般來說，擴展 JAR 必須存儲在引用它的 JAR 所在的同一目錄中。

　　例如，假設類 ExtensionClient 引用了類 ExtensionDemo,它捆綁在一個名為 ExtensionClient.jar 的 JAR 文件中，而類 ExtensionDemo 則捆綁在 ExtensionDemo.jar 中。為了使 ExtensionDemo.jar 可以成為擴展，必須將 ExtensionDemo.jar 列在 ExtensionClient.jar 的 manifest 的 Class-Path 頭中，如下所示：

　　Manifest-Version: 1.0
　　Class-Path: ExtensionDemo.jar

　　在這個 manifest 中 Class-Path 頭的值是沒有指定路徑的 ExtensionDemo.jar，表明 ExtensionDemo.jar 與 ExtensionClient JAR 文件處在同一目錄中。

　　JAR 文件中的安全性
　　JAR 文件可以用 jarsigner 工具或者直接通過 java.security API 簽名。一個簽名的 JAR 文件與原來的 JAR 文件完全相同，只是更新了它的 manifest，并在 META-INF 目錄中增加了兩個文件，一個簽名文件和一個簽名塊文件。

　　JAR 文件是用一個存儲在 Keystore 數據庫中的證書簽名的。存儲在 keystore 中的證書有密碼保護，必須向 jarsigner 工具提供這個密碼才能對 JAR 文件簽名。

Keystore 數據庫

　　JAR 的每一位簽名者都由在 JAR 文件的 META-INF 目錄中的一個具有 .SF 擴展名的簽名文件表示。這個文件的格式類似于 manifest 文件 -- 一組 RFC-822 頭。如下所示，它的組成包括一個主要部分，它包括了由簽名者提供的信息、但是不特別針對任何特定的 JAR 文件項，還有一系列的單獨的項，這些項也必須包含在 menifest 文件中。在驗證一個簽名的 JAR 時，將簽名文件的摘要值與對 JAR 文件中的相應項計算的摘要值進行比較。

　　清單 1. 簽名 JAR 中的 Manifest 和 signature 文件

Contents of signature file META-INF/MANIFEST.MF

Manifest-Version: 1.0
Created-By: 1.3.0 (Sun Microsystems Inc.)

Name: Sample.java
SHA1-Digest: 3+DdYW8INICtyG8ZarHlFxX0W6g=

Name: Sample.class
SHA1-Digest: YJ5yQHBZBJ3SsTNcHJFqUkfWEmI=

Contents of signature file META-INF/JAMES.SF

Signature-Version: 1.0
SHA1-Digest-Manifest: HBstZOJBuuTJ6QMIdB90T8sjaOM=
Created-By: 1.3.0 (Sun Microsystems Inc.)

Name: Sample.java
SHA1-Digest: qipMDrkurQcKwnyIlI3Jtrnia8Q=

Name: Sample.class
SHA1-Digest: pT2DYby8QXPcCzv2NwpLxd8p4G4=

　　數字簽名
　　一個數字簽名是.SF 簽名文件的已簽名版本。數字簽名文件是二進制文件，并且與 .SF 文件有相同的文件名，但是擴展名不同。根據數字簽名的類型 -- RSA、DSA 或者 PGP -- 以及用于簽名 JAR 的證書類型而有不同的擴展名。

　　Keystore
　　要簽名一個 JAR 文件，必須首先有一個私鑰。私鑰及其相關的公鑰證書存儲在名為 keystores 的、有密碼保護的數據庫中。JDK 包含創建和修改 keystores 的工具。keystore 中的每一個密鑰都可以用一個別名標識，它通常是擁有這個密鑰的簽名者的名字。

　　所有 keystore 項(密鑰和信任的證書項)都是用唯一別名訪問的。別名是在用 keytool -genkey 命令生成密鑰對(公鑰和私鑰)并在 keystore 中添加項時指定的。之后的 keytool 命令必須使用同樣的別名引用這一項。

　　例如，要用別名“james”生成一個新的公鑰/私鑰對并將公鑰包裝到自簽名的證書中，要使用下述命令：

keytool -genkey -alias james -keypass jamespass
        -validity 80 -keystore jamesKeyStore
        -storepass jamesKeyStorePass

　　這個命令序列指定了一個初始密碼“jamespass”，后續的命令在訪問 keystore “jamesKeyStore”中與別名“james”相關聯的私鑰時，就需要這個密碼。如果 keystore“jamesKeyStore”不存在，則 keytool 會自動創建它。

　　jarsigner 工具
　　jarsigner 工具使用 keystore 生成或者驗證 JAR 文件的數字簽名。

　　假設像上述例子那樣創建了 keystore “jamesKeyStore”，并且它包含一個別名為“james”的密鑰，可以用下面的命令簽名一個 JAR 文件：

jarsigner -keystore jamesKeyStore -storepass jamesKeyStorePass
          -keypass jamespass -signedjar SSample.jar Sample.jar james

　　這個命令用密碼“jamesKeyStorePass”從名為“jamesKeyStore”的 keystore 中提出別名為“james”、密碼為“jamespass”的密鑰，并對 Sample.jar 文件簽名、創建一個簽名的 JAR -- SSample.jar。

　　jarsigner 工具還可以驗證一個簽名的 JAR 文件，這種操作比簽名 JAR 文件要簡單得多，只需執行以下命令：

　　jarsigner -verify SSample.jar

　　如果簽名的 JAR 文件沒有被篡改過，那么 jarsigner 工具就會告訴您 JAR 通過驗證了。否則，它會拋出一個 SecurityException， 表明哪些文件沒有通過驗證。

　　還可以用 java.util.jar 和 java.security API 以編程方式簽名 JAR(有關細節參閱參考資料)。也可以使用像 Netscape Object Signing Tool 這樣的工具。

　　JAR 索引
　　如果一個應用程序或者 applet 捆綁到多個 JAR 文件中，那么類裝載器就使用一個簡單的線性搜索算法搜索類路徑中的每一個元素，這使類裝載器可能要下載并打開許多個 JAR 文件，直到找到所要的類或者資源。如果類裝載器試圖尋找一個不存在的資源，那么在應用程序或者 applet 中的所有 JAR 文件都會下載。對于大型的網絡應用程序和 applet，這會導致啟動緩慢、響應遲緩并浪費帶寬。

　　從 JDK 1.3 以后，JAR 文件格式開始支持索引以優化網絡應用程序中類的搜索過程，特別是 applet。JarIndex 機制收集在 applet 或者應用程序中定義的所有 JAR 文件的內容，并將這些信息存儲到第一個 JAR 文件中的索引文件中。下載了第一個 JAR 文件后，applet 類裝載器將使用收集的內容信息高效地裝載 JAR 文件。這個目錄信息存儲在根 JAR 文件的 META-INF 目錄中的一個名為 INDEX.LIST 的簡單文本文件中。

　　創建一個 JarIndex
　　可以通過在 jar 命令中指定 -i 選項創建一個 JarIndex。假設我們的目錄結構如下圖所示：

JarIndex

　　您將使用下述命令為 JarIndex_Main.jar、JarIndex_test.jar 和 JarIndex_test1.jar 創建一個索引文件：

　　jar -i JarIndex_Main.jar JarIndex_test.jar SampleDir/JarIndex_test1.jar

　　INDEX.LIST 文件的格式很簡單，包含每個已索引的 JAR 文件中包含的包或者類的名字，如清單 2 所示：

　　清單 2. JarIndex INDEX.LIST 文件示例

JarIndex-Version: 1.0

JarIndex_Main.jar
sp

JarIndex_test.jar
Sample

SampleDir/JarIndex_test1.jar
org
org/apache
org/apache/xerces
org/apache/xerces/framework
org/apache/xerces/framework/xml4j

　　結束語
　　JAR 格式遠遠超出了一種壓縮格式，它有許多可以改進效率、安全性和組織 Java 應用程序的功能。因為這些功能已經建立在核心平臺 -- 包括編譯器和類裝載器 -- 中了，所以開發人員可以利用 JAR 文件格式的能力簡化和改進開發和部署過程。

轉自：http://linxh.bokee.com/2946294.html

        1、禁用壓縮文件夾功能
　　假如你打開zip文件的話用winzip或者winrar軟件的話，以下優化是一個相當好的優化，Windows XP內置了對ZIP文件的，我們可以把zip文件當成文件夾瀏覽。不過，系統要使用部分資源來實現 這一功能，因此禁用這一功能可以提升系統性能。實現方法非常簡單，只需取消zipfldr.dll的注冊就可以了。
　　開始→運行: regsvr32 /u zipfldr.dll

　　2、減少開機磁盤掃描等待時間，重啟時候馬上你會看到效果。
　　開始→運行:chkntfs /t:0

　　3、刪除系統備份文件,在各種軟硬件安裝妥當之后，其實XP需要更新文件的時候就很少了。
　　開始→運行:sfc.exe /purgecache
　　然后回車即可,可節省百兆。
　　假如擔心的話，可不執行，此做法只會節省空間，而不是加速。

　　4、開始→運行: services.msc進入XP自帶服務修改列表
　　在列表每個服務的屬性里可選"關閉","手動","自動"。

　　alerter -錯誤警報器。 (可關閉)

　　application layer gateway service -給與第三者網絡共享/防火墻支持的服務，有些防火墻/網絡共享軟件需要。占用1。5mb內存。 (可關閉)

　　application management-用于設定，發布和刪除軟件服務。

　　automatic updates -windows自動更新。(可關閉)

　　background intelligent transfer service - 這個服務原是用來實現http1.1服務器之間的信息傳輸，微軟稱支持windows更新時斷點續傳

　　clipbook - 用與局域網電腦來共享 粘貼/剪貼的內容。(可關閉)

　　com+Event system　-一些 COM+　軟件需要。(檢查你的 c:program filesComPlus Applications 目錄，沒東西可以把這個服務關閉)

　　COM+Event system application　-同上 (可關閉)

　　COmputer browser -用來瀏覽局域網電腦的服務，但關了也不影響瀏覽!(可關閉)

　　cryptographic services -windows更新時用來確認windows 文件指紋的，我更新時才開啟一下。 (可關閉)

　　DHCP client-靜態IP者需要(xDSL　等)。

　　Distributed link tracking client-用于局域網更新連接信息，比如在電腦A有個文件，在B做了個連接，如果文件移動了，這個服務將會更新信息。占用4兆內存。 (可關閉) 

        Distributed Transaction coordinator-無聊的東西。 (可關閉)

　　DNS Client-DNS解析服務。(可關閉)

　　Error reporting service -錯誤報告器，把windows中錯誤報告給微軟。(可關閉)

　　Event Log- 系統日志紀錄服務，很有用于查找系統毛病.

　　Fast user switching compatibility-多用戶快速切換服務。(可關閉)

　　help and support -幫助。(可關閉)

　　Human interface device access-支持"弱智"電腦配件的。比如鍵盤上調音量的按鈕等等。(可關閉)

　　IMAPI CD-burning COM service　-xp刻牒服務，用軟件就不用了。占用1.6兆內存 (可關閉)

　　Indexing service -恐怖的xp減速……(可關閉)

　　Internet Connection Firewall(ICF)……-xp防火墻。(不用的話可關閉)

　　IPSEC Services-大眾用戶連邊都沾不上。 (可關閉)

　　Logical Disk manager　-磁盤管理服務。需要時它會通知你，所以一般關。 (可關閉)

　　Logical Disk manager administrative service-同上。 (可關閉)

　　messenger -不是msn，不想被騷擾的話就關。注:妖刺就是利用這個。 (可關閉)

　　MS software shadow copy provider-無用，據說是備份用的。但……沒用。 (可關閉)

　　Net Logon-登陸Domain Controller用的。(可關閉)

　　Netmeeting remote desktop sharing-用netmeeting實現電腦共享。(可關閉)

　　Network Connections - 上網/局域網要用的。

　　Network DDE　-和clipbook一起用的。(可關閉)

　　Network DDE DSDM　-同上 (可關閉)

　　Network Location Awareness-如有網絡共享或ICS/ICF可能需要。(服務器端) (可關閉)

　　NT LM Security support provider-telnet　服務用的。(可關閉)

　　NVIDIA Driver Helper service -nvidia 顯卡幫助。(可關閉)

　　PDEngine - perfectdisk 引擎

　　PDScheduler -perfectdisk 計劃服務

　　PerFORMance logs and alerts-記錄機器運行狀況而且定時寫入日志或發警告，內容可能過于專業，所以自己決定。

　　Plug and Play- 自動查測新裝硬件，即插即用。

　　Portable media serial number-絕對無用。 (可關閉)

　　Print Spooler -打印機用的。 (無打印機可關閉)

　　Protected Storage-儲存本地密碼和網上服務密碼的服務，包括填表時的"自動完成"功能。

　　QoS RSVP -據說是降低網速20%……(可關閉)

　　Remote access auto connection manager-寬帶/網絡共享。

　　Remote desktop help session manager-遠程幫助服務，占用4兆內存。 (可關閉)

　　Remote Procedure Call (RPC) -系統核心服務。

　　Remote Procedure Call LOCATOR-這個倒沒什么用，管理　RPC　數據庫服務，占用1兆內存。 (可關閉)

　　remote registry -遠程注冊表運行/修改。微軟的漏洞……(可關閉)

　　removable storage　-一般情況下不用，磁帶備份用的。 (可關閉)

　　routing and remote access-不知者關，我也不知。 (可關閉)

　　secondary logon-給與administrator 以外的用戶分配指定操作權.(可關閉)

　　security accounts manager-像 Protected Storage,　IIS Admin 才需要。

　　server -局域網文件/打印共享需要的。 (不打印者可關閉)

　　shell hardware detection-給有些配置自動啟動，像內存棒，和有些cd驅動等

　　smart card -占1.4兆內存呢(可關閉)

　　smart card helper -關。(可關閉)

　　SSDP Discovery service-沒有什么硬件利用這個服務。(可關閉)

　　system event notification-記錄用戶登錄/注銷/重起/關機信息。(可關閉)

　　system restore service -系統還原服務，吃資源和內存的怪獸。雖然有時用到，自己決定。 (可關閉)

　　task scheduler-windows 計劃服務。(可關閉)

　　TCP/IP NetBIOS helper-如果你的網絡不用Netbios 或WINS的話。(可關閉)

　　Telephony - 撥號服務，如果你的寬帶不用撥號，那么關了它。

　　telnet -還是微軟的漏洞。這根dos中的telnet命令沒關系。2兆內存。(可關閉)

　　terminal services-實現遠程登錄本地電腦，快速用戶切換和遠程桌面功能需要，不用這些功能就關了吧。(可關閉)

　　themes -XP的主題。關閉后是XP的經典風格。(可關閉)

　　uninterruptible power supply-停電保護設備用的。(可關閉)

　　universal plug and play device host-同SSDP Discovery Service。(可關閉)

　　upload manager-用來實現服務器和客戶端輸送文件的服務，簡單文件傳輸不需要這個。(可關閉)

　　volume shadow copy-同MS Software Shadow Copy Provider，無用。(可關閉)

　　webclient-可能和以后的.net技術有聯系。(可關閉)

　　Windows Audio -　控制著你聽到的聲音。(喜歡無聲者可關閉)

　　Windows Installer -windows的MSI安裝服務。(建議設成手動)

　　windows image acquisition (WIA) -有些數碼相機和掃描器用的，覺得沒用。(可關閉)

　　Windows Management Instrumentation - 重要的服務，關了會出現奇怪的問題

Thread.currentThread().getContextClassLoader().getResource("")
Test.class.getClassLoader().getResource("")
ClassLoader.getSystemResource("")
Test.class.getResource("")
Test.class.getResource("/")
new File("/").getAbsolutePath()
System.getProperty("user.dir")

關于Classloader詳見http://m.tkk7.com/lengxinCEO/archive/2007/12/07/166055.html

當JVM（Java虛擬機）啟動時，會形成由三個類加載器組成的初始類加載器層次結構：

       bootstrap classloader
                |
       extension classloader
                |
       system classloader

bootstrap classloader －引導（也稱為原始）類加載器，它負責加載Java的核心類。在Sun的JVM中，在執行java的命令中使用-Xbootclasspath選項或使用 - D選項指定sun.boot.class.path系統屬性值可以指定附加的類。這個加載器的是非常特殊的，它實際上不是 java.lang.ClassLoader的子類，而是由JVM自身實現的。大家可以通過執行以下代碼來獲得bootstrap classloader加載了那些核心類庫：
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (int i = 0; i < urls.length; i++) {
            System.out.println(urls[i].toExternalForm());
        }
在我的計算機上的結果為：
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/dom.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/sax.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xalan-2.3.1.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xercesImpl-2.0.0.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xml-apis.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xsltc.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/rt.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/i18n.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/sunrsasign.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/jsse.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/jce.jar
文件:/C:/j2sdk1.4.1_01/jre/lib/charsets.jar
文件:/C:/j2sdk1.4.1_01/jre/classes
這時大家知道了為什么我們不需要在系統屬性CLASSPATH中指定這些類庫了吧，因為JVM在啟動的時候就自動加載它們了。

extension classloader －擴展類加載器，它負責加載JRE的擴展目錄（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系統屬性指定的）中JAR的類包。這為引入除Java核心類以外的新功能提供了一個標準機制。因為默認的擴展目錄對所有從同一個JRE中啟動的JVM都是通用的，所以放入這個目錄的 JAR類包對所有的JVM和system classloader都是可見的。在這個實例上調用方法getParent()總是返回空值null，因為引導加載器bootstrap classloader不是一個真正的ClassLoader實例。所以當大家執行以下代碼時：
   System.out.println(System.getProperty("java.ext.dirs"));
   ClassLoader extensionClassloader=ClassLoader.getSystemClassLoader().getParent();
   System.out.println("the parent of extension classloader : "+extensionClassloader.getParent());
結果為：
C:\j2sdk1.4.1_01\jre\lib\ext
the parent of extension classloader : null
extension classloader是system classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一個實際的classloader，所以為null。

system classloader －系統（也稱為應用）類加載器，它負責在JVM被啟動時，加載來自在命令java中的-classpath或者java.class.path系統屬性或者 CLASSPATH*作系統屬性所指定的JAR類包和類路徑。總能通過靜態方法ClassLoader.getSystemClassLoader()找到該類加載器。如果沒有特別指定，則用戶自定義的任何類加載器都將該類加載器作為它的父加載器。執行以下代碼即可獲得：
   System.out.println(System.getProperty("java.class.path"));
輸出結果則為用戶在系統屬性里面設置的CLASSPATH。
classloader 加載類用的是全盤負責委托機制。所謂全盤負責，即是當一個classloader加載一個Class的時候，這個Class所依賴的和引用的所有 Class也由這個classloader負責載入，除非是顯式的使用另外一個classloader載入；委托機制則是先讓parent（父）類加載器 (而不是super，它與parent classloader類不是繼承關系)尋找，只有在parent找不到的時候才從自己的類路徑中去尋找。此外類加載還采用了cache機制，也就是如果 cache中保存了這個Class就直接返回它，如果沒有才從文件中讀取和轉換成Class，并存入cache，這就是為什么我們修改了Class但是必須重新啟動JVM才能生效的原因。

每個ClassLoader加載Class的過程是：
1.檢測此Class是否載入過（即在cache中是否有此Class），如果有到8,如果沒有到2
2.如果parent classloader不存在（沒有parent，那parent一定是bootstrap classloader了），到4
3.請求parent classloader載入，如果成功到8，不成功到5
4.請求jvm從bootstrap classloader中載入，如果成功到8
5.尋找Class文件（從與此classloader相關的類路徑中尋找）。如果找不到則到7.
6.從文件中載入Class，到8.
7.拋出ClassNotFoundException.
8.返回Class.

其中5.6步我們可以通過覆蓋ClassLoader的findClass方法來實現自己的載入策略。甚至覆蓋loadClass方法來實現自己的載入過程。

類加載器的順序是：
先是bootstrap classloader，然后是extension classloader，最后才是system classloader。大家會發現加載的Class越是重要的越在靠前面。這樣做的原因是出于安全性的考慮，試想如果system classloader“親自”加載了一個具有破壞性的“java.lang.System”類的后果吧。這種委托機制保證了用戶即使具有一個這樣的類，也把它加入到了類路徑中，但是它永遠不會被載入，因為這個類總是由bootstrap classloader來加載的。大家可以執行一下以下的代碼：
   System.out.println(System.class.getClassLoader());
將會看到結果是null，這就表明java.lang.System是由bootstrap classloader加載的，因為bootstrap classloader不是一個真正的ClassLoader實例，而是由JVM實現的，正如前面已經說過的。

下面就讓我們來看看JVM是如何來為我們來建立類加載器的結構的：
sun.misc.Launcher，顧名思義，當你執行java命令的時候，JVM會先使用bootstrap classloader載入并初始化一個Launcher，執行下來代碼：
  System.out.println("the Launcher's classloader is "+sun.misc.Launcher.getLauncher().getClass().getClassLoader());
結果為：
  the Launcher's classloader is null (因為是用bootstrap classloader加載,所以class loader為null)
Launcher 會根據系統和命令設定初始化好class loader結構，JVM就用它來獲得extension classloader和system classloader,并載入所有的需要載入的Class，最后執行java命令指定的帶有靜態的main方法的Class。extension classloader實際上是sun.misc.Launcher$ExtClassLoader類的一個實例，system classloader實際上是sun.misc.Launcher$AppClassLoader類的一個實例。并且都是 java.net.URLClassLoader的子類。

讓我們來看看Launcher初試化的過程的部分代碼。

Launcher的部分代碼：
public class Launcher  {
   public Launcher() {
       ExtClassLoader extclassloader;
       try {
           //初始化extension classloader
           extclassloader = ExtClassLoader.getExtClassLoader();
       } catch(IOException ioexception) {
           throw new InternalError("Could not create extension class loader");
       }
       try {
           //初始化system classloader，parent是extension classloader
           loader = AppClassLoader.getAppClassLoader(extclassloader);
       } catch(IOException ioexception1) {
           throw new InternalError("Could not create application class loader");
       }
       //將system classloader設置成當前線程的context classloader（將在后面加以介紹）
       Thread.currentThread().setContextClassLoader(loader);
       ......
   }
   public ClassLoader getClassLoader() {
       //返回system classloader
       return loader;
   }
}

extension classloader的部分代碼：
static class Launcher$ExtClassLoader extends URLClassLoader {

   public static Launcher$ExtClassLoader getExtClassLoader()
       throws IOException
   {
       File afile[] = getExtDirs();
       return (Launcher$ExtClassLoader)AccessController.doPrivileged(new Launcher$1(afile));
   }
  private static File[] getExtDirs() {
       //獲得系統屬性“java.ext.dirs”
       String s = System.getProperty("java.ext.dirs");
       File afile[];
       if(s != null) {
           StringTokenizer stringtokenizer = new StringTokenizer(s, File.pathSeparator);
           int i = stringtokenizer.countTokens();
           afile = new File;
           for(int j = 0; j < i; j++)
               afile[j] = new File(stringtokenizer.nextToken());

       } else {
           afile = new File[0];
       }
       return afile;
   }
}

system classloader的部分代碼：
static class Launcher$AppClassLoader extends URLClassLoader
{

   public static ClassLoader getAppClassLoader(ClassLoader classloader)
       throws IOException
   {
       //獲得系統屬性“java.class.path”
       String s = System.getProperty("java.class.path");
       File afile[] = s != null ? Launcher.access$200(s) : new File[0];
       return (Launcher$AppClassLoader)AccessController.doPrivileged(new Launcher$2(s, afile, classloader));
   }
}

看了源代碼大家就清楚了吧，extension classloader是使用系統屬性“java.ext.dirs”設置類搜索路徑的，并且沒有parent。system classloader是使用系統屬性“java.class.path”設置類搜索路徑的，并且有一個parent classloader。Launcher初始化extension classloader，system classloader，并將system classloader設置成為context classloader，但是僅僅返回system classloader給JVM。

　　這里怎么又出來一個context classloader呢？它有什么用呢？我們在建立一個線程Thread的時候，可以為這個線程通過setContextClassLoader方法來指定一個合適的classloader作為這個線程的context classloader，當此線程運行的時候，我們可以通過getContextClassLoader方法來獲得此context classloader，就可以用它來載入我們所需要的Class。默認的是system classloader。利用這個特性，我們可以“打破”classloader委托機制了，父classloader可以獲得當前線程的context classloader，而這個context classloader可以是它的子classloader或者其他的classloader，那么父classloader就可以從其獲得所需的 Class，這就打破了只能向父classloader請求的限制了。這個機制可以滿足當我們的classpath是在運行時才確定,并由定制的 classloader加載的時候,由system classloader(即在jvm classpath中)加載的class可以通過context classloader獲得定制的classloader并加載入特定的class(通常是抽象類和接口,定制的classloader中是其實現),例如web應用中的servlet就是用這種機制加載的.

        好了，現在我們了解了classloader的結構和工作原理，那么我們如何實現在運行時的動態載入和更新呢？只要我們能夠動態改變類搜索路徑和清除 classloader的cache中已經載入的Class就行了，有兩個方案，一是我們繼承一個classloader，覆蓋loadclass方法，動態的尋找Class文件并使用defineClass方法來；另一個則非常簡單實用，只要重新使用一個新的類搜索路徑來new一個 classloader就行了，這樣即更新了類搜索路徑以便來載入新的Class，也重新生成了一個空白的cache(當然,類搜索路徑不一定必須更改)。噢，太好了，我們幾乎不用做什么工作，java.netURLClassLoader正是一個符合我們要求的classloader！我們可以直接使用或者繼承它就可以了！

這是j2se1.4 API的doc中URLClassLoader的兩個構造器的描述：
URLClassLoader(URL[] urls)
         Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader.
URLClassLoader(URL[] urls, ClassLoader parent)
         Constructs a new URLClassLoader for the given URLs.
其中URL[] urls就是我們要設置的類搜索路徑，parent就是這個classloader的parent classloader，默認的是system classloader。


        好，現在我們能夠動態的載入Class了，這樣我們就可以利用newInstance方法來獲得一個Object。但我們如何將此Object造型呢？可以將此Object造型成它本身的Class嗎？

        首先讓我們來分析一下java源文件的編譯，運行吧！javac命令是調用“JAVA_HOME/lib/tools.jar”中的“com.sun.tools.javac.Main”的compile方法來編譯：

   public static int compile(String as[]);

   public static int compile(String as[], PrintWriter printwriter);

返回0表示編譯成功，字符串數組as則是我們用javac命令編譯時的參數，以空格劃分。例如：
javac -classpath c:\foo\bar.jar;. -d c:\ c:\Some.java
則字符串數組as為{"-classpath","c:\\foo\\bar.jar;.","-d","c:\\","c:\Some.java"}，如果帶有PrintWriter參數，則會把編譯信息出到這個指定的printWriter中。默認的輸出是 System.err。

其中 Main是由JVM使用Launcher初始化的system classloader載入的，根據全盤負責原則，編譯器在解析這個java源文件時所發現的它所依賴和引用的所有Class也將由system classloader載入，如果system classloader不能載入某個Class時，編譯器將拋出一個“cannot resolve symbol”錯誤。

所以首先編譯就通不過，也就是編譯器無法編譯一個引用了不在CLASSPATH中的未知Class的java源文件，而由于拼寫錯誤或者沒有把所需類庫放到CLASSPATH中，大家一定經常看到這個“cannot resolve symbol”這個編譯錯誤吧！

其次，就是我們把這個Class放到編譯路徑中，成功的進行了編譯，然后在運行的時候不把它放入到CLASSPATH中而利用我們自己的 classloader來動態載入這個Class，這時候也會出現“java.lang.NoClassDefFoundError”的違例，為什么呢？

我們再來分析一下，首先調用這個造型語句的可執行的Class一定是由JVM使用Launcher初始化的system classloader載入的，根據全盤負責原則，當我們進行造型的時候，JVM也會使用system classloader來嘗試載入這個Class來對實例進行造型，自然在system classloader尋找不到這個Class時就會拋出“java.lang.NoClassDefFoundError”的違例。

OK，現在讓我們來總結一下，java文件的編譯和Class的載入執行，都是使用Launcher初始化的system classloader作為類載入器的，我們無法動態的改變system classloader，更無法讓JVM使用我們自己的classloader來替換system classloader，根據全盤負責原則，就限制了編譯和運行時，我們無法直接顯式的使用一個system classloader尋找不到的Class，即我們只能使用Java核心類庫，擴展類庫和CLASSPATH中的類庫中的Class。

還不死心！再嘗試一下這種情況，我們把這個Class也放入到CLASSPATH中，讓system classloader能夠識別和載入。然后我們通過自己的classloader來從指定的class文件中載入這個Class（不能夠委托 parent載入，因為這樣會被system classloader從CLASSPATH中將其載入），然后實例化一個Object，并造型成這個Class，這樣JVM也識別這個Class（因為 system classloader能夠定位和載入這個Class從CLASSPATH中），載入的也不是CLASSPATH中的這個Class，而是從 CLASSPATH外動態載入的，這樣總行了吧！十分不幸的是，這時會出現“java.lang.ClassCastException”違例。

為什么呢？我們也來分析一下，不錯，我們雖然從CLASSPATH外使用我們自己的classloader動態載入了這個Class，但將它的實例造型的時候是JVM會使用system classloader來再次載入這個Class，并嘗試將使用我們的自己的classloader載入的Class的一個實例造型為system classloader載入的這個Class（另外的一個）。大家發現什么問題了嗎？也就是我們嘗試將從一個classloader載入的Class的一個實例造型為另外一個classloader載入的Class，雖然這兩個Class的名字一樣，甚至是從同一個class文件中載入。但不幸的是JVM 卻認為這個兩個Class是不同的，即JVM認為不同的classloader載入的相同的名字的Class（即使是從同一個class文件中載入的）是不同的！這樣做的原因我想大概也是主要出于安全性考慮，這樣就保證所有的核心Java類都是system classloader載入的，我們無法用自己的classloader載入的相同名字的Class的實例來替換它們的實例。

看到這里，聰明的讀者一定想到了該如何動態載入我們的Class，實例化，造型并調用了吧！

那就是利用面向對象的基本特性之一的多形性。我們把我們動態載入的Class的實例造型成它的一個system classloader所能識別的父類就行了！這是為什么呢？我們還是要再來分析一次。當我們用我們自己的classloader來動態載入這我們只要把這個Class的時候，發現它有一個父類Class，在載入它之前JVM先會載入這個父類Class，這個父類Class是system classloader所能識別的，根據委托機制，它將由system classloader載入，然后我們的classloader再載入這個Class，創建一個實例，造型為這個父類Class，注意了，造型成這個父類 Class的時候（也就是上溯）是面向對象的java語言所允許的并且JVM也支持的，JVM就使用system classloader再次載入這個父類Class，然后將此實例造型為這個父類Class。大家可以從這個過程發現這個父類Class都是由 system classloader載入的，也就是同一個class loader載入的同一個Class，所以造型的時候不會出現任何異常。而根據多形性，調用這個父類的方法時，真正執行的是這個Class（非父類 Class）的覆蓋了父類方法的方法。這些方法中也可以引用system classloader不能識別的Class，因為根據全盤負責原則，只要載入這個Class的classloader即我們自己定義的 classloader能夠定位和載入這些Class就行了。

這樣我們就可以事先定義好一組接口或者基類并放入CLASSPATH中，然后在執行的時候動態的載入實現或者繼承了這些接口或基類的子類。還不明白嗎？讓我們來想一想Servlet吧，web application server能夠載入任何繼承了Servlet的Class并正確的執行它們，不管它實際的Class是什么，就是都把它們實例化成為一個Servlet Class，然后執行Servlet的init，doPost，doGet和destroy等方法的,而不管這個Servlet是從web- inf/lib和web-inf/classes下由system classloader的子classloader(即定制的classloader)動態載入。說了這么多希望大家都明白了。在applet,ejb等容器中,都是采用了這種機制.

對于以上各種情況，希望大家實際編寫一些example來實驗一下。

最后我再說點別的， classloader雖然稱為類加載器，但并不意味著只能用來加載Class，我們還可以利用它也獲得圖片，音頻文件等資源的URL，當然，這些資源必須在CLASSPATH中的jar類庫中或目錄下。我們來看API的doc中關于ClassLoader的兩個尋找資源和Class的方法描述吧：
　　　　　　　　public URL getResource(String name)
　　　　　　　　用指定的名字來查找資源，一個資源是一些能夠被class代碼訪問的在某種程度上依賴于代碼位置的數據（圖片，音頻，文本等等）。
               一個資源的名字是以'/'號分隔確定資源的路徑名的。
               這個方法將先請求parent classloader搜索資源，如果沒有parent，則會在內置在虛擬機中的classloader（即bootstrap classloader）的路徑中搜索。如果失敗，這個方法將調用findResource(String)來尋找資源。
　　　　　　　　public static URL getSystemResource(String name)
               從用來載入類的搜索路徑中查找一個指定名字的資源。這個方法使用system class loader來定位資源。即相當于ClassLoader.getSystemClassLoader().getResource(name)。

例如：
   System.out.println(ClassLoader.getSystemResource("java/lang/String.class"));
的結果為：
   jar:文件:/C:/j2sdk1.4.1_01/jre/lib/rt.jar!/java/lang/String.class
表明String.class文件在rt.jar的java/lang目錄中。
因此我們可以將圖片等資源隨同Class一同打包到jar類庫中（當然，也可單獨打包這些資源）并添加它們到class loader的搜索路徑中，我們就可以無需關心這些資源的具體位置，讓class loader來幫我們尋找了！

<script language="vbscript">
/*利用VBScript構建asc嗎和字符串的互轉函數*/
Function str2asc(strstr)
    str2asc = hex(asc(strstr))
End Function
Function asc2str(ascasc)
    asc2str = chr(ascasc)
End Function
</script>
<script language="javascript">
/*這里開始時UrlEncode和UrlDecode函數*/
function UrlEncode(str){
    var ret="";
    var strSpecial="!"#$%&'()*+,/:;<=>?[]^`{|}~%";
    for(var i=0;i<str.length;i++){
        var chr = str.charAt(i);
        var c=str2asc(chr);
        if(parseInt("0x"+c) > 0x7f){
            ret+="%"+c.slice(0,2)+"%"+c.slice(-2);
        }else{
            if(chr==" "){
                ret+="+";
            }else if(strSpecial.indexOf(chr)!=-1){
                ret+="%"+c.toString(16);
            }else{
                ret+=chr;
            }
        }
    }
    return ret;
}
function UrlDecode(str){
    var ret="";
    for(var i=0;i<str.length;i++){
        var chr = str.charAt(i);
        if(chr == "+"){
            ret+=" ";
        }else if(chr=="%"){
            var asc = str.substring(i+1,i+3);
            if(parseInt("0x"+asc)>0x7f){
                ret+=asc2str(parseInt("0x"+asc+str.substring(i+4,i+6)));
                i+=5;
            }else{
                ret+=asc2str(parseInt("0x"+asc));
                i+=2;
            }
        }else{
            ret+= chr;
        }
    }
    return ret;
}
</script>

 

quartz報錯：
Caused by: java.lang.NoSuchMethodError: org.apache.commons.collections.SetUtils.orderedSet(Ljava/util/Set;)Ljava/util/Set;
的原因是由于使用的commons-collections.jar版本太低導致的要使用3.*的才行。
對于使用MyEclipse的，如果導入了commons-collections.jar 3.*的包還不行，而且沒有找到其他的包的話很可能是MyEclipse自帶的Liberary中包括了版本低的包而你導入了這個lib。
比如MyEclipse的Hibernate的Lib中包括commons-collections.jar但是版本是2.*。
Window->Preferences->Myeclipse->Project Capabilities->Hibernate
從lib中刪除此包即可。