如果說看完這個連載你便能全面掌握Java技術，我絕不敢打這樣的保票。喝再多咖啡，我也無法把Java的博大精深濃縮成一個連載。咖啡館本來就是休閑的地方，所以，我將有選擇地為你介紹Java技術的重要組成部分，涉獵面廣，但不見得都非常深入。所以，如果想真正在Java技術上有所造詣，也需要你自己的努力和汗水。畢竟，咖啡聞起來香，但本身是苦的，只有不嫌棄這點苦，才能品嘗到真味道。
做為一個.Net、Java、Delphi、Python、PHP等語言都進行過有一定復雜度的項目開發的人來說，我對任何一門語言都沒有宗教式狂熱崇拜，因此我也相對理性的對整個問題進行分析。
從北京、廣州、上海等地區2010年的就業統計數據(由于沒有找到更權威的數據，這些數據是我對主流招聘網站和技術網站的相關數據進行的并不是太嚴謹的分析)來看，.Net和Java的職位數量比例為2：3，從就業網站和主要技術社區數據來看，2010年.Net和Java的學習人員數量比例為1：3。從數據上看，.Net的職位絕對數量比Java低一些，不過Java學習人員數量比.Net學習人員高出3倍，因此.Net職位的競爭激烈程度低于 Java。
由于.Net秉承了微軟技術的入門簡單的特點，經過短時間的學習就可以掌握拖拉控件的快速開發方式，很多人被.Net的快速開發方式所滿足，認為自己“學成了”，不再深入研究，因此人才市場上充斥著很多只會拖控件、而不懂.Net更深入一步技術的.Net開發人員，比如很多 ASP.Net的書上都是講ASP.Net服務端控件，很多所謂“精通ASP.Net”的人連什么是Http、HTML、JavaScript、Dom等基本概念都稀里糊涂，實際公司項目中很多功能點的實現不是簡單的拖一個ASP.Net服務端控件就能搞定的，因此看似學習.Net的人非常多，但是真正滿足企業要求的人則比較少;而Java則入門門檻比較高，如果想要配置一個Hello World級別的學習環境就會涉及到很多技術，開發環境也要學習者自行配置，對于初學者來說可能花費一周時間都無法配置一個最簡單的環境出來，Java的開發環境也不像.Net開發環境那么可用性強，Java和.Net的區別就像Windows和Linux的區別，正因為Java學習門檻非常高，很多學習者被淘汰了下來，這樣能夠撐過一個個難關學習下來的開發人員都是水平比較高的人員。因此.Net初級開發人員的工資平均是比Java初級開發人員的工資平均略低的。但是由于.Net中高級人才非常缺乏，因此掌握.Net深入技術的開發人員在企業內部是非常吃香的，招聘人員經常發出這樣的感嘆“招合適的 Java工程師能招來一堆，招合適的.Net工程師一個月都招不來幾個”。
.Net入門快，在.Net中微軟為開發人員提供了一套最佳的技術架構搭配、集成的開發環境，用微軟的技術架構開發出的系統就可以保證最好的效果，而不用像Java開發人員那樣去學很多開源框架再去學習搭建技術架構、開發環境，因此.Net學習周期比Java短，有了語言基礎后再進行集訓式的就業班學習，那么.Net學習者學習3個月可以進入就業，Java學習者需要5個月可以進入就業。
]]>
| 以下內容含腳本,或可能導致頁面不正常的代碼 |
|---|
| 說明：上面顯示的是代碼內容。您可以先檢查過代碼沒問題，或修改之后再運行. |
Java基于GPL的開源確實來得不是時候，但幸好微軟在這時發布了他們的Vista。當Windows桌面的開發者面對著難用而且安全性存在缺陷C 或C++，他們紛紛轉向了Visual Basic。但在Vista上，微軟傾向于所有的桌面應用利用.Net管理代碼，這一策略收到了奇效。但在Linux桌面上，開發者仍在延用C或C++語言，這樣開發者就不得不面對令人棘手的安全問題和復雜的內存分配問題。很顯然，Linux桌面的開發者也需要一場類似的轉變，并且我們不得不說，這已是一場遲到的轉變。而當Linux桌面的開發者著手類似于Windows平臺的轉變時，他們會發現，他們面臨的只有兩個選擇；其中之一是由Novell所支持的Mono，另一個就是Java。
對我來說，更傾向于選擇Java出于以下幾方面的原因。首先，Java的發展時間比Mono長得多。盡管Mono成長迅速，但Java早在此之前已成為了一個穩定、成熟的平臺。其次，Java包含了許多大量的開源工具和庫文件。再次，Java擁有許多大型開發社區，并且在SourceForge上的開源項目大多數采用了Java做為開發語言。在FreshMeat.net的情況也大致此，采用Java開發的項目達到了5383個，而采用C#的只有 284個。此外，Mono還存在一個發展瓶頸，這就是它的更新必須要滯后于.Net平臺。而Java則是基于GPL發布的，隨時可以保持更新。在協議方面，Mono同樣存在一個陷阱，因為它的類庫是基于MIT協議發布的，因此軟件的開發者或所有者不能名正言順地為利用到庫的修正申請專利。
如果你對我的觀點持有異議，就還是請你原諒我對Java語言的偏愛吧。但我還是認為以上的觀點還是有客觀依據的，并且說明了Java將成為Linux桌面應用開發首選語言的主要原因。在開源平臺上利用Java卻有點名不正言不順的日子再也不會來了。
還有一點，Java與Linux將是一種互相促進的關系。桌面Linux希望在整個桌面市場上占有更大的市場份額，而Java能提高一個更高效、更安全、更容易排錯的開發平臺，并且利用這一平臺，開發出的應用同樣能跑在Windows上面。這不僅會促進Linux達成它的目標，還會最大可能地保護開發者的利益。從這個角度看，Java與桌面Linux可以說是天生的一對，地造的一雙。
]]>
| 以下內容含腳本,或可能導致頁面不正常的代碼 |
|---|
| 說明：上面顯示的是代碼內容。您可以先檢查過代碼沒問題，或修改之后再運行. |
（1）SUN的主流技術的發展
GUI界面：Java AWT API--〉Java Swing API
JavaWeb: Servlet--〉JSP--〉JSF
持久化層：JDBC--〉CMP EJB或BMP EJB或JDO
分布式應用：Socket--〉RMI--〉J2EE或Java Web Service
（2）主要Java開源軟件的種類
JavaWeb容器: Tomcat、Resin
EJB容器: JBoss
框架: Java Web框架（Struts）、業務邏輯層框架（Spring）
持久化層: DAO、ORM映射工具（如Hibernate、OJB）
工程管理工具：ANT、Eclipse
日志輸出工具: Log4J
JavaWeb服務工具:Apache Axis
促成Java世界如此絢麗多姿的基本動力在于以下核心思想：
接口與實現
不同的軟件系統之間通過接口來交互。軟件系統只對外公開接口，封裝實現細節。接口描述了軟件系統具備的功能，也就是指定軟件系統能夠做什么，但是沒有指明怎么去做。接口具有三大作用：
(1)對于接口制訂者：SUN公司通過定義接口，來制定新的軟件系統的規范，例如Servlet規范、EJB規范和JDO規范，這些規范主要以接口的形式描述了軟件系統必須具備的功能。通過制定規范，SUN公司指引著Java技術的發展方向，同時給接口的實現者提供了自由發揮的廣闊空間。
(2)對于接口實現者：接口實現者以特定的方式實現標準的規范。例如一些開放源代碼軟件，如Tomcat和Resin分別以不同的實現方式，實現了標準的Servlet規范。同一個接口允許有多種實現，使得Java領域保持著百花齊放、百家爭鳴的良好勢頭，
(3)對于接口調用者：接口調用者的程序具有良好的可移植性。以JavaWeb應用為例，由于Tomcat和Resin遵守同樣的規范，因此用戶開發的JavaWeb應用能夠順利的從Tomcat容器移植到Resin容器中。
封裝與抽象
封裝指的是在一個大系統中包含一個小系統，大系統是建立在已有小系統的基礎上的更為復雜、功能更強大的系統。例如，Hibernate對JDBC API進行了封裝，在Hibernate內部依賴JDBC API來操縱數據庫，但是Hibernate API比JDBC API具有更強大的功能，例如JDBC API只具有連接和操縱數據庫的功能，而Hibernate不僅具備這一功能，還具有對象-關系映射的功能。
抽象是指從已經存在的具有相似功能、但不同接口的系統中抽取共性，提煉出統一的接口。例如，Hibernate Transaction API是對JDBC
Transaction API和Java Transaction API（JTA）的抽象。
繼承與擴展
繼承與擴展是一對孿生兄弟，當兩個類之間存在繼承關系，那么必定也存在擴展關系。繼承的優點在于提高代碼的可重用性，子類會繼承父類的所有public和protected類型的屬性和方法，在子類的程序代碼中，無需重復定義這些屬性和方法。擴展的優點在于使軟件應用具有可伸縮性，能夠在已有功能的基礎上擴展新的功能。
Struts框架充分運用了擴展思想。Struts框架中的許多類都是供應用程序擴展的，其中最主要的一個是Action類，在Action類中已經定義了一些通用的方法，采用Struts框架的JavaWeb應用將擴展Action類，創建負責特定流程或業務的客戶化的Action類。
對象的生命周期
當一個對象通過new語句創建后，它就會擁有一塊固定的內存空間，如果沒有任何變量引用它，它就會結束生命周期，它占用的內存空間隨時可能被JVM的垃圾回收器回收。
應用程序如何管理對象的生命周期呢？目前比較流行的做法是把對象存放在一個“范圍”內。例如在JavaWeb應用中，JavaBean可以存放在request、session或application范圍內。每個范圍對應一個對象，例如request范圍對應HttpServletRequest對象，session范圍對應HttpSession對象，application范圍對應ServletContext對象。把一個JavaBean存放在request范圍內，實質上是在HttpServletRequest對象的一個集合屬性中加入這個JavaBean的引用，這個集合屬性也被稱為HttpServletRequest對象的緩存。
把一個JavaBean存放在request范圍內，等價于以下兩種說法：
把一個JavaBean加入到HttpServletRequest對象的緩存中
把一個JavaBean和HttpServletRequest對象關聯
當JavaBean位于request范圍內，這個JavaBean的生命周期依賴于HttpServletRequest對象的生命周期，當HttpServletRequest對象結束生命周期，并且這個JavaBean也不被應用程序中的其他變量引用，那么它就會結束生命周期。
那么HttpServletRequest對象本身的生命周期由誰管理呢？這是由JavaWeb容器（也稱Servlet容器）來管理的。對于每個HTTP請求，JavaWeb容器會自動創建一個HttpServletRequest對象，當HTTP請求的響應完畢，JavaWeb容器就會結束這個對象的生命周期。同理，當每個HTTP會話開始，JavaWeb容器會自動創建一個HttpSession對象，當這個會話結束，JavaWeb容器就會結束這個對象的生命周期；當每個JavaWeb應用啟動時，JavaWeb容器會自動創建一個ServletContext對象，當這個應用被關閉，JavaWeb容器就會結束這個對象的生命周期。
在Hibernate中，在net.sf.hibernate.Session范圍內加入一個持久化對象，實質上是在Session對象的集合屬性中加入這個持久化對象的引用。以下幾種說法是等價的：
在Session范圍內加入一個持久化對象
在Session的緩存中加入一個持久化對象
把一個持久化對象與Session關聯
值得注意的是，Hibernate的Session不僅能管理緩存中持久化對象的生命周期，還會負責按照持久化對象的狀態的變化，來同步更新數據庫。
集成開源軟件的基本步驟
在開發Java應用時，為了提高開發效率，縮短開發周期，常常需要集成第三方提供的Java軟件，如ORM映射工具Hibernate、MVC框架Struts、日志工具Log4J和Web服務軟件Apache
AXIS等。在自己的應用中集成這些第三方軟件時，大體步驟都很相似。
（1） 把它們的JAR文件拷貝到classpath中。
（2） 創建它們的配置文件（XML格式的文件或者Java屬性文件），這些配置文件通常也位于classpath中。
（3） 在程序中訪問它們的接口。
接口與配置文件，是軟件系統對外公開的兩個主要窗口。無論是Tomcat、Struts還是Hibernate，都離不開配置文件，與編寫程序代碼相比，配置文件能提高軟件的可維護性，更加靈活的適應用戶變化的需求，但是，配置文件不擅長表達非常復雜的邏輯，在這種情況下，必須求助于程序代碼。作為軟件使用者，如果僅僅想快速掌握一個新的Java軟件的使用方法，而不打算深入了解軟件內在原理和結構，無非就是了解它的接口以及配置文件的使用方法。當然，如果想對軟件的運用達到得心應手的地步，還應該了解軟件本身的實現原理和結構，而這些軟件無非就是通過抽象、封裝和實現等手段，從簡單的小系統出發，構造出更加復雜，但是對外有著簡潔統一的接口的大系統
import java.io.BufferedReader;
import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.PrintWriter;
import java.io.UnsupportedEncodingException;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.URLEncoder;
import java.util.Date;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Locale;
import java.util.Map;
import java.util.Properties;
import java.util.StringTokenizer;
import java.util.TimeZone;
/**
* A simple, tiny, nicely embeddable HTTP 1.0 server in Java
*
* This class has been trivially modified from its original form, taken from
* http://elonen.iki.fi/code/nanohttpd/NanoHTTPD.java
*
* <p> NanoHTTPD version 1.1,
* Copyright © 2001,2005-2007 Jarno Elonen (elonen@iki.fi, http://iki.fi/elonen/ )
*
* <p><b>Features + limitations: </b><ul>
*
* <li> Only one Java file </li>
* <li> Java 1.1 compatible </li>
* <li> Released as open source, Modified BSD licence </li>
* <li> No fixed config files, logging, authorization etc. (Implement yourself if you need them.) </li>
* <li> Supports parameter parsing of GET and POST methods </li>
* <li> Supports both dynamic content and file serving </li>
* <li> Never caches anything </li>
* <li> Doesn't limit bandwidth, request time or simultaneous connections </li>
* <li> Default code serves files and shows all HTTP parameters and headers</li>
* <li> File server supports directory listing, index.html and index.htm </li>
* <li> File server does the 301 redirection trick for directories without '/'</li>
* <li> File server supports simple skipping for files (continue download) </li>
* <li> File server uses current directory as a web root </li>
* <li> File server serves also very long files without memory overhead </li>
* <li> Contains a built-in list of most common mime types </li>
* <li> All header names are converted lowercase so they don't vary between browsers/clients </li>
*
* </ul>
*
* <p><b>Ways to use: </b><ul>
*
* <li> Run as a standalone app, serves files from current directory and shows requests</li>
* <li> Subclass serve() and embed to your own program </li>
* <li> Call serveFile() from serve() with your own base directory </li>
*
* </ul>
*
* See the end of the source file for distribution license
* (Modified BSD licence)
*/
public class NanoHTTPD
{
// ==================================================
// API parts
// ==================================================
/**
* Override this to customize the server.<p>
*
* (By default, this delegates to serveFile() and allows directory listing.)
*
* @parm uri Percent-decoded URI without parameters, for example "/index.cgi"
* @parm method "GET", "POST" etc.
]]>
因此 ,Java的誕生必將對整個計算機產業發生深遠的影響 ,對傳統的計算模型提出了新的挑戰。SUN MicroSystem公司的總裁 Scott McNealy認為 Java為 Internet和 WWW開辟了一個嶄新的時代。環球信息網 WWW的創始人 Berners-Lee說 :"計算機事業發展的下一個浪潮就是 Java,并且將很快會發生的"。
看來 ,使用 Java已成大勢所趨 !MicroSoft和 IBM兩大公司都計劃在 Internet上銷售用 Java編寫的軟件。
Apple、 HP、 IBM、 MicroSoft、 Novell、 SGI、 SCO、 Tandem等公司均計劃將 Java并入各自開發的操作系統 ,而負責開發并推廣 Java技術的 SunSoft公司 (這是 SUN下屬的一個子公司 ),將通過頒發許可證的辦法來答應各家公司把Java虛擬機和 Jav a的 Applets類庫嵌入他們開發的操作系統 ,這樣各類開發人員就能更輕易地選擇多種平臺來使用 Java語言編程 ,不同的用戶也就可以脫離 Web瀏覽器來運行 Java應用程序 ,這無疑是很受廣大用戶歡迎的 ,也為 Java語言的應用開拓了極為廣闊的前景。 (當然 ,各類 JavaOS之間的兼容性必須得到重視 ,好在 JavaSoft已保證將監督這種兼容性 )。
另外 ,由 JavaSoft推出的完全用 Java編寫的 Internet上新型瀏覽器HotJava,比去年 alpha版更為實用 ,不僅能編制動態的應用軟件 ,而且能編制完整的成套桌面應用軟件 ,將來還會提供更多的能幫助編制動態應用軟件的模塊 ,顯然 ,這也是為 Java的應用提供了有力的例證。
去年 6月 7日 ,由 SUN公司和臺灣經濟事務部信息發展局、臺灣信息技術研究所等單位牽頭 ,成立了一個"Java聯盟 ",參加的有 22個在臺灣相當聞名的計算機公司 ,并在臺北建立一個 "Java開發中心 ",在新竹建立一個"Java語言實驗室", 以掀起臺灣開發與應用 Java語言的熱潮。
香港則在去年 4月就舉行了全島的 Java杯比賽 ,在計算機界掀起了學習Java的熱潮 (尤其是在大學生們中 ,出現了一批 Java迷 )。
有人預言 :Java將是網絡上的 "世界語 ",今后所有的用其他語言編寫的軟件統統都要用 Java語言來改寫。
二、 Java語言對軟件開發技術的影響
工業界不少人預言 :"Java語言的出現 ,將會引起一場軟件革命 ",這是因為傳統的軟件往往都是與具體的實現環境有關 ,換了一個環境就需要作一番改動 ,耗時費力 ,而 Java語言能在執行碼 (二進制碼 )上兼容 ,這樣以前所開發的軟件就能運行在不同的機器上 ,只要所用的機器能提供 Java語言解釋器即可。
Java語言將對未來軟件的開發產生影響 ,可從如下幾個方面考慮 :
1 軟件的需求分析:可將用戶的需求進行動態的、可視化描述 ,以提供設計者更加直觀的要求。而用戶的需求是各色各樣的 ,不受地區、行業、部門、愛好的影響 ,都可以用 Java語言描述清楚。
2 軟件的開發方法:由于 Java語言的面向目標的特性 ,所以完全可以用 O-O 的技術與方法來開發 ,這是符合最新的軟件開發規范要求的。
3 Java語言的動畫效果遠比 GUI技術更加逼真 ,尤其是利用 WW W提供的巨大動畫資源空間 ,可以共享全世界的動態畫面的資源。
4 軟件最終產品:用 Java語言 開發的軟件可以具有可視化、可聽化、可操作化的效交互、動畫與動作 ",要它停就停 ,要它繼續就繼續 ,而這是在電影與電視播放過程中難以做到的。
5 其它:使用 Java語言對開發效益、開發價值都有比較明顯的影響。 三、工業界對 Java語言的評價
1996年 5月 29～ 31日 ,在美國舊金山召開了一個全世界 Java語言開發者大會 ,(JavaOne Developer Confer-ence),出席會議的多達 6500多人 ,來自工業界的超過一半 ,有人評價說 :"這是近年來計算機界最光輝的一次盛會 ",一些工業界的老總們相當看好 Java語言 ,認為它的使用將會引起一場軟件革命。從軟件的設計風格、設計方法、設計目標到設計過程 ,都會產生徹底的變革 ,"甚至會改變此星球的生活方式 "。
在這次會上 ,Java的創始人之一 James Gosling說 :"Java不僅僅只是applets,它能做任何事情 ",Dta咨詢公司的高級軟件工程師 Rich Kadel說 :"Java不僅僅是一種程序設計語言 ,更是現代化軟件再實現的基礎 ;Java還是未來新型OS的核心 ;將會出現 Java芯片 ;將構成各種應用軟件的開發平臺與實現環境 ,是人們必不可少的開發工具 ,……"。
由于各界都看好它 ,因此 ,各大公司都紛紛表示支持 Java, Intel、Xerox公司聲言將把 Java嵌入到他們的產品中去。就連華爾街金融界也在投入資金人力用 Java開發電子貿易、金融軟件。
所以有人說 :"現在第三方的開發商都團結在 Java大旗四周了 !",紛紛推出用 Java開發的各種軟件產品 ,以期盡快地占領市場。
四、 Java語言的應用前景
Java語言有著廣泛的應用前景 ,大體上可以從以下幾個方面來考慮其應用；
1 所有面向對象的應用開發 ,包括面向對象的事件描述、處理、綜合等；
2 計算過程的可視化、可操作化的軟件的開發；
3 動態畫面的設計 ,包括圖形圖像的調用；
4 交互操作的設計 (選擇交互、定向交互、控制流程等；
5 Internet的系統治理功能模塊的設計 ,包括 Web頁面的動態設計、治理和交互操作設計等；
6 Intranet(企業內部網 )上的軟件開發 (直接面向企業內部用戶的軟件；
7 與各類數據庫連接查詢的 SQL語句實現；
8 其它應用類型的程序。
]]>
Gutmans的這篇文章在技術界引發了強烈爭議，很對人對此有不同的意見，我在這里就闡述一下我對PHP和Java兩種語言的看法。
首先對比一下PHP和Java的異同，PHP是一種解釋執行的腳本語言，語法和C語言類似，易學易用，不懂電腦的非專業人員稍經學習也能使用PHP.而Java要先編譯成Class文件，然后在Java虛擬機上執行，Java開發需要熟悉Java語法以及一些核心的架構，從而實現一種可復用的、跨平臺的軟件，Java比PHP要難學的多。
實際上，從技術架構來說，Java語言相比PHP有明顯的優勢，Java使用的是面向對象的系統設計方法，而PHP還是采用面向過程的開發方法。PHP只能實現簡單的分布式兩層或三層的架構，而JAVA可以實現多層架構。數據庫層（持久化層）、應用（業務）邏輯層、表示邏輯層彼此分開，而且現在不同的層都已經有一些成熟的開發框架的支持。例如Struts就是利用Java的web開發技術實現了MVC的設計模式，而在業務邏輯層也有Spring框架，數據庫持久化層有Hibernate等框架。這些框架可以方便開發者高效、合理、科學得架構多層的商業應用。從數學運算和數據庫訪問速度來講，Java的性能也優于PHP.實際上，對于跨平臺的大型的企業應用系統來講，Java幾乎已經成為唯一的選擇（微軟.NET不支持跨平臺），但是在于Web網站應用開發來講，Java卻面臨著被PHP邊緣化的危險，幾乎所有的虛擬主機都支持PHP+MySQL，而支持Java的卻少之又少，在資源上，網上有不計其數的PHP資源，很多著名的大型網站（例如Facebook、Mediawiki等）都是基于PHP的，而成功的Java網站卻寥寥無幾，這又是什么原因呢？
Java的理念是“一次編寫，到處運行”，Java在應用框架底下的架構是無與倫比的，遠勝過其他任何語言，Java的框架利于大型的協同編程開發，系統易維護、可復用性較好。而PHP很容易自學，讓熱備能快速簡潔地編寫代碼，適合于快速開發，中小型應用系統，開發成本低。在調試、發布上，PHP也較Java簡單。
理念上的不同導致了Java和PHP在Web應用開發上顯示了不同的結果，盡管Java的數學計算和數據庫訪問都有優勢，架構也相當完美，但是PHP卻可以簡單輕松地支持高強度Web訪問，能夠快速開發應用，支持PHP的虛擬主機多如牛毛，使得用PHP開發一個網站比用Java開發一個網站要快得多，容易的多。Java所擁有的優點只適合傳統的以軟件項目為核心的開發模式，而PHP更適合于以客戶為核心的SaaS的開發模式，因此，PHP目前在Web網站開發的優勢完全是因為Web網站開發的特殊性而導致的，并非編程語言特性所決定。
因此，PHP在Web網站開發語言的戰爭中已經慢慢將Java拋在了后面，Java要想在Web網站開發上奮起直追，的確應該多聽聽Andi Gutmans的意見，徹底改變一下思路才行，否則兩者的差距只能是越來越遠。
另外，雖然在國際上LAMP（Linux+Apache+Mysql+Php）架構已經占領了統治地位，但是在中國國內還有一個怪胎，就是基于微軟的Windows Server+IIS+SqlServer+ASP/ASP.NET的架構，從理論上說，微軟的這一套架構也能實現不錯的性能，只可惜Windows和SqlServer價格不菲，整個架構在性能上比起LAMP不僅沒有什么優勢，反而還有不少劣勢，因此微軟的這一套家伙在國際市場上吃不開。而國內使用微軟盜版則可以忽略成本，而ASP的易學易用性不遜于PHP，甚至連IT外行都能夠使用，因此在國內也有不小的市場。但是隨著中國在保護知識產權方面的日趨完善，免費的LAMP依舊是未來的趨勢。
<iframe id="google_ads_frame1" style="LEFT: 0px; POSITION: absolute; TOP: 0px" name="google_ads_frame" marginwidth="0" marginheight="0" src="http://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-1076724771190722&output=html&h=60&slotname=5506163105&w=468&lmt=1292033497&flash=10.1.102.64&url=http%3A%2F%2Fmorris.javaeye.com%2Fblog%2F188327&dt=1292033497218&shv=r20101117&jsv=r20101209&saldr=1&correlator=1292033497296&frm=0&adk=2738616005&ga_vid=236802693.1292033497&ga_sid=1292033497&ga_hid=1861103146&ga_fc=0&u_tz=480&u_his=0&u_java=1&u_h=768&u_w=1024&u_ah=738&u_aw=1024&u_cd=32&u_nplug=0&u_nmime=0&biw=994&bih=589&ref=http%3A%2F%2Fwww.baidu.com%2Fs%3Fwd%3DJAVA%25D3%25EF%25D1%25D4%25BF%25AA%25B7%25A2%25BC%25BC%25CA%25F5%26pn%3D110&fu=0&ifi=1&dtd=657&xpc=aTAMl37CFY&p=http%3A//morris.javaeye.com" frameborder="0" width="468" scrolling="no" height="60" allowTransparency="allowTransparency"></iframe>]]>
下面為避免混淆，在文中凡未加特殊說明的Java，統指桌面Java而言。
一、 問題提出
*常用的解釋性Java(Java Applet)的執行速度慢，不適于嵌入式的應用。
*Java要求過大的內存。
*嵌入式設備要求操作硬件。因Java廢棄了C語言所使用的指針，且在Web環境下使用了Java虛擬機（JVM），使Java無力直接甚至間接地用指針操作硬件。
*Java使用一些自動功能會引起執行時間的不確定性，成為嵌入式的大忌。如垃圾自動收集器。本是對于C的重大改進，但卻因程序自動地回收垃圾，從而引入了實時的時間不確定性。
二、解決方案
使用AOT編譯器
為解決解釋性Java(Java Applet)執行速度過慢的問題，發展了AOT（ahead-of-time）編譯器。大家喜歡在Internet上使用Java的一個原因是其字節碼具有跨平臺性，即同一Java代碼可以運行于PC、Mac、Solaris，甚至于主機之上。為此，在英文叫它WORA（寫一次即可通行于任意機）。這是因為每一操作系統平臺上都有符合自己機型的專用Java虛擬機（JVM），由它對字節碼進行解釋運行。因為解釋程序需先被解釋再被執行，多了解釋環節，延誤數秒鐘時間。如果是撥打電話，這個時間足以令人生厭。現在使用AOT（ahead-of-time）超前編譯器，提前將解釋碼轉換為本平臺所用的并經優化過的二進制碼，速度提高很多。現有Cygnus公司聲稱，它開發的AOT編譯器執行速度是原解釋程序的8倍。NewMonics說它的 QuickPERC編譯器是原解釋程序的20倍。當然，AOT編譯器也有不足，就是他犧牲了Java的WORA。
減少內存的占用
所有的面向對象語言，比C及匯編語言點用內存都多。這個問題對于桌面系統早已不再是考慮的因素了，如服務器平均占用數GB的內存已司空見慣。但是，對于嵌入式系統卻不能不考慮。用Java開發的信息家電產品可能需要把內存限制到512KB以下。如果嵌入式系統使用的是規模為1MB的核心類庫，那就是說，一句代碼尚未寫，內存早就不夠用了。
為此，需要把用不到的類、類方法和代統統從程序中剔除。（AOT超前編譯器可以幫助解決這個問題。）再就是自己開發本平臺專用的，既短小高效、又符合Java API標準的Java核心類庫。
開發能混合編程的IDE
一般認為，用C語言寫的程序，指鍺使用不當引起的缺陷占總缺陷的80%左右。Java語言，出于安全的考慮，才廢棄了使用指針。但是，指針卻能夠最直接地訪問到存儲器和真實的硬件。現在，為在嵌入式Java中能夠訪問到硬件，不得不改用本地接口，即從嵌入式Java中利用能夠訪問到硬件的C語言函數來實行交叉編程。這就意味著增加了復雜性。開發人員需要具備多語言以及多層次的混合編程和混合調試的能力。發展多語言多層次混合編程的IDE，無疑十分有助于一般開發人員完成這一相當復雜的課題。Metrowerks的CodeWorrior和IBM的VisualAge就是新開發的基于J2ME的這樣的IDE。
克服時間的不確定性
Java 最主要的問題是時間不確定性，主要來源于存儲器殘渣的自動收集再生器。這種垃圾收集再生器工作的時候，自動地決定何時停下其他程序的執行，再根據當時殘渣的實際情況或長或短地完成任務。所以，它嚴重地干擾實時應用所要求的時間確定性。為解決這一問題，不同公司采用不同的方法和垃圾收集的算法。 NewMonics的Real Time Executives和Windriver的FastJ都是保證絕對的確定時間，Sun公司用不同的辦法但也保證具有實時的確定性。采用不同的編程技巧，譬如使用類型確定的線程局部存儲，也可以避免因垃圾收集引發的沖突。
需保持跨平臺的必要
AOT 編譯器生成的Java代碼喪失了Java在其他操作平臺上的執行能力。要想把Java的源代碼再向其他平臺移植，需要附加很大的勞動。面向對象的一個基本設計原理就是只要保持接品不變，那么，與接口交談的代碼在移植時就不受影響。所謂高級邏輯接口的隔離手法，事實上，就是將平臺敏感的內容同移值無關的代碼分離開來，并且分別提供同樣功能的平臺敏感程序。現在，針對嵌入式Java，目前還沒有人做這項工作。
三、實際應用
Java是良好的嵌入式編程語言嗎？
還不能這么說，至少現在是這樣。因為在嵌入式系統中，Java如何應用要看具體情況而定。對于需要管理中斷來完成重要任務的應用系統，就不宜于選用Java 進行開發，譬如引導登外星的飛行器系統就是這樣。對于要求輕型、高效、任務重要、時間確定性要求極高的系統，也是只能局限于使用C語言和匯編。比如，點燃登陸外星的制動火箭系統，定時通過串行口獲取關鍵信息一邊做出決定的系統，定時報告航天器方位的系統等都不能使用Java。但是，需要不斷與他人通信聯系，以便對貨運進行有效管理的手持系統，又最適合使用Java編程。因為，它既發揚了Java Applet固有的跨平臺應用地Web環境的特點，又能充分利用服務器端的現成軟件。
使用Java有時也并不完全取決于技術
立足于經濟上的考慮，比單獨的技術考慮更為重要。譬如，對于服務器，為了支持使用Java，寧愿多花費數千元擴大存儲器是正確的。因為，從投入/產出的分析也得出同樣的結論。又如手機，若為支持使用Java，哪性僅只需要多花一元錢去擴大存儲器也是不可行的。因為，手機的生產是以行百萬件的產量來考慮的，多花一元線，就意味著多花千百萬元，諾大的數字遠比技術的先進更為重要，是顯而易見的。
實施嵌入式Java時需注意
Java 用于嵌入式還是瓣生事物，需要探路前進，摸著石頭過河，忌冒進和全面開花。應試探性地從使用現成的嵌入式J2ME開始，在它的通用性的開發環境下運行本平臺的字節碼。盡可能地順著J2MME向前走，盡可能地順著J2ME向前走，盡可能地走得遠一點，只有在遇到特殊問題時才導求新的解決辦法。新方法的采用并不一定能夠解決問題，比如，AOT或半自動的垃圾收集器等可能并沒有解決你的問題，也勿驚慌，要總結經驗做出評價，繼續前進，使嵌入式Java日罄完善。
要重視IDE的選用，好的IDE絕對是良好的助手。否則，你是單槍匹馬，披荊斬棘，艱苦良多。
]]>軟件是有生命的，這可能是老調重彈了，但是因為它事關分層架構的原由，反復強調都不過分。
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構，其次才是完整的功能。
目前很多人對軟件的思想還是焦點落在后者：完整的功能，覺得一個軟件功能越完整越好，其實關鍵還是架構的靈活性，就是前者，基礎架構好，功能添加只是時間和工作量問題，但是如果架構不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長時，更多功能需要加入，但是因為基礎架構不靈活不能方便加入，死路一條。
正因為普通人對軟件存在短視誤區，對功能追求高于基礎架構，很多吃了虧的老程序員就此離開軟件行業，帶走寶貴的失敗經驗，新的盲目的年輕程序員還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟件，擴展性以及持續發展性嚴重不足。
那么選擇現在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢?其實還不盡然，關鍵還是取決于你如何使用這些框架來搭建你的業務系統。
存儲過程和復雜SQL語句的陷阱
首先談談存儲過程使用的誤區，使用存儲過程架構的人以為可以解決性能問題，其實它正是導致性能問題的罪魁禍首之一，打個比喻：如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫療方案就全部失效，請問你會使用這種短視方案嗎?
為什么這樣說呢?如果存儲過程都封裝了業務過程，那么運行負載都集中在數據庫端，要中間J2EE應用服務器干什么?要中間服務器的分布式計算和集群能力做什么?只能回到過去集中式數據庫主機時代。現在軟件都是面向互聯網的，不象過去那樣局限在一個小局域網，多用戶并發訪問量都是無法確定和衡量，依靠一臺數據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環境的。(當然搞數據庫集群也只是五十步和百步的區別)。
從分層角度來看，現在三層架構：表現層、業務層和持久層，三個層次應該分割明顯，職責分明：持久層職責持久化保存業務模型對象，業務層對持久層的調用只是幫助我們激活曾經委托其保管的對象，所以，不能因為持久層是保管者，我們就以其為核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做復雜的業務組合。打個比喻：你在火車站將水果和盤子兩個對象委托保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給你，合理嗎?
上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠占業務層，腐蝕業務層，整個業務層到處看見的是數據表的影子(包括數據表的字段)，而不是業務對象。這樣程序員應該多看看OO經典PoEAA。PoEAA 認為除了持久層，不應該在其他地方看到數據表或表字段名。
當然適量使用存儲過程，使用數據庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和存儲過程作為規則Specification一部分。
Hibernate等ORM問題
現在使用Hibernate人也不少，但是他們發現Hibernate性能緩慢，所以尋求解決方案，其實并不是 Hibernate性能緩慢，而是我們使用方式發生錯誤：
“最近本人正搞一個項目，項目中我們用到了struts1.2+hibernate3, 由于關系復雜表和表之間的關系很多，在很多地方把lazy都設置false，所以導致數據一加載很慢，而且查詢一條數據更是非常的慢。”
Hibernate是一個基于對象模型持久化的技術，因此，關鍵是我們需要設計出高質量的對象模型，遵循DDD領域建模原則，減少降低關聯，通過分層等有效辦法處理關聯。如果采取圍繞數據表進行設計編程，加上表之間關系復雜(沒有科學方法處理、偵察或減少這些關系)，必然導致 系統運行緩慢，其實同樣問題也適用于當初對EJB的實體Bean的CMP抱怨上，實體Bean是Domain Model持久化，如果不首先設計Domain Model，而是設計數據表，和持久化工具設計目標背道而馳，能不出問題嗎?關于這個問題N多年就在Jdon爭論過。
關于本系列
PHP 是一種非常優秀的 Web 開發語言，而在商業應用程序開發方面，Java 編程語言十分流行。因此，為了在 AIX Version 5.3 操作系統上充分利用它們的優勢，專門開發了 PHP Java Bridge。本系列文章向 AIX 5.3 開發人員介紹了如何在他們的 Web 應用程序開發中集成 PHP 和 Java 技術。
為了說明這一點，您將按照典型的開發過程來構建一個簡單的問卷調查應用程序，具體內容包括：
開發主要的 Java 應用程序
通過 Servlet 將 Java 應用程序公開為基于 Java 的 Web 應用程序
添加在數據庫中存儲信息的支持
將原始應用程序公開為 Web Services，并為該應用程序提供 PHP 接口
使用專門的 PHP Java Bridge 重新開發 PHP 接口
本系列文章共分為六個部分：
第 1 部分介紹了一個應用程序，并為構建 Java 應用程序以及使用 Tomcat 執行基于 Java 的 Web 應用程序搭建了相應的環境。
第 2 部分介紹了主要的應用程序代碼以及一個簡單的 Java Servlet 的開發，以便為信息提供一個 Web 接口。
第 3 部分將核心應用程序連接到 DB2? 數據庫，以便對問卷調查的問題和回答進行存儲。
第 4 部分對原始應用程序進行轉換，使其能夠作為 Web Services 進行訪問，并且它為 PHP 接口提供了基礎。
第 5 部分使用 PHP Java Bridge 為 Java 應用程序構建 PHP 接口。
第 6 部分對這個應用程序進行重新開發，以便使用 PHP Java Bridge 來代替 Web Services 接口。
關于本教程
本教程是這個系列文章的最后一個部分，在本教程中，您將了解如何組合使用 PHP 和 Java 技術，以便為支持問卷調查應用程序的原始 Java 類構建 Web 接口。這個最終解決方案使用 PHP Java Bridge 以使得您可以為在本系列文章的前面幾個部分中所開發的 Java 類構建基于 PHP 的接口。
您首先將了解 PHP Java Bridge、以及它的操作與最初開發的 Web 服務方法之間的區別，從而對這幾種不同的技術進行比較。然后，在研究原始 Java 類的 PHP 接口的最終備選方法之前，您將研究幾種不同的集成您的基于 PHP 和 Java 的解決方案。
先決條件
為了學習本教程，您需要安裝下列軟件：
IBM pSerIEs? 服務器（本文中的代碼使用 AIX Version 5.3 進行了測試。）
Apache Tomcat 系統
Eclipse IDE
Java 5 64-bit SDK（要下載這個包，您需要進行注冊，但注冊是免費的。）
Mozilla Web browser for AIX
幾種不同連接技術的比較
問卷調查應用程序所使用的 Web 服務方法為您提供了極大的靈活性，而 PHP Java Bridge 以不同的方式提供了類似的靈活性。在您更深入地研究開發過程之前，讓我們更仔細地分析一下它們之間的區別和相似之處。
Web 服務方法
您對原始應用程序進行了轉換，這樣一來，在本系列文章的第四部分中（請參見參考資料），就可以將其作為 Web Services 進行訪問。除了可訪問性之外，Web Services 模型還具有許多其它的優點。通過 Web Services 接口來公開類，您可以保證互操作性，因為幾乎所有的語言都支持某些形式的 Web Services ，無論是 XML-RPC 還是簡單對象訪問協議 (SOAP)。
這也就帶來了極大的靈活性。現在，您的 Java 后端可以由采用 C、Perl、Java 語言、PHP、JavaScript 和許多其他編程語言所編寫的腳本和應用程序來進行訪問；然而，實現互操作性是要付出一定代價的。
正如您在本系列文章的第四部分中所看到的，將您的應用程序公開為 Web Services 是一項復雜的任務。要正確地完成這項工作，需要通過 Web 服務描述語言 (WSDL) 文件開發和部署您的代碼；然后，您必須單獨地為每個函數定義不同的接口，同時還需要確保采用與您希望使用的標準可互操作的格式，對所提供的值和返回的值進行編碼和封裝。
在您為核心類開發和添加新的功能和擴展時，所有的這些工作都需要花費大量的時間進行開發、以及較長的時間進行控制。要使得原始類能夠通過 Web 服務接口進行訪問，可能會使得您的開發時間增加 20% 到 50%。
而且，正如稍后將更詳細地進行介紹的，Web 服務方法還隱含了不容忽視的顯著性能開銷（如果您希望在大型操作環境中部署該應用程序的話）。
PHP Java Bridge
在本系列文章的第五部分中，您詳細地了解了 PHP Java Bridge（請參見參考資料），但是 PHP Java Bridge 的關鍵元素允許您直接從 PHP 內部訪問 Java 類，就好像您正在訪問本地 PHP 類一樣。
盡管 Web 服務和 PHP Java Bridge 接口在本質上存在很大的差別，但事實上，它們都使用 XML 進行通信，以交換有關原始方法和類、以及應該如何對它們進行訪問的信息。與 Web 服務解決方案有所不同，這個過程是自動的。
正如您在第五部分中所看到的（請參見參考資料）、以及本文清單 1 中所介紹的，在您導入 PHP 元素、并且創建到遠程 Java 主機的連接之后，使用和創建 Java 類和對象是非常簡單的。
清單 1. 簡單的 PHP Java Bridge 的示例| <? require_once("http://sulaco.mcslp.pri:8080/JavaBridge/java/Java.inc"); $System = new Java("java.lang.System"); print_r($System->getProperties); ?> |
在本教程后面的內容中，您將研究所需的確切的方法和解決方案。
區別和相似之處
Web Services 和 PHP Java 解決方案之間存在許多明顯的區別和相似之處，從而使得采用這兩種方法開發和部署應用程序時具有相應的優點和缺點。
例如，Web 服務和 PHP Java Bridge 解決方案都允許您使用 PHP 作為前端、使用 Java 環境作為應用程序的后端部分。對于 Web 服務解決方案，您必須開發原始類、Web 服務類和 PHP 接口。對于 PHP Java Bridge，您只需要開發原始 Java 類和 PHP 前端，PHP Java Bridge 可以為您處理所有的互操作性問題。
在 Web 服務和 PHP Java Bridge 解決方案之間還存在一個比較顯著的區別，即完成解決方案所需的步驟有所不同。Web 服務解決方案需要額外的開發時間，以使用所需的 Web 服務接口來公開服務、并使得它們可供使用。在 PHP 中使用 Web 服務也是相當繁瑣的，因為您必須開發一個能夠為已開發的 Web 服務接口提供接口的解決方案。
對于 PHP Java Bridge，您可以直接訪問現有的 Java 類，而不必在 Java 端顯式地開發接口、或者在 PHP 端顯式地開發訪問接口。
性能
為了將您的原始請求轉換為完全與平臺無關的形式，使用 Web 服務的關鍵問題之一是必須將請求轉換為 XML。所得到的 XML 數據包中包括請求、源或目標信息、以及請求中所包含的任何數據或者信息（例如，方法或函數的參數），這使得 XML 組件的負載變得非常大。
采用這種方式生成有效的 XML 是相當花費時間的，但是對該信息進行解碼甚至可能需要花費更多的時間，因為 XML 解析的過程并不像您所預期的那么簡單和直接。和發送請求到服務器的客戶端的負載相比，這個處理過程會呈現更高的負載，隨后還會有接受請求和最后處理請求的過程。在將響應發送回客戶端的時候，將按相反的順序執行相同的處理過程（采用 XML 對響應進行編碼，發送到客戶端，客戶端解析 XML 并且提取響應）。
您可以在圖 1 中更詳細地看到這個過程。
圖 1. 實際應用中的 Web 服務接口 ]]>一、ODBC到JDBC的發展歷程
說到JDBC，很容易讓人聯想到另一個十分熟悉的字眼ODBC。它們之間有沒有聯系呢？如果有，那么它們之間又是怎樣的關系呢？
ODBC是OpenDatabaseConnectivity的英文簡寫。它是一種用來在相關或不相關的管理系統（DBMS）中存取數據的，用C語言實現的，標準應用程序數據接口。通過ODBCAPI，應用程序可以存取保存在多種不同管理系統（DBMS）中的數據，而不論每個DBMS使用了何種數據存儲格式和編程接口。
1．ODBC的結構模型
ODBC的結構包括四個主要部分：應用程序接口、驅動器管理器、驅動器和數據源。
應用程序接口：屏蔽不同的ODBC驅動器之間函數調用的差別，為用戶提供統一的SQL編程接口。
驅動器管理器：為應用程序裝載驅動器。
驅動器：實現ODBC的函數調用，提供對特定數據源的SQL請求。如果需要，驅動器將修改應用程序的請求，使得請求符合相關的DBMS所支持的文法。
數據源：由用戶想要存取的數據以及與它相關的操作系統、DBMS和用于DBMS的網絡平臺組成。
雖然ODBC驅動器管理器的主要目的是加載驅動器，以便ODBC函數調用，但是驅動器本身也執行ODBC函數調用，并與相互配合。因此當應用系統發出調用與數據源進行連接時，驅動器能管理通信協議。當建立起與數據源的連接時，驅動器便能處理應用系統向DBMS發出的請求，對分析或發自數據源的設計進行必要的翻譯，并將結果返回給應用系統。
2．JDBC的誕生
自從Java語言于1995年5月正式公布以來，Java風靡全球。出現大量的用java語言編寫的程序，其中也包括應用程序。由于沒有一個Java語言的API，編程人員不得不在Java程序中加入C語言的ODBC函數調用。這就使很多Java的優秀特性無法充分發揮，比如平臺無關性、面向對象特性等。隨著越來越多的編程人員對Java語言的日益喜愛，越來越多的公司在Java程序開發上投入的精力日益增加，對java語言接口的的API的要求越來越強烈。也由于ODBC的有其不足之處，比如它并不容易使用，沒有面向對象的特性等等，SUN公司決定開發一Java語言為接口的應用程序開發接口。在JDK1．x版本中，JDBC只是一個可選部件，到了JDK1．1公布時，SQL類包（也就是JDBCAPI）就成為Java語言的標準部件。
二、JDBC技術概述
JDBC是一種可用于執行SQL語句的JavaAPI（ApplicationProgrammingInterface，應用程序設計接口）。它由一些Java語言寫的類、界面組成。JDBC給應用開發人員、前臺工具開發人員提供了一種標準的應用程序設計接口，使開發人員可以用純Java語言編寫完整的應用程序。
通過使用JDBC，開發人員可以很方便地將SQL語句傳送給幾乎任何一種。也就是說，開發人員可以不必寫一個程序Sybase，寫另一個程序Oracle，再寫一個程序Microsoft的SQLServer。用JDBC寫的程序能夠自動地將SQL語句傳送給相應的管理系統（DBMS）。不但如此，使用Java編寫的應用程序可以在任何支持Java的平臺上運行，不必在不同的平臺上編寫不同的應用。Java和JDBC的結合可以讓開發人員在開發應用時真正實現WriteOnce，RunEverywhere！
Java具有健壯、安全、易用等特性，而且支持自動網上下載，本質上是一種很好的應用的編程語言。它所需要的是Java應用如何同各種各樣的連接，JDBC正是實現這種連接的關鍵。
JDBC擴展了Java的能力，如使用Java和JDBCAPI就可以公布一個Web頁，頁中帶有能遠端的Ap?plet。或者企業可以通過JDBC讓全部的職工（他們可以使用不同的操作系統，如Windwos，Machintosh和UNIX）在In?tranet上連接到幾個全球上，而這幾個全球可以是不相同的。隨著越來越多的程序開發人員使用Java語言，對Java易操作性的需求越來越強烈。
MIS管理人員喜歡Java和JDBC，因為這樣可以更容易經濟地公布信息。各種已經安裝在中的事務處理都將繼續正常運行，甚至這些事務處理是存儲在不同的管理系統中；而對新的應用來說，開發時間將縮短，安裝和版本升級將大大簡化。程序員可以編寫或改寫一個程序，然后將它放在服務器上，而每個用戶都可以服務器得到最新的版本。對于信息服務行業，Java和JDBC提供了一種很好的向外界用戶更新信息的方法。
1．JDBC的任務
簡單地說，JDBC能完成下列三件事：
1）同一個建立連接；
2）向發送SQL語句；
3）處理返回的結果。
]]>1996年7月-1999年10月3年時間一直使用C語言編寫電信協議軟件，算作我的C語言時代。其中還使用過一段時間SDL語言和基于SDL的代碼自動生成工具（瑞典Telelogic公司的SDT）。
2000年3月-2000年10月7個多月時間使用Perl語言做網站開發，算作我的Perl語言時代。后來轉向了使用Java和JSP，用了兩個月。
2001年2月-2001年8月6個月時間使用JavaScript做DHTML開發，還使用ColdFusion做網站開發。
2001年12月-2001年6月7個月時間使用C語言做企業級郵件服務器開發。
2002年8月之后做開發一直使用Java語言至今，算作我的Java語言時代，算算已經快5年了。
在我使用過的這些語言中，有3種語言對我的影響最大，那就是C、Perl和Java。當然JavaScript對我的影響也很大，不過對于整體的應用軟件開發來說，JavaScript并不是一個主角。
現在我正在經歷一次新的技術轉型，從Java語言轉向Ruby語言和Rails框架。
如果說以前的幾次技術轉型都是因為工作的變動而導致的，那么這一次技術轉型則是我自己主動發起的，因為我感覺Ruby代表著應用軟件開發技術（注意限定詞 “應用軟件”）的未來。Ruby是一種比Java更加先進的應用軟件開發語言，最重要的是它能夠帶來極高的開發效率，而且不會影響代碼的可讀性和可維護性。
一年多以前我對Java還抱有一些幻想，認為Java社區如果有更好的框架，開發效率一定會追上Rails。今年5月我讀了 Bruce A. Tate的《超越Java》這本書，希望從專家那里了解一下Java語言和Java社區到底出了什么問題。這本書打消了我的幻想，讓我理解了Java最大的問題在于靜態類型對開發效率造成的嚴重影響。聯想到我去年下半年做的那個廣告發布平臺，我對此深有感觸。我當時所采用的框架是Spring MVC+Spring IoC+Hibernate+FreeMarker+SiteMesh，按理說在Java開發領域，這套組合的開發效率應該算是比較高的了。然而實際的開發進度遠遠低于我的預期，我作出第一個版本的時間差不多是預計時間的兩倍。當然因為資金的缺乏，大部分時間都只有我一個人在做開發，什么都要親自動手，困難確實很多。不過我認為主要的問題還是在于Java語言做Web開發的笨拙。
因為資金的缺乏，我今后要做一些自己感興趣的東西，注定仍然只會有很少的人參與（2、3個人），Java這樣笨拙的語言可能會使我付出雙倍的代價。
當然，Java語言仍然在發展和變化，但是它變的越來越復雜，越來越缺乏一致性，最終很可能會發展成為像C++那么復雜的一種語言。Java越來越不適合Web應用的開發了（我說的比較謹慎是因為這個領域是我最熟悉的），是到需要尋找一種新的開發語言的時候了。
Rod Johnson確實很偉大，在參與翻譯了《J2EE without EJB》之后，我至今仍然對Rod Johnson對于JavaEE的偉大貢獻深感敬意。但是Spring是從企業應用環境成長起來的，它對于面向Internet的Web應用來說，仍然是太重了。而Web 應用的很多重要的需求（例如對Ajax的支持、對REST的支持等等），Spring并沒有解決。做企業應用，Spring仍然是很好的選擇，然而做Web應用，Spring，甚至是Java語言本身，都不是很好的選擇。為何在Web應用開發技術方面，PHP最終占據了第一的份額，這是很值得思考的。
我們以前做網站開發從Perl語言轉向了Java語言，主要的原因有以下這些：
1. Perl開發的應用代碼量大了之后很難維護。我自己寫過一個4、500行的復雜Perl程序，過了兩個月后再讀居然都讀不懂了。
2. Perl這個工具最初是設計用來取代bash、awk、sed等工具的，因為Larry Wall覺得這些工具還不夠強大靈活。Perl最初并不是設計用來作為一種全功能的應用軟件編程語言的。
3. Perl對面向對象編程支持的并不好。
4. 對于Web開發來說，Perl的資源（開發框架、開發庫）沒有Java豐富，很多功能需要自己來開發。
5. CGI開發與支持session的Servlet/JSP開發相比太原始，開發難度太大。
所以我們有非常充足的理由轉向Java語言。還有一個不大好開口的理由就是，做Java開發當時似乎是成為一個專業程序員的標志，純粹的面子問題，當然Java程序員的就業前景也要好的多。
但是轉向Java之初最強烈的感覺就是Java做一些與文本處理相關的工作非常麻煩，沒有Perl快捷，而這些工作對于開發Web應用來說是很常見的。當時 Java核心類庫甚至還不支持正則表達式，需要下載學習其他的開發包，直到JDK1.4之后Java核心類庫才開始支持正則表達式。不過JSP這樣與 ASP、PHP類似的服務器頁面技術是比CGI要先進一代的技術，所以開發效率還是比寫Perl CGI有所提高。
我做了一段時間JSP 開發，發現全部代碼都混在頁面中問題很多，于是開始學習Java Web開發的Model1和Model2，并且接觸到了當時剛剛興起的Struts。不過因為工作轉換，并沒有深入使用Struts。后來我用了半年 ColdFusion之后，就不愛使用JSP了。JSP的開發效率雖然比Perl CGI高一些，但是比起ColdFusion來說還是要低很多。JSP開發后來逐漸轉向基于custom tag的開發方式，并且最終出現了JSTL，在我看來是一種對ColdFusion的模仿。Java社區后來出現了n多的MVC框架、n多的IoC框架、 n多的ORM框架。《J2EE核心模式》所提倡的標準的三層架構至今仍然被當作鐵律來遵循，過多的層次帶來了巨大的靈活性，同時也帶來了巨大的復雜性。除了JavaEE之外，我還沒有看到其他的服務器端開發技術如此強調三層架構或者多層架構。一般來說，分出MVC就足夠了。而JavaEE開發不僅要在 Web表現層中分出MVC，還要在M中再分出業務層和持久層。這個分層的設計，是做JavaEE開發很難實現Martin Fowler在《企業應用架構模式》中提倡的充血的domain model的一個主要原因。另外Java語言本身的靜態類型所造成的笨拙和無法避免的重復代碼也是一個主要的原因，如果不強調分層，并且真的實現充血的 domain model，那么一個類中包含的代碼量會顯得太多太復雜了。
Java社區中的一些廠商目前在大力追捧JSF和EJB3，但是我并不認為JSF和EJB3或者將兩者集成在一起的JBoss Seam能夠拯救JavaEE。復雜性才是JavaEE最大的問題，JBoss Seam成功的關鍵在于它能否成功地掩蓋JSF和EJB3的復雜性，使得學習成本降低到與Rails相當的級別。不過即使它能夠做到，將來開發者還是要面對Java語言本身的靜態類型所造成的開發效率低下。我并不認為JBoss Seam有機會在開發效率上超越Rails。另外一個值得關注的框架是Grails，它是基于動態語言Groovy的，嚴格來說不能算是Java社區的框架。不過由于它基于Spring、Hibernate、SiteMesh，所以也可以看作是Java框架的進一步發展。在開發效率方面Grails也不大可能超越Rails。除了開發框架本身，還需要考慮眾多外圍工具的支持和社區的規模，在這些方面Grails不可能達到Rails的水平。還有一個RIFE呢，雖然我完全不了解它，不過看來它受到的關注很少。一個幾乎完全被忽視的框架，成功的前景估計很渺茫。Wicket我認為是不值得考慮的，現在我們應該把目光僅僅投向那些full stack框架上，建造一個更加精巧的Web MVC框架解決不了根本的問題，對開發效率的提升是有限的。Cetia4和Restlet也是兩個很有趣的框架，特別是它們能夠支持REST開發，代表了 Java Web開發框架的未來。Google的Guice是一個很有可能取代Spring的輕量級IoC框架，前景似乎不錯。不過Cetia4、Restlet、Guice這些框架和Wicket一樣，并不是full stack框架，對開發效率的提升是有限的。
根據上述分析，我現在對Java社區內部的創新能力已經感到很失望了（很明顯我后知后覺了，感到失望的大有人在），這種持續了10年之久的創新能力似乎已經逐漸枯竭。由于動態類型的腳本語言（Python、Ruby、JavaScript等等）這些年來取得了長足的進步，而且在Web開發方面出現了一些killer級的框架，現在是將目光投向其他開發語言的時候了。我的決定就是在今年下半年完全轉到Ruby和Rails這個平臺上面。從Java轉到 Ruby有幾個強有力的理由：
1. Rails可以讓單個開發者在開發效率方面接近自己能力的極限。我并不是一個完美架構的fans，熱衷于不寫一行代碼，巨細無靡地分析各種架構優劣直到腦神經癱瘓。我熱衷的是解決用戶真正關心的問題，用技術改善他們的生活，與用戶建立起良好的人際關系。
2. Rails框架對Ajax有更好的支持，通過使用RJS模板可以極大減輕一般情況下做Ajax開發的復雜性，提高開發的效率。
3. Rails框架對REST開發提供了最好的支持。REST在Web開發方面會越來越重要，全面支持REST就是未來所有語言Web開發框架發展的方向。
4. JRuby 1.0對Rails的支持已經很好，而且支持直接使用Java開發的資源，所以現在是從Java轉到Ruby的一個適當的時機。
我已經讀完了《Ruby for Rails中文版》，并且出了一個個人的勘誤。《應用Rails進行敏捷Web開發》第2版我已經讀了1/3，在一周之內可以全部讀完。這兩本書讀完之后，基本上已經入門了。在入門階段我只準備讀這兩本書，然后我會通過開發來熟悉更多的技術。因為我對Perl、JavaScript和Java語言的熟悉，所以學習Ruby和Rails并沒有感覺有什么難度。事實上閱讀《應用Rails進行敏捷Web開發》第2版要比我閱讀《Struts實戰》之類的書容易理解的多（同時也更加有趣味，我第一次沒有感覺犯困），到目前為止，一切都感覺很自然。Ruby在我看來就是Perl+JavaScript+Java，毫無疑問是一門偉大的語言。很可惜晚學習了整整一年多，否則去年見到Martin Fowler的時候本應該問他更多關于Ruby的問題的。 ]]>
新技術采用概況
許多分析家擁有技術應用所需的描述模型。其中最為流行的模型是定義在Ruby的Web開發框架Iowa中，用來描述農產品的應用，稍后在一本由Geoffrey A. Moore寫作的名為《跨越鴻溝》(Crossing the Chasm)的書中，被用來描述技術內容。在書中，Moore分析了技術應用周期中存在著的五個截然不同的群體：
技術專家。這個群體傾向于采用新的技術。任何一種有前途的技術都會引起這個群體的注意。
先行采納者。不管這項技術是否在主流技術中取得成功，這個群體都將會采用新的技術來提升競爭優勢。
實用主義者。一旦新的技術進入主流應用，或是有足夠陡峭的增長曲線來保證技術將得到廣泛采用，那么實用主義者就會積極采用新的技術。
保守派。只有新技術成為必須的時候，他們才會考慮采用新的技術。
懷疑論者。這個群體可能很晚才會采用新的技術，或者也可能永遠只使用某一特定技術。
Moore指出，技術應用的關鍵之處在于團隊中是否存在實用主義者。因為實用主義者需要新技術大規模的應用，這個中間群體希望看到其他務實派在團隊做出承諾之前就使用新的技術。這是一個類似于《第二十二條軍規》書中所描述的現象，因為務實派們都會相互依賴的存在。出于這樣的原因，在先行采納者排列在技術專家之后和務實派之前，你會經常在市場接受度曲線中看到一種下降的趨勢。Moore將這種下降稱之為鴻溝傾向，并且這種想法應出于圍繞任何新技術的風險討論的中心。
]]>
基于JVM的語言正在開始流行
當Sun Microsystems公司在1995年第一次揭開Java的面紗的時候，就是非常難被定義的。這是因為JAVA是由多個部分構成：首先，它當然是一個面向對象語言。同時JAVA也是一個定義標準的語言(或多個標準，包括移動設備，標準，和企業三個版本)。最后，Java是一個虛擬機(”JVM”)，一個Java程序能夠執行的軟件環境。如果你有一個JVM，雖然這個JVM只能用來運行Java的程序——但是，JVM能在運行在你能想到的每一個平臺之上，這使得Java成為一個具有高移植性的語言。
在Java世界的一個令人著迷的趨勢就是：在最近的幾年里使用JVM來運行非Java的程序在程增長的趨勢。畢竟，如果創造了一門新的語言，你就必須在特定的平臺上實現它。如果你想你的語言能在不同的平臺上移植，那么你就需要為每一個平臺實現一個版本。但是，相比而言，如果你將語言實現在JVM上，那么你就能讓你的語言運行在任何系統的JVM上，這就意味著幾乎所有平臺都可以運行。
于是現在就有了許多的基于JVM的新增語言。其中4個最流行的是發布在開源許可證之下的。考慮到如今Java也是開發源碼了，這意味著你可以使用一個全開源體系，并且這個體系是可以移植的。因為這些語言都在JVM之上實現的，所以你就可以同時訪問Java的標準庫。這意味著如果有一個第三方的的 Java庫，而且你精于Python，那么你就可以使用Jython在你的源代碼中訪問這些Java庫。
早期的基于JVM的腳本語言，就我所知，是Jython,之前被稱為JPython。Jython，從名字你就可以猜到，是一個基于JVM的 Python語言實現。Jython完全兼容Python2.2的標準版本(這個標準版本的Python也被稱為CPython)，這意味著Jython 將會沒有Python的一些新特性。最近發布的Jython版本是2007年月發布的，但是Sun雇傭了兩位早期Jython非常知名的開發者，并且現在 Jython可以運行Django應用程序框架，因此驗證其兼容Python的能力
Sun公司同時資助了JRuby的開發，一個基于JVM的Ruby版本。Jython是Python唯一的兩個實現的其中之一，對比而言，JRuby則是眾多Ruby語言實現的其中之一。然而,JRuby被廣泛的認為是一個非常重要的版本。特別是因為他的效率，和高度兼容標準C的 Ruby版本實現。JRuby同樣可以運行Ruby on Rails框架(譯者注：構建在Ruby之上的WEB應用框架)，此外還能運行其他眾多的功能。
Jython和JRuby都是從其他已存在的語言中移植到JVM中來的。而全新的基于JVM的腳本語言是Groovy和Scala。這兩門語言現在都越來越流行，不同的是，Groovy是動態腳本語言，而是Scala是靜態語言。使用Groovy最著名的應用是Groovy on Grails項目，一個用Groovy寫成，運行在JVM之上的WEB應用框架(和Ruby on Rails很相似)。Grails找到通向商業應用程序的道路，最著名的就是LinkedIn,使用Linkedin，開發人員發現他們能比直接使用 Java更快速和容易的開發程序。相比而言，Scala，而是強類型是語言，Steve Yegge最近的一次訪談中曾經談到、靜態語言和動態語言的爭論，因為這個他還受到了很多的批評（譯者注：關于Steve Yegge的這篇關于動態語言和靜態語言之爭可以查看這里Steve Yegge是一個動態語言的支持者）
Java已經被公認為是非常成功而流行的語言。現在，Java也同時也被認為是非常流行的平臺，這四類語言僅僅是在不遠的將來通過JVM來實現的新興語言的開始。
]]>create database logindb;
use logindb;
create table user_info
-> (
-> id int auto_increment primary key,
-> name varchar(10) unique not null,
-> age int not null,
-> password varchar(10) not null,
-> city char(10) not null,
-> type int not null
-> );
insert into user_info values(default,'tom','23','123456','wuxi',0);
insert into user_info values(default,'niit','23','123456','shanghai',1);
insert into user_info values(default,'jerry','25','654321','shanghai',2);
insert into user_info values(default,'admin','25','admin888','shanghai',3);
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//構建一個JavaBean
package com.niit.login;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public class UserInfoBean
{
private Connection con;
public UserInfoBean()
{
con = Connecter.getConnection();
}
/*
* 得到用戶的類別代號
* 0：普通用戶
* 1：VIP用戶
* 2：管理員
* 3：超級管理員
* -1：帳號或者密碼錯誤
*/
public int getUserType(String name,String pass)
{
int type = -1;
try
{
PreparedStatement ps = con
.prepareStatement("select type from user_info where name = ? and password = ?");
ps.setString(1, name);
ps.setString(2, pass);
ResultSet rs = ps.executeQuery();
if(rs.next())
{
type = rs.getInt(1);
}
}
catch (SQLException e)
{
e.printStackTrace();
}
return type;
}
}
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//創建基本方法
package com.niit.login;
public class UserInfo
{
private String name;
private int age;
private String password;
private String city;
private int type;
public UserInfo()
{
// TODO 自動生成構造函數存根
}
public UserInfo(String name, int age, String password, String city, int type)
{
this.name = name;
this.age = age;
this.password = password;
this.city = city;
this.type = type;
}
public int getAge()
{
return age;
}
public void setAge(int age)
{
this.age = age;
}
public String getCity()
{
return city;
}
public void setCity(String city)
{
this.city = city;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
public String getPassword()
{
return password;
}
public void setPassword(String password)
{
this.password = password;
}
public int getType()
{
return type;
}
public void setType(int type)
{
this.type = type;
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//創建數據庫連接(該例使用的是MySql數據庫)
package com.niit.login;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class Connecter
{
public static Connection getConnection()
{
Connection con = null;
try
{
Class.forName("com.mysql.jdbc.Driver");
String url = "jdbc:mysql://127.0.0.1/logindb?useUnicode=true&characterEncoding=GBK";
con = DriverManager.getConnection(url, "root", "");
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
}
catch (SQLException e)
{
e.printStackTrace();
}
return con;
}
}
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//創建過濾器
package com.niit.login;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
public class ManagerLoginFilter implements Filter
{
public void init(FilterConfig config) throws ServletException
{
}
/*
* 執行功能的核心方法(過濾器)
*/
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException
{
//將請求和響應轉變成 HTTP的請求和響應
HttpServletRequest request = (HttpServletRequest)req;
HttpServletResponse response = (HttpServletResponse)res;
request.setCharacterEncoding("gb2312");
HttpSession session = request.getSession();
Object obj = session.getAttribute("MANAGERLOGIN");
if(obj == null)
{
//目前沒有登錄成功
String name = request.getParameter("userName");
String pass = request.getParameter("userPass");
if(name == null || pass == null)
{
System.out.println("*********別走后門**********");
response.sendRedirect("login.html");
}
else
{
]]>
“又一次”指的是什么？“革命”指的又是什么？光看結論的話肯定是一頭霧水。其實，筆者要講的并不是變化這樣一個事實，而是“促進變化的原動力”。是什么讓Java技術發生變化？讓我們從這一角度出發，先看一下Java的變化歷程。
Java正處于轉變期
回顧Java技術的發展歷程，人們一定會感慨：2004年到2005年發生的變化如此之大，可以說“現在”正是Java技術的轉換期。 Java技術由編程語言（Java語言）、運行環境（JVM：Java虛擬機）、框架（Java API群）組成，目前在每一個層面上都發生著巨大的變化。
（1）編程語言的變化
Java語言標準出現明顯變化。在2004年9月發布的正式版本J2SE5.0（J2SE:Java2 Platform, Standard Edition，Java技術的核心運行環境）中，對Java語言標準中的Generics與元數據進行了大幅擴展。出現了被認為是“自Java問世以來的最大一次語言標準變化”（美國Sun Microsystems）。這次語言標準的變化給許多Java API帶來了影響。許多企業API的新版本都引入了基于元數據的注解（程序中記錄的附加信息），以較短的編碼記述更多的信息。
（2）Java運行環境的變化
在J2SE5.0中，大幅度強化了JVM的管理功能與實用性，換句話說就是具備了Java執行OS（操作系統）的特征。例如，原來在J2EE （Java2 Platform, Enterprise Edition，構筑企業系統的Java技術）領域，標準配備有作為管理功能的應用軟件管理框架JMX。不僅如此，還配備有JVM自身監控功能（（JSR 174: Monitoring and Management Specification for the Java Virtual Machine）。在標準功能架構中可以實時監視JVM運行時的狀態，也就是內存使用量、線程狀態等。
J2SE5.0中新追加的功能中包括并行處理實用程序（JSR 166），其基礎是紐約州立大學Doug Lea提供的程序庫。也就是說，標準規格中采用了來自民間的程序庫。
（3）框架的變化
服務器端的Java框架也發生了巨大變化。企業級Java技術--J2EE的“使用方法”說明文件“J2EE Blueprint”中，提出了將應用軟件分為Web層、EJB層（Enterprise JavaBeans，將包括事務處理在內的業務進程模塊化的框架）來構筑的思路。這兩種層次都迎來了架構更替時期。Web層的新框架為JSF （JavaServer Faces，將模塊組合起來構筑Web應用程序的框架），EJB層為標準方案中剛剛公布的下一代EJB規格“EJB3.0”。
值得注意的是，促成框架發生變化的正是來自民間的源碼開放軟件。
對JSF產生影響的是作為源碼開放的Web層框架得到普及的Apache Struts。JSF是對Struts的思路進行改進的產物，JSF的Spec Lead（規格制定領袖）之一Craig R. McClanahan就是Struts的作者。
對EJB3.0造成影響的也是民間源碼開放軟件。EJB3.0引入了DI（Dependency Injection，依賴注入）容器類（Container）與POJO（Plain Old Java Object）持久類這些新功能，大大減輕了編程的復雜性。這些概念因PicoContainer、Spring等源碼開放軟件的導入而引人注目。
其背景在于用戶對“目前的EJB過于復雜”的批評。原本由EJB反對派提出的設計思想與源碼開放軟件，卻變成了EJB3.0的中心概念，顯出了巨大的影響力。
（4）腳本語言
在Java技術標準中新增加了編程語言Groovy（JSR 241）。這是一種可與Java語言無縫連接的腳本語言，有望以極短的程序完成相關處理。“在Java技術中添加Java以外的語言”，這聽起來也許有些別扭，其實以前就有這樣的呼聲，希望將可以充分利用Java技術資源的腳本作為語言使用。Groovy本來是源碼開放軟件，最終得到認可，被采納為標準規格。
由上述可以看出，Java技術的構成要素正在發生巨大變化。就在不久以前，一提起服務器Java，“Servlet、JSP、EJB是重要的 API”這樣的說明還占主流，但現在基于JSF和EJB3.0的應用程序已經變成了“面目全非”的程序。而在運行短程序或測試時，甚至還出現了不僅是 Java語言，連腳本語言都開始調用Java框架的情況。]]>
那么，如何保護我們的源代碼，實際上，應該有幾種方法可以使用：1、使用代碼混淆器 2、重載應用服務器的classloader
對于第一種方法來說，現在外面有很多開源工具可以使用，個人認為最好用的當屬proguard莫屬。proguard主要是易用易學。而且提供的功能也挺多。下面是個人一點使用心得
（1）、從網上download proguard工具，proguard工具主要包含是幾個jar文件和一些example，下載地址http://proguard.sourceforge.net/
（2）、將里面的幾個jar文件添加到類路徑下面。當然，也可以不添加，但是下面在做混淆的時候，必須指定classpath，使在做混淆的過程中，能否訪問該類
（3）、編寫一個配置文件，主要是混淆器的一些參數。比如，下面是一個例子
-injars platform.jar
-outjars platform_out.jar
-libraryjars <java.home>/lib/rt.jar
-libraryjars ibatis-common-2.jar
-libraryjars ibatis-dao-2.jar
-libraryjars ibatis-sqlmap-2.jar
-libraryjars junit-3.8.1.jar
-libraryjars d:/j2ee.jar
-libraryjars struts.jar
-libraryjars commons-lang.jar
-libraryjars D:/0working/coreproject/byislib/jasperreports-0.6.1.jar
-libraryjars commons-beanutils.jar
-printmapping proguard.map
-overloadaggressively
-defaultpackage ''
-allowaccessmodification
-dontoptimize
-keep public class *
{
public protected *;
}
-keep public class org.**
-keep public class it.**
各個參數的含義參考proguard文檔，該文檔非常詳細，上手很容易
OK，到此就完成了代碼混淆，打開產生的jar包可以看到，多了好多a、b、c之類的類文件。說明混淆結果已經成功。將原jar刪除、運行產生的混淆jar包，一切正常！
常見問題：使用過程中個人遇到了幾個問題，開始也是找了很久才解決
a. 內存溢出異常： 主要是proguard在做混淆的時候，吃了很多內存，因此，在運行混淆器的時候，可以增加內存，比如 java -mx512m .....
b.棧溢出異常： 主要是proguard在做混淆的時候，會對一些代碼進行優化，若遇到一些相對復雜的方法時，可能會拋出此異常。對付的辦法是增加配置參數-dontoptimize，如上面的配置例子所示
對于第二種方法，重載服務器的classloader的原理是這樣。 首先我們通過一定算法把class文件加密； 然后寫我們自己的classloader，替換服務器的classloader。 這樣，我們可以讀取class文件，通過我們自己的算法反加密成正確的class，然后再次進行load。這個方式還沒應用起來，這幾天個人正在研究，有什么新成果會在此做一些總結。
ProGuard是一個開源的項目，主頁：http://proguard.sourceforge.net/，目前最新的版本是3.3.2.。加載混淆器是非常簡單的，只需要解壓縮proguard3.3.2.zip，然后在 J2ME->Packing->Obfuscation 標簽中選擇 Proguard 的安裝目錄。如下圖所示，在這里可以對需要在混淆過程中保留的類名進行配置，MIDlet 類的名稱必須保留，以便設備的 Java 運行時環境（JRE）能夠找到執行的入口點。
http://images.csdn.net/20050726/image027.jpg，It’s about the above pic.
另一篇文檔
ProGuard是一款免費的Java類文件壓縮器、優化器和混淆器。它能發現并刪除無用類、字段（field）、方法和屬性值（attribute）。它也能優化字節碼并刪除無用的指令。最后，它使用簡單無意義的名字來重命名你的類名、字段名和方法名。經過以上操作的jar文件會變得更小，并很難進行逆向工程。這里提到了ProGuard的主要功能是壓縮、優化和混淆，下面我就先介紹一下這些概念，然后再介紹ProGuard的基本使用方法。
l 什么是壓縮：
Java源代碼（.java文件）通常被編譯為字節碼（.class文件）。而完整的程序或程序庫通常被壓縮和發布成Java文檔（.jar文件）。字節碼比Java源文件更簡潔，但是它仍然包含大量的無用代碼，尤其它是一個程序庫的時候。ProGuard的壓縮程序操作能分析字節碼，并刪除無用的類、字段和方法。程序只保留功能上的等價，包括異常堆棧描述所需要的信息。
l 什么是混淆：
通常情況下，編譯后的字節碼仍然包含了大量的調試信息：源文件名，行號，字段名，方法名，參數名，變量名等等。這些信息使得它很容易被反編譯和通過逆向工程獲得完整的程序。有時，這是令人厭惡的。例如像ProGuard這樣的混淆器就能刪除這些調試信息，并用無意義的字符序列來替換所有名字，使得它很難進行逆向工程，它進一步免費的精簡代碼。除了異常堆棧信息所需要的類名，方法名和行號外，程序只會保留功能上的等價。通過以上的了解，你應該明白為什么需要混淆了。
l ProGuard支持那些種類的優化：
除了在壓縮操作刪除的無用類，字段和方法外，ProGuard也能在字節碼級提供性能優化，內部方法有：
2 常量表達式求值
2 刪除不必要的字段存取
2 刪除不必要的方法調用
2 刪除不必要的分支
2 刪除不必要的比較和instanceof驗證
2 刪除未使用的代碼
2 刪除只寫字段
2 刪除未使用的方法參數
2 像push/pop簡化一樣的各種各樣的peephole優化
2 在可能的情況下為類添加static和final修飾符
2 在可能的情況下為方法添加private, static和final修飾符
2 在可能的情況下使get/set方法成為內聯的
2 當接口只有一個實現類的時候，就取代它
2 選擇性的刪除日志代碼
實際的優化效果是依賴于你的代碼和執行代碼的虛擬機的。簡單的虛擬機比有復雜JIT編譯器的高級虛擬機更有效。無論如何，你的字節碼會變得更小。
仍有一些明顯需要優化的技術不被支持：
2 使非final的常量字段成為內聯
2 像get/set方法一樣使其他方法成為內聯
2 將常量表達式移到循環之外
2 Optimizations that require escape analysis
ProGuard是一個命令行工具，并提供了圖形化用戶界面，它也可以結合Ant或J2ME Wireless Toolkit使用。通過ProGuard得到的更精簡的jar文件意味著只需要更小的存儲空間；網絡傳輸更省時；裝載速度更快和占用更小的內存空間。另外，ProGuard非常快速和高效，它僅僅只花費幾秒鐘和幾兆的內存在處理程序。它處理的順序是先壓縮，然后優化，最后才進行混淆。The results section presents actual figures for a number of applications.與其他Java混淆器相比，ProGuard的主要優勢可能是它的基于模版文件的簡單配置。一些直觀的命令行選項或一個簡單的配置文件已經足夠了。例如，下面的配置選項保護了jar文件里的所有applets：
-keep public class * extends java.applet.Applet
用戶指南里說明了所有可用的選項，并以大量的例子為你演示這些功能強大的配置選項。
上面談到了ProGuard的很多好處，現在我們就來看看如何在程序中使用ProGuard吧，之前也提到了ProGuard可以用命令行、圖形界面、Ant等來執行和處理程序，同時也提到了配置文件，下面我們一起來看如何使用：
用命令行執行ProGuard的命令如下：
java –jar proguard.jar options……
具體的選項可以參考ProGuard的用戶指南，你也可以把這些屬性寫在配置文件里；運行時，我們只需要指定這個配置文件就行了，例如：
java –jar proguard.jar @config.pro
而配置文件的格式也是要按照ProGuard提供的格式來寫的，這個可以參考ProGuard例子里的配置文件來配置適合你的應用系統的ProGuard配置文件。ProGuard提供了圖形界面的配置和運行程序，你可以在界面上配置你想要的參數，然后運行即可。前面提到的要手動寫的配置文件也可以用圖形界面來配置和生成。
如果你要在Ant里運行ProGuard，只需要添加一一個如下的target即可：
<target name="proguard" depends="init">
<taskdef resource="proguard/ant/task.properties" classpath="${lib.dir}/proguard/proguard.jar" />
<proguard c />
</target>
你只需要制定lib.dir和src.dir屬性就行了，同樣的，這里也用了proguard配置文件，跟上面提到的是一樣的。建議大家把ProGuardGUI當成一個生成配置文件的向導來使用，這樣我們只需要修改配置文件而不用重新寫一個配置文件。
如果你覺得ProGuard還不錯，那就快把它加入你的項目里吧。
第三文檔
這是一個不應該在開源社區出現的東西，但它的的確確是一個開源的項目，正像它的名字一樣，Proguard，即Program Guard（程序衛士），它代表了開源的相對面－－代碼保護。
作為JAVA這樣的高級語言，編譯的產物只是相對源代碼的一個概念而已，字節碼雖然不像源代碼那樣易懂，但絕不是不可能進行反編譯的，針對JAVA的反編譯產品很多，如CAVAJ,JAD等等。面對反編譯產品的不斷出現，將代碼視為財富的那些開發者，又何去何從。
混淆器正是在這種背景下應運而生，既然不可能完全地將拒絕反編譯，那就讓他們去反編譯吧，只要反編譯的結果別人不能直接使用不就行了嗎？只要將代碼搞混，讓別人拿到了反編譯的結果也看不懂，甚至不能編譯。
混淆的方法有很多，主要是以下幾方面。
更名，將私有類，私有的成員，方法體內部的變量名改名，改成a,b,c等等，甚至1,2,3(代碼中不允許不等于成果物中不允許）
改變邏輯的流向，如將if條件取反，if/else對換
等價代碼，如將循環改成GOTO
無效代碼，插入不可及的無用代碼
Proguard是一個非常優秀的開源的JAVA混淆器,可以在http://proguard.sourceforge.net/下載到，現在就讓我一起來看一下Proguard.
以3.2版為例，釋放壓縮包，我們看到，作為開源項目就有docs，lib,src,sample文件夾，在此就不一一介紹了。
進入lib目錄，內有proguard.jar，如果要自己有混淆器的外殼，或作ANT插件的話，會用到它，詳細情況可以參考Proguard的文檔。
我們要看的是proguardgui.jar，這是Proguard的圖形界面，我們使用JDK打開，注意是JDK，不是JRE。
點選Input/Output標簽，選擇要混淆的JAR包（注意是JAR包），輸出JAR包，以及用到的所有類庫。
點選Obfuscation標簽，選中不需要混淆的類（要被反射的類絕對不能被混淆）
點選Process標簽，Process按鈕，等著看結果吧。
Proguard中還包括了代碼優化和代碼整理的功能，不是本文討論范圍，有興趣的就自己研究吧）
只混淆方面的選項
使用此種方式，如果a-z使用過，會轉向aa.class,如下圖配置界面
1,4,6,9,10,11,12
源代碼
package org.zwm.pub;
public class Bru {
/**
* @param args
*/
]]>