Java究竟怎么玩？

 剛剛在javaeye看到一個名為Douyu的國人項目，覺得搞下去未來可能很有意思，放到blog上做個標記。

——————以下是轉載的作者原文———————

原文地址如下：http://zhh2009.javaeye.com/blog/517796

標題的構思來源于Rod Johnson的那本"Without EJB"以及CCTV5中一句耳熟能詳的廣告詞，
不過此文并不是用來批判SSH(Struts、Spring、Hibernate)/JSP/Servlet的，
也不是為某品牌做廣告，而是用來分享這將近一年來的研究心得。

去年圣誕節時曾在JavaEye發過一兩篇文章，不過現在找不到了，
文章內容提到要在3個月左右的時間內設計出一個有別于SSH的新型MVC框架，
設計的起點最初是以JSP/Servlet為基礎的，雖然在兩個多月后有了個雛形，
但是跟Rails這樣的框架相比還是沒有明顯的優勢，
比如在不使用反射的情況下，
很難將不同的uri對應到Servlet類中的public方法。
(Servlet類指的是繼承自javax.servlet.http.HttpServlet的類)
每次修改Servlet類的源代碼時總得經過煩人的手工編譯步驟(有時還不得不重啟Tomcat)，
還有與數據庫打交道的模型層也得人工干預，一堆煩人的映射配置。

那三個月內時常有沮喪感，似乎已走近了死胡同!
后來心一狠，決心甩開JSP/Servlet那一堆條條框框，把設計的起點再往下深一個層次。
因為2007年曾詳細研究過Java語言的編譯器(javac)實現細節，所以從編譯器著手，
但是編譯器的強項在于分析Java源代碼，無法處理Http請求，
接著在網上把Tomcat6的源代碼下下來研究了三個月，
期間順便研究了Sun公司的超輕量級Http服務器"com.sun.net.httpserver"的源代碼，
同時詳細學習HTTP/1.0(RFC1945)與HTTP/1.1(RFC2616)協議。

但是Tomcat6過于臃腫了，包含的Java文件超過了1300個，
光是解析server.xml與web.xml的代碼看完后就讓人有煩躁感。
(如org/apache/tomcat/util/digester與org/apache/catalina/startup包中的很多類)

另外最重要一點，Tomcat6采用的是Eclipse JDT編譯器，僅僅是用來編譯JSP文件，
編譯器在控制層沒有發揮一點作用。
而Sun公司的超輕量級Http服務器又過于簡單了，連HTTP/1.1的大多數功能都沒實現，
除了參考一下它的SSL實現外基本上毫無價值。

本想在現有的JSP/Servlet容器上做一下簡單擴展就得了，
哪知也是四處碰壁(還下過Jetty的源代碼下來看了一會，結果發現比Tomcat6還糟)，
后來決定對Tomcat6與Sun的Http服務器進行大刀闊斧的改造，
完成了一個精簡版的改良后的基于NIO的Http服務器(目前的版本只有60個左右的Java源文件)，
并且能跟Javac編譯器完美結合，能直接運行Java源文件。

在模型層這一塊，最初是從書上和網絡上對Hibernate進行應用層次的研究，
但是并不想深入源代碼，因為代碼量也實在是太多了，倒是對Ibatis2.0深入研究了一下，
Ibatis2.0代碼量比較少，也簡單，看了不到一星期就基本上看完了，不過現在并沒留下深刻映象，
因為并沒發現什么特別出彩的地方，Ibatis2.0還是離不開xml，而我想要完全拋棄xml。

當然，不管Hibernate也好，Ibatis2.0也好，相比Rails的ActiveRecord還是遜色了點，
不過我的目標并不是要造一個Hibernate、Ibatis2.0或ActiveRecord這樣的輪子，
我的要求更高，我在想如何才能寫更少的代碼，如何才能實現自動化？
可不可以在服務器啟動時或運行時動態解析數據庫的元數據，
讓編譯器跟據這些元數據動態生成類呢？
接著我轉去研究JDBC-1.2/JDBC-2.1/JDBC-3.0/JDBC-4.0規范，研究數據庫驅動的開發手冊。
我得從零開始，我目前的實現是這樣做的：你可以在你自己的Java源文件中直接引用動態生成的類，
就像這些類是你自己寫的一樣，ORM已基本上實現自動化了，2.9 節專門講Douyu的ORM。

最后一點值得一提的是，我在Java語言層次引入了權限管理模型，
不過你別擔心，我并沒有引入新的Java語言語法，
只是借助Annotation擴充了某些特殊的語義。
目前這個權限管理模型的粒度只是劃分為功能、字段權限兩個等級，
并沒有實現與具體業務相關的數據權限，不過在未來的路線圖中有打算引入工作流模型，
到時會努力嘗試各種實現數據權限的方案。

與權限相關的細節請看2.8節 Douyu的權限模型 。



折騰了半年后，發現已不再是個MVC框架了，我想稱為平臺更合適，
一種運行在JVM之上的新型平臺，我給她起了個名字: Douyu
(呵呵，名字的由來暫時保密，也許你能猜出來。。。)


雖然孤軍奮戰將近一年，自我感覺小有成就，但是還有很多不怎么滿意的地方，
各位大牛們也許更牛，看見不爽砸磚頭便是。


Ok，上干貨。


1. 安裝配置


(這里只針對Windows平臺，特別是XP操作系統，因為我沒其他試驗環境)



1.1 安裝JDK


Douyu是在JDK1.6下開發的，不支持也不打算支持JDK1.4及更早的版本，JDK1.5我沒有測試過，
所以我只能推薦你安裝JDK1.6了 ，安裝細節我想你都會，
唯一要注意的一點是:最好是建個JAVA_HOME環境變量，然后把%JAVA_HOME%/bin加入到Path中，
因為在Douyu服務器的啟動腳本中并沒有進行過多的環境檢測，
而是直接使用了%JAVA_HOME%/bin目錄下的java命令來啟動Java HotSpot VM。


1.2 安裝Douyu服務器

Douyu項目主頁目前放在:
http://code.google.com/p/douyu/

請先下載二進制版的壓縮文件:
http://douyu.googlecode.com/files/Douyu_0_1_0.rar

目前的版本是:0.1.0，版本號很小，但大多數功能都包含了，
我并不推薦你用于工業級別的產品開發，
因為還不穩定，目前只適合分享、交流、嘗鮮目的。

下下來后直接解壓到一個你選定的目錄(假定你解壓到了D:/Douyu目錄)

D:/Douyu目錄里頭有下面7個目錄(跟Tomcat6差不多):

apps  //應用程序的源代碼放在這里，里頭有一些java源文件是下面的演示中用到的，當然你可以全都刪了。
bin   //服務器的啟動腳本和運行時類庫都在這里
conf  //服務器的配置文件放在這里
lib   //應用程序使用到的第三方類庫(比如數據庫驅動)都放在這里，初始情況下是個空目錄
logs  //存放服務器運行期間的日志(目前日志只是輸出到控制臺)，初始情況下是個空目錄
temp  //服務器運行期間用到的臨時文件夾(比如上傳文件時可能會用到)，初始情況下是個空目錄
work  //服務器運行期間的工作目錄，初始情況下是個空目錄

了解了這些就足夠了，目前你不需要做任何配置。

2. 體驗Douyu


2.1 如何運行Douyu服務器？


點"開始->運行"，輸入cmd，打開一個控制臺，切換到D:/Douyu/bin目錄，
然后輸入 douyu  啟動Douyu服務器 (要關閉Douyu服務器連按兩次Ctrl+C既可)
見下圖:



如果你是第一次打開操作系統第一次啟動JVM運行Java程序
或是隔了一個小時左右重新啟動JVM運行Java程序，這時可能要等待幾秒鐘(5--10秒)，
出現這種情況并不是Douyu服務器的問題，而是JVM本身或操作系統的問題，
通常啟動Douyu服務器如果不加載數據庫的話，一般在一秒鐘內就能啟動完成了。

Douyu服務器默認情況下監聽的主機名是: localhost，端口: 8000

如果你不喜歡這樣的默認配置，
或者最常見的情況是端口8000被占用了
(一般拋出異常: java.net.BindException: Address already in use)
你可以打開conf/server.java這個服務器配置文件，
配置文件本身就是一個java源文件，參數的配置使用Java語言的Annotation語法，
所有與服務器配置有關的都是Annotation或是Enum，全都在com.douyu.config包中定義。

import com.douyu.config.*;

@Server(
	port=8000,
	.................

要修改默認主機名和端口，請修改hostName和port的值，
hostName是一個字符串，可以用IP地址來表示，port是一個整型(int)值。


其他很多參數先不羅列了，使用到時再詳細說明。


當你修改了conf/server.java后，你也不需要自己去手工編譯它，
啟動Douyu服務器時，Douyu會自行決定是否要編譯它。
如果conf/server.java存在語法錯誤，那么編譯失敗，
Douyu服務器的啟動也會失敗，同時向你顯示編譯錯誤信息。



下文中假定Douyu服務器已啟動，監聽的主機名是: localhost，端口是: 8000
以下所有例子都經過嚴格測試了，

我的JRE版本:
D:/Douyu/bin>java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

測試瀏覽器用了兩個:

傲游瀏覽器(IE6.0),
谷歌瀏覽器(Chrome 3.0.195.27)





2.2 Hello World!



2.2.1 程序代碼

//對應apps/HelloWorld.java文件

import java.io.PrintWriter;
import com.douyu.main.Controller;

@Controller
public class HelloWorld {
	public void index(PrintWriter out) {
		out.println("Hello World!");
	}
}

2.2.2 手工編譯已經Out了，你再也不需要這一步了。


2.2.3 運行HelloWorld

打開你心愛的瀏覽器，輸入 http://localhost:8000/HelloWorld
如果你能看到下圖中所示內容，恭喜你，你己經進入了Douyu的精彩世界。



(注:這是你第一次直接運行Java源文件，可能會等幾秒鐘(2--4秒)，因為Douyu得初始化編譯器)


2.2.4 程序代碼說明

com.douyu.main包中的類大多數是Annotation，還包含一些重要的接口和類，
相當于java.lang，是你用Douyu開發程序時最常用到的，也是通往其他模塊的快速入口，
本想讓com.douyu.main包中的類像java.lang一樣讓編譯器自動導入的，
但是考慮到很多開發人員更偏愛使用IDE，不同IDE內置的編譯器不一樣，
從而會引起找不到com.douyu.main包中的類的問題，所以最后決定放棄這樣的設計了。

@Controller 這個Annotation是用來告訴Douyu這是一個控制器，
當你在瀏覽器的地址欄中輸入http://localhost:8000/HelloWorld 這樣的uri時，
瀏覽器內部通常會生成一個HTTP GET請求消息，消息內容類似這樣:

GET /HelloWorld HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,......
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon)
Host: localhost:8000
Connection: Keep-Alive

不過這里并不打算介紹HTTP協議，如果你有興趣，可以把RFC2616下下來研究。

Douyu服務器收到瀏覽器發來的請求消息后，
特別留意 "GET /HelloWorld HTTP/1.1" 這一行消息，
其中的"/HelloWorld"表示想要獲取Douyu服務器上的哪些資源，
資源有靜態的(如html、jpg等文件)，也有動態的，在Douyu服務器中動態資源只有一種，
凡是帶有@Controller這個Annotation的Java源文件都是可以直接通過uri訪問的動態資源。

不過Douyu服務器不能根據uri的表面特征一眼就看出它是動態的還是靜態資源，
服務器內部有一個專用的資源裝載器，裝載器的搜索根目錄是從apps這個地方開始的，
資源裝載器會嘗試將apps目錄與uri組合成一個java.io.File對象，
如果File對象存在，那么它就是一個靜態資源，
然后由Douyu服務器內部的靜態資源處理器給瀏覽器發送包含有文件內容的響應消息；

如果File對象不存在，資源裝載器把請求的uri當成一個類名，
然后嘗試采用類裝載器的方式裝載類，如果找不到那么就直接返回未找到(404)消息；
如果找到了，并且uri是第一次請求的，資源裝載器會返回java源文件，
然后把java源文件交給Douyu服務器內置的編譯器處理，編譯器的處理過程很復雜，
這里就不深入說明了，總之它會為你動態生成HelloWorld的實例，
然后調用它的index這個缺省的public方法，
之后調用out.println()方法把"Hello World!"發送給瀏覽器。

——————轉載結束———————

在我們這個總喜歡以“不要重復發明輪子”為口頭禪的國度里，事實上無論是“重復發明的”抑或“自己獨創的”現代事物全都屈指可數，出現Douyu這樣一個“另類”的項目，無論怎么說都是很有紀念意義的，起碼來講，它敢于犧牲ide支持，重構部分javac代碼，以換取實時編譯的舉動，偶就肯定做不出來……另外在它是“平臺”而非“框架”的問題上，偶堅定的支持原作者，因為標準的java服務器會和它有兼容性問題，它只能自己充當平臺…… 就我看來， Douyu要想做大做強，最簡單的一條路就是作者自己開公司做應用，以應用推平臺。否則，未來其研究意義或者遠大于實用意義，畢竟使用Douyu不光是使用一個框架，也意味著放棄一系列Java現有體系，而使用它的一整套“平臺“。

Douyu已實現的代碼量并不大，加之暫不開源，所以我們無法做太多的評判。 但有些人用Douyu與play!framework對比，就我看來，現在還太早了些。最起碼來說， play!framework使用REST隱藏了HTTP，而Douyu現今只是通過HTTP協議明碼進行get與post傳遞，Play支持模板，而 Douyu暫時只能用靜態的html作為頁面，雖然兩者都不用 重新編譯就可以部署文件， 但play!framework使用自定義ClassLoader動態加載class，用Javassist修改字節碼，使用自己修正的Compiler方式編譯java源碼與模板，而 Douyu主要通過重寫javac的java源碼部分實現動態編譯，Play加上支持庫等體積有40多MB，而 Douyu算上更改的javac部分也不過1MB多個一個jar 。從事實上講，Douyu更像一個play的原型系統，或者說一個未完善的play!framework，如果不照著play!framework的老路走下去，那么Douyu未來會變成什么樣子現在還未可知，演化成一個我們無法想象的平臺也大有可能。

此項目名為Douyu，就作者自己所言，似乎取自“斗魚”的意思，而不是有些人所說的“多余”或者我第一印象的“都暈”，不過嘛，斗魚這個名字其實并不太好，因為無論日漫的《斗魚》抑或臺劇的《斗魚》，主角都沒能逃脫“騙子，流氓，賭徒”的陰影（雖然人都很帥）……該項目未來的走勢如何，還是讓我們拭目以待吧……