選擇jsp而不是servlet作為BS前台主流方案是JAVA的戰略性方向錯誤

js|servlet|錯誤|戰略|主流  原文
許多人認為JSP是JAVA向微軟ASP挑戰的成功產品，到今天，圍繞著JSP方案發展出了TAG/EL等技術，JSP作為JAVA的BS前台介面方案看來已經是無法逆轉。但在我看來，JAVA選擇JSP這種表達形式，恰恰是它最失敗的地方，是對ASP的一種拙劣的模仿，它本來可以做得更好的，甚至可能據此讓微軟徹底退出伺服器領域，但最終，卻可能成為足以令JAVA最終失敗的重大戰略方向性錯誤。
JAVA到今天仍具有微軟所有語言所不具備的優點，就以C#而言，只不過是形似而神不似。java最根本的地方不在於它的OOP，不在於它是C++的文法最佳化，這些都不重要，而在於它的虛擬機器機制，使它成為最佳的跨平台的伺服器語言；而C#無論多麼文法相似，都無法改變這樣一個現實：它只是微軟CLI中的語言中的一種，它再成功，也充其量是取代了在windows啟動並執行JAVA；某種程度上，C#是一種註定沒有必要存在的語言，在CLI中，只需要一種就夠了，象VB.net。
JAVA到軟體世界帶來的最大的影響是令軟體真正出現了分層開發，出現真正的三層結構。儘管有些傢伙吹噓他們的軟體是N層結構（真不要臉！），其實究其實則，都只不過是傳統的CS式的兩層結構的變種，不能把函數每加一個就稱為一層噢！JAVA出現體現了軟體的創造性思維，但JAVA犯的錯誤最大的地方就在於他毫無創造性地模仿了ASP，並且，竟然把JSP作為中介軟體的主要訪問手段加以發展。這是一個重大的失誤，也許，如果有一天JAVA死掉的話，就死在這個失誤上面。

ASP的是模仿最早的livewire式的jsp和cofusion，livewire也是本人最早在項目中接觸的jsp，與後來的java jsp毫無相同之處。這種netscape公司的"jsp"與asp有共同的特點，就是完全沒有物件導向的特性，是純粹的解析性指令碼語言，後來的PHP也是這樣的產品，PHP本質上可以看作是Cscript。這些語言的出現原意是要滿足那些不懂電腦語言，從HTML美工轉行的半吊子程式員的能力需要，美其名為讓美工可以寫動態網頁程度。不過，這個開發假想成了互連網出現以來最大的笑話之一，美工式的程式員始終不能寫真正的動態網頁，反而讓真正的程式員去做了美工的活了，最典型的產品就是struts。

java與此完全不一樣，它是一種需要編譯的語言，具有完全的物件導向的能力；所以，它如果能夠發揮這種特點，打敗其他的幾種指令碼是毫無困難的。結果，SUN的天才的笨蛋們（我覺得這種稱呼最客觀，既是天才，也是笨蛋），選擇了用坦克車去和捷達爭奪出租車市場，做起了JSP。而我認為， servlet才應該是它最佳的發展方向。今天，我已經忘記了當初是什麼原因令我放棄了jsp而使用servlet作為項目解決方案的；只記得後來完全放棄jsp是由於兼顧兩種形式在傳遞變數和地址時非常複雜，還不如光用一種。今天當我以為我當初錯了，而標籤/EL等技術的出現會令JSP不同往昔而再次在重大項目中選用JSP時，（其中一個原因也是那個笑話的延續，希望不懂JAVA的維護人員可以在交貨後自已維護系統前台），隨著項目的進入，我記起了當初放棄JSP的原因：一個是當時的代碼管理非常困難，JSP系統基本上與其他PPP類程式一樣是不可維護的；另一個原因就是JSP無法基於模板進行維護。前者由於tag等的出現而緩解了，（從前也可以使用include sevlet的辦法達到接近的效果），後者仍然一樣，關鍵就在於不能複蓋已有的代碼。而在servlet中，重載一個方法是很容易的。

許多人以為servlet難寫，在doget/dopost/init/等中需要塞進那麼多的方法；其實，這是一種誤解，這種誤解是沒有認識到 servlet本質上是一種java class,可以輕易公有私人的方法，也可以繼承，可以重載等等。因此，在servlet中很容易就可以形成一個全系統追隨的模板，一改一起改。相反，以為寫servlet就是在doget中用out.println輸出的，是把寫JSP的理解帶進了servlet;JSP編譯成servlet後，也正是這個樣子的。所以它不存在繼承的價值。

那麼對於複雜的html介面如何達到與jsp同樣的簡潔嵌入呢？其實很簡單。我當時的解決方案是使用${xxx}標記預置預設的方式，然後把這些帶有大量html代碼的標記的檔案存在某個目錄；在sverlt初始化時通過檔案位元組流讀入，使用一個字串分析的組件（今天還在用呢）把標記轉化為相應的實際動態變數。這恰恰就是今天的號稱最先進的EL 運算式語言的解決方案。真的，我一點都不覺得有寫servlet比一般的網頁程式難在什麼地方。某種程度上，我覺得自已做了一個jsp解釋引擎出來了。

那麼這種土產的jsp和真正的jsp有什麼區別呢？最大的區別就在於它是把jspp僅僅看成是為servlet服務的html程式碼程式庫，而不是 serlvet為jsp服務。換言之，這裡的jsp是類似於今天的tile/Jspfragment的東西。一個小小的差別，帶來的效果完全不一樣，因為它可以完整的發揮出java物件導向和繼承的特點；甚至可以象PB那樣將整個項目前台作為一個類"繼承"出來，再擴充和重整需要修改的地方。而這種能力，是那些"P"語言永遠不可能做到的。但是，SUN偏偏跟在微軟屁股後面去拙劣地模仿JSP。

不妨回顧一下在BS前台最常見到的架構是什麼? 是一個大的網站上大部分版面具有類似的架構布局，每個分欄中只有其中某處不一樣。JSP可以很容易地共用其中一樣的部分；但對於其中不一樣的部分就無能為力。由於JSP不能形成頂級模板，而每一個大分欄中部內容不一樣，所以唯一的辦法就是每一個大分欄拷貝出一個jsp檔案來獲得一個頂級架構模板；顯然，這意味著對每一個檔案的相同架構部分進行維護；項目越大，這樣日後更改的工作量越大。這時侯真的有點懷念servlet的功能了，對這種需求，只需要寫好一個 servlet,其他的servlet繼承它，然後重載它的中央內容方法，就搞惦了。當前要達到類似要求的唯一辦法，似乎只能是在頂級頁面中使用if-else/equal-notequal判斷裡include不同的內容檔案。舍此，還有什麼好辦法嗎？

JAVA的BS前台的正確的思路應該是以一個可以訂製繼承方法的servlet為核心，然後可以分解一些象jsp這樣的檔案，類似今天的jsp中技術都可以用到這些JSP檔案中。也就是說，核心應該是一個可以定製的servlet，而不是提供一個工具，把jsp編譯成不可變的servlet。頂級檔案應該是servlet，而不應該是JSP，這就是我所說的。
我一個人是不可能與整個JSP社區作對的，不可能一個人完成SUN幾千個開發工程師的工作，既然SUN的某個天才大笨蛋選擇了JSP作為JAVA在 BS的表達主流，到今天，如果我仍使用JAVA作為前台介面程式的話，最好就是隨大流標準，而在幾年前，JSP完全不是標準，情況是不一樣了。不過，從今天實際的體驗來說，我仍然強烈地覺得，SUN犯了一個嚴重的方法性錯誤。更為遺憾的是，SUN沒有做到的事情，讓微軟在ASP.net中有所體現了，所幸微軟的東西從來不打算跨平台移植的，所以SUN還有一點機會。