JAVA後台開發可以純粹用JAVA SE嗎？

學生黨，沒接觸過java後台。

我理解的Java後台就是伺服器有一個java程序，

監聽某個埠，接收來自瀏覽器的HTTP請求，

然後對資料庫做查詢或修改，然後將數據返回給前端去顯示。

如果是這樣的話，JAVA SE完全可以做到啊。

Socket監聽埠，然後開線程，或者用線程池來管理，

JDBC操作資料庫，然後返回數據。

那Servlet、SSH這些東西是出於什麼目的而存在？

我習慣於先有個基本概念，先知道這些東西有什麼用，再去學，還請大家指教。

=========================================================

這幾天看了一些回答，自己也去找了一些資料，對後台也有了大概的了解。首先對大家表示感謝。

有個別回答者可能以為我是在噴J2EE或者tomcat或者SSH，所以他們怒了，說「按我的邏輯，應該去實現JVM」，「應該用彙編」。。。呵呵，真有意思，這世界從來不乏走極端的人。

我就納悶了，「按我的邏輯」，我的邏輯怎麼了？我的邏輯僅僅是因為沒學過後台，想開始學，又不是很清楚一些概念，所有想先知道這東西有什麼用，再抱著目的與興趣去學。我覺得「我的邏輯」已經表達得很清楚了。結果就變成了按我的邏輯，應該去實現JVM？？呵呵。。。

---

javaEE 是 javaSE 上的一個官方擴展，用於「企業」程序開發(直譯其實不是很貼切)。

所有的第三方擴展都是為了簡化原生的操作。

你先設想這樣的一個環節。

如果你要開發一個web項目，但是完全用javaSE。

1.你要自己寫一個網路通信庫，和netty類似，用來將Socket封裝起來。簡化其中的操作。

2.你要根據HTTP協議寫協議的encode 和 decode,這裡是最複雜的。因為你要根據HTTP協議的不同狀況進入不同的流程，最重要的你還需要根據HTTP header中的內容，區分出各種各樣的情況，比如cookie的設置和判斷等。

3.等你完整地實現了一個http協議的server之後，你進入了 resquest 和response 的 content內容的處理，request中不僅有參數，有的時候還是文件的二進位流。其中最重要的是response的content的內容構造，為了擁有動態的內容，你還要根據用戶(cookie)的上下文狀態，返回合適的結果。

現在我們還沒有涉及到EJB，JDBC，JSP 之類的東西。

然後你發現，上面的 1 2 就是一個簡單的tomcat的HTTP server部分，3 其實就是servlet做的事情。

這個時候你就明白了，javaEE的 web部分其實就是一個規範，用來對「java進行web開發」進行一個規範化和約束，使得整個生態都圍繞著某一個規範進行。這樣的好處就是，你在開發一個 java web應用的時候，你是不需要去考慮你的web是跑在 tomcat 或者 Jboss 上的。

SSH的誕生，其實就是對 servlet的簡陋的不滿，以及 java EE中 EJB的不滿而誕生的。

其中的struts or spring MVC ，是對請求路徑，數據解析等操作提供了更高層次的抽象，我相信每一個在web.xml中配置上百個路徑映射的人都深惡痛絕。

第二個 S ，早先 Spring 的提出就是為了解決 java項目中各種對象之間的依賴和解耦所提出的方案。目前的Spring 已經自成一體了，已經成為了另一種事實上的標準。

第三個 H，hibernate （其實大家用mybatis比較多），是為了簡化 java與 關係性資料庫交互而誕生的。如果你用過原生的JDBC 操作資料庫，特別是存在上百個sql的時候，想跳樓的想法會時不時冒出來。畢竟資料庫中存儲的數據和 java 能操作的對象是兩碼事，為了在其中進行轉換，無數先輩折戟沉沙，比如 enum 在資料庫中的存儲。

總結部分：

java SE，是整個體系的基石。往後的其他東西都是為了解決某一個特定問題而衍生開發出來的第三方組件。其最主要的目的是為了簡化開發過程，減少人為因素導致整個項目的不可控。

---

J2EE只是一組規範

比如Tomcat、JBOSS或者GlassFish都實現了部分J2EE的規範(比如JSP、Servlet) 但是實現方式不一樣 比如JBoss是基於Netty網路類庫 而GlassFish是基於Grizzly

你所說的那些開源框架都是不滿規範或基於規範新增的實現(比如Struts是基於Servlet實現的 Spring出現的時候的EJB太重了有一個"輕量級"的修飾詞..) 標明實現了不同規範的實現對外提供的功能也不同(比如Tomcat 6隻實現了Servlet 2.5 而Tomcat 7實現了3.0 支持了新追加的WebSocket規範)

你可以使用J2SE實現WEB服務 如果你不嫌麻煩的話

---

不同意已有的大多數答案。大家的觀點是離開了 Java EE ，不用 SSH 做 Java Web 後台就舉步維艱，寸步難行，還得步步為營，簡直步步驚心。

但是其實那只是 Oracle 制定的一套企業標準罷了，沒說 WEB 項目一定要按照企業標準去開發啊。 JavaEE 是企業標準，不單是 Java Web Framework 啊。

如果同學不喜歡 JavaEE 但是有心做 WEB ，沒有任何問題，浩瀚的 Java 世界也絕對有解決方案。

比如現在 Java/Scala 社區比較火的 Play Framework ，推薦運行在 Java EE Free 環境下，兼容 Java EE Application Server。

如果不喜歡所謂的 Framework，也可以用 Netty 簡單做一個，難度只比 NodeJs 的 Server 麻煩一點點罷了，比如 Netty 自己的範例 Netty.docs: Netty.docs: Home，裡面有個叫做 snoop 的標準 HTTP Web Server Netty Source Xref (4.0.27.Final) Package io.netty.example.http.snoop，是不是趕腳很簡單？這並不需要 Java EE支持。

實際上我做了4年 Java 後台，沒寫過一頁 jsp，半路出家的我也真沒學過 jsp 和 Java EE，也照樣在 Java 上做了很多 HTTP 協議的後台和網頁。不過學生黨嘛，不要把自己的未來限定得太死，什麼都去嘗試一下，你會發現 Java EE 還是很值得你去了解的。

---

肯定可以啊，特別是早期監控系統很多服務並不通過http提供，當時也沒啥容器的概念，每家都是自己寫服務端，通過socket或各種其他方式和客戶端通信，我十幾年前做的電力的一個系統，就是純j2se的應用，服務端通過UDP和設備卡通信，前端通過TCP和客戶端通信，界面也都是Swing，資料庫自己寫的連接池JDBC訪問，完全沒有J2EE的東西，當然也沒Servlet、SSH啥事。現在看起來好土的架構，但相應的時期適合的框架就是最好的，這麼土的架構好多年跑得穩穩噹噹。

我還留了項目的前後台截圖，供參考：

---

可以。你理解是對的。

---

SE其實就是Java最基礎的部分。

EE就是面向企業開發的延伸功能和規範。

---

如果你不用任何server而是完全自己寫，90%的工作量是監聽請求和解析路由這些事情，10%才是和你的網站相關的邏輯。如果我寫一個網站，大部分時間都是處理如何和底層交互，業務邏輯的代碼一行也沒動，是不是非常不爽？大半年過去了，該如何跟老闆交差？讓tomcat幫你做的好處是，你不用管和計算機底層如何去交互，你只需要專註於設計你的網站。不是每個開發網站的人都懂，或者需要懂太底層的知識，不然，會使得本來豐富多彩的編程變得枯燥乏味。

其實這也是種分工，不同的人擅長不同的事情，干不同的事情。我好奇你在寫javase應用的時候，想沒想過，要把java標準庫重新實現一遍，或者把jvm重新實現一遍。按你的邏輯，這些也都不是你自己做的啊，你總要了解清楚吧。現在你寫的所有東西，不管是web的也好，pc的也好，都依賴於一些運行環境。專註於你需要寫的東西就好，不要總想著重新把這些環境重新實現一遍。

servlet是一個規範，它規定了一些確定的介面，以便在tomcat載入它的時候，知道該調用哪個方法。jvm運行jar包的時候，其實它也要讀裡面的配置，知道入口在哪裡，一個意思。

ssh屬於框架。框架的作用主要是強迫你分層，也就是防止你在代碼中一邊連資料庫一邊拼接html一邊干其他事情。如果你把html做成一個模板，規定好需要傳遞的參數，那麼它就可以獨立出來寫成單獨的文件。一般來說，寫html的人和寫邏輯的人是不同的，他們就可以獨立工作互不干擾，完成的時候再拼接到一起就可以了。這不就是servlet和jsp么。

struts是對servlet和jsp的擴展，是mvc框架。struts的action繼承自servlet，簡化了讀取參數和像jsp傳參的過程。struts也為jsp擴展了不少標籤。感覺它不是必須的，不用也行。

hbm是orm框架，主要把資料庫中的表映射成java的對象形式，這樣你直接在代碼中取到的就是對象，不必要再寫原生的sql語句，也不用自己一行一行的讀取數據表然後填充到對象中了。不過對複雜條件的查詢還是力不從心。

spring主要負責ioc，即控制反轉。意思是，比如以前你在代碼中指定跳轉到哪個jsp，現在你只需要寫配置文件，由spring框架控制各部分怎麼連接。它實現了mvc三層充分的解耦。

---

Java後台當然可以用JavaSE去實現，你完全可以自己寫一個。

但是你要知道的是這樣的實現成本很大，你要自己解析HTTP報文，自己構造請求和響應對象，自己操作socket，你相當於自己寫了一個web伺服器。

而正常的做法都是在現有的web伺服器上（比如Tomcat）再寫自己的邏輯，底層的細節都被封裝起來了，從開發效率上看就好得多。

所謂的SSH更是在這之上實現了一大堆技術讓你寫代碼的過程更舒服，更不容易出錯而已。

---

除非你寫代碼是寫完了就算，再來新的東西，又再把所有的東西都重新寫一次，不打算做任何抽象或者重用。

否則，你慢慢還是會自己折騰一些東西，等到你把類似的東西都造了一次，並且還未必有別人寫得那麼好的時候，你就知道這些東西存在的目的了。

還有就是，你什麼都自己重寫了一次後，你寫的東西也比存在的那些東西牛逼，因為這是你針對實際情況做出來，換成那些已存在的那些東西，反而會變得差些。但後來有一天，你和老闆鬧翻了，你說「我他媽的不幹了，回家抱老婆去～！」，這時你老闆重新一招人進來，看著你的這「陀」（儘管在你眼裡這其實是很牛逼的東西，但別人看上去就是個陀狀的）東西，傻了：這是什麼鬼東西？老闆，推到重做把，搞不下去了。這時，老闆就冒火了：媽的，投入了這麼多搞了這麼久，不是一直都運行得很好的么，只是走了一個人，你現在告訴我搞不下去？我￥#%……##×……

總之一句話：沒什麼不可以的，只是一個成本問題。

---

很好的問題,可能一些人工作久了不會從學生角度看問題了.

從語言角度講,JavaSE是可以用來開發後台的,JavaEE只存在工程學方面的意義.高複雜度的應用(所謂的企業級應用)需要協作完成,規範/標準是協作的基礎,而JavaEE是很成功很有價值的規範,它不僅實現了一些底層的協議,還凝結了軟體行業一些積累的範式,當你"被迫"採用了它的是實現,你已經不知不覺地走在了最佳實踐的路上.可以說沒有它,Java不會取得今天的成功,你也不會有用JavaSE來寫後台的想法.

-----------------------加點廢話--------------------------------------

想起去年去漁山島,上面有些房子是居民自己用碎石搭的.而我也常常在南京的城牆上散步,會看到每一個城牆大小接近,磚上有燒著諸如"宜春府*** 制"的陽文,用以發現城磚不合規時追溯責任人.可以說,如果僅僅體驗搭房子的樂趣,作為基本材料,碎石(JavaSE)是足夠的--往往學生敲代碼更希望的是享受這種樂趣,我也是--而一旦和工程,商業,責任,合作等等搭上邊,城磚(JavaEE)則是必須的,雖然我們都知道自己搭房子和按規定的大小燒磚樂趣是不一樣的...

---

能不做後台開發就不要做吧，連夜發布項目是件令人痛苦的事情。

---

= = 對啊 java se 完全可以做到。實際上伺服器也是用java se寫的。

Servlet定義了一套標準的介面讓你可以不管伺服器是什麼實現的你只要關注業務就好。後來由於Servlet用起來也不夠方便，又有了jsp。

想讓一個程序變得低耦合，好維護，需要些很多代碼，同是一般很多程序都有些相同的部分我們不需要一遍又一遍的寫，這部分就由SSH搞定了。用SSH搭個框架，其他人只用往裡面填業務就行了。

總的來說JAVA SE -&> Servlet+JSP-&>SSH就是讓開發變得越來越容易，越來越好維護的過程。

---

這也正是我的工作領域：一端是監聽socket請求，按公司專有協議解析，一端接到資料庫。2008年自己開發的通訊模塊庫，其他部門也有在用（為了方便應用nio，2011年遷移到了Netty）。由於對資料庫連接池有特殊要求（例如：每分鐘要處理1萬多條通訊數據，同時還要兼顧連接有效性測試；底層庫還要兼作異常時能自動定位sql語句等需求），連接池驅動也是自己開發的。目前該資料庫驅動模塊也應用在公司tomcat資料庫連接監測；為了手機也能隨時監測軟體運行參數，內置了http服務，直接控制頁面的輸出流。

而這一切都基於JavaSE。

---

可以用Java SE的jdk和Spring來做, maven分分鐘把對Java EE的依賴拉下來

---

這個想法其實是很好的，如果沒有人從底層去考慮問題，那麼也就沒有新語言，新框架的出現了。重複造輪子的說法，首先要會造，然後去做質量差不多的輪子，才叫重複造輪子，一群連底層原理都不懂的，又有什麼資格說別人造輪子呢。再說，如果你造的輪子質量更好，那無疑就是一門新語言，一個新框架的誕生。JVM是真的有人重新實現了，現在叫scala。

框架是提煉共性，簡化開發的手段。簡單來說，你開發了一個程序，別人copy過去稍微改改變成了另一個程序，你的程序就是框架。好處自然顯而易見，壞處當然也有。每家公司的業務都有獨特性，而這些獨特性往往會讓框架難以處理，這個時候技術差的公司就會寫一些與框架不兼容的代碼做臨時方案，這種臨時處理會越來越多，最終讓工程無法維護。而技術好的公司就會出中間件或三方包，然後會被框架收錄，框架整合越來越多的個性化組件，越來越重，用起來越來越麻煩。然後，就會有人提出新的更加易用框架，慢慢淘汰老的框架。

由此可見，不用框架，可能你寫個http協議解析就要翻幾十頁的IEEE標準。只用框架，那麼可能你一輩子技術也就停留在簡單的業務處理了。

所以，我的建議是用框架而讀源碼。java最好的地方就在於基本都是開源的，就算不開源，反編譯也不要太簡單，就算加了混淆，java位元組碼也非常易讀。先慢慢成為能為舊框架提供新組件的人，最終就能成為新框架的創始人。

回到問題的話，在你搞透當前框架的原理和不足，並且你能有一個新的完整的解決方案之前，還是用框架。當然如果是學習角度，輪子隨便造，工程角度的話，造出質量低的輪子可能要把歷史上的坑全部踩一遍。

---

軟體開發的本質就是分層抽象，java ee對有關http web等打基礎的功能做了封裝抽象，以便在此層之上的程序員可以只關注高層業務。在具體業務層同樣會做分層抽象，任何有點規模的軟體都是如此。

如果你沒領悟到這一點，而認為什麼東西都可以自己寫，那你根本連軟體開發的門都沒有摸到。

---

public class TcpServer {
public static void main( String[] args ) {
ServerSocket serverSocket = null;
try {
// 監聽8080埠
serverSocket = new ServerSocket( 8080 );
Socket socket = serverSocket.accept();

while ( socket != null ) {
new HttpRootAcceptor( socket ).start();
socket = serverSocket.accept();
}
} catch ( IOException e ) {
e.printStackTrace();
} finally {
if ( serverSocket != null ) {
try {
serverSocket.close();
} catch ( IOException e ) {
e.printStackTrace();
}
}
}
}
}


分割線----------------

public class HttpRootAcceptor extends Thread {
private Socket socket;

public HttpRootAcceptor( Socket socket ) {
this.socket = socket;
}

@Override
public void run() {
BufferedReader bufferedReader = null;
BufferedWriter bufferedWriter = null;
try {
bufferedReader = new BufferedReader( new InputStreamReader( socket.getInputStream() ) );

String str = null;
while ( ( str = bufferedReader.readLine() ) != null !str.equals( "" ) )
System.out.println( str );// 後續可以寫方法處理requestHeader和requestBody

bufferedWriter = new BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) );
bufferedWriter.write( "HTTP/1.1 200 OK
" );
// 後續可以自定義是json格式還是text/html格式
bufferedWriter.write( "Content-Type: application/json; charset=UTF-8

" );
bufferedWriter.write( "{"a": "Hello", "b": "World"}" );
bufferedWriter.flush();
bufferedWriter.close();
bufferedReader.close();
socket.close();
} catch ( IOException e ) {
e.printStackTrace();
}
}
}


一個請求一個線程，埠為8080，最原始WebServer

---

可以，就像你可以用彙編寫程序一樣

---

完全沒有問題，比如這個 https://www.oschina.net/p/simplewebserver，web開發無非是處理瀏覽器，客戶端的HTTP請求而已。J2EE規範了大家編碼的邏輯。

---

可以啊

自己設計並實現一套基於java的企業應用的規範唄

---

推薦閱讀：