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

許多人認?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還有一點機會。
http://blog.csdn.net/zwwwxy/archive/2005/04/02/334958.aspx

http://zwwwxy.blogchina.com/1081807.html

http://blog.csdn.net/zwwwxy/archive/2005/03/30/333818.aspx

http://zwwwxy.blogchina.com/blog/article_81038.521777.html

http://zwwwxy.blogchina.com/443048.html

http://cnjavaxml.blogspot.com/2005/06/jspbs.html
http://javaxml.blog-city.com/jspservletbsjava_1.htm