java平台架構

『壹』 java架構有哪些

主流框架還是MVC框架技術
1：jsp+servlet+javaben適用於比較小的項目
2：strut+spring+hibnate
目前這是主流框架技術組合在一起就是ssh了
適用於要求可維護性強的框架技術
3：ejb jsf等重量級框架技術比較過時
WebWork 【Java開源 Web框架】
WebWork 是由OpenSymphony組織開發的，致力於組件化和代碼重用的拉出式MVC模式J2EE Web框架。WebWork目前最新版本是2.1，現在的WebWork2.x前身是Rickard Oberg開發的WebWork，但現在WebWork已經被拆分成了Xwork1和WebWork2兩個項目。 Xwork簡潔、靈活功能強大，它是一個標準的Command模式實現，並且完全從web層脫離出來。 Xwork提供了很多核心功能：前端攔截機（interceptor），運行時表單屬性驗證，類型轉換，強大的表達式語言（OGNL – the Object Graph Notation Language），IoC（Inversion of Control倒置控制）容器等。 WebWork2建立在Xwork之上，處理HTTP的響應和請求。WebWork2使用ServletDispatcher將HTTP請求的變成 Action(業務層Action類), session（會話）application（應用程序）范圍的映射，request請求參數映射。WebWork2支持多視圖表示，視圖部分可以使用 JSP, Velocity, FreeMarker, JasperReports，XML等。在WebWork2.2中添加了對AJAX的支持，這支持是構建在DWR與Dojo這兩個框架的基礎之上.【EclipseWork：用於WebWork輔助開發的一個Eclipse插件】
Struts 【Java開源 Web框架】
Struts 是一個基於Sun J2EE平台的MVC框架，主要是採用Servlet和JSP技術來實現的。由於Struts能充分滿足應用開發的需求，簡單易用，敏捷迅速，在過去的一年中頗受關注。Struts把Servlet、JSP、自定義標簽和信息資源(message resources)整合到一個統一的框架中，開發人員利用其進行開發時不用再自己編碼實現全套MVC模式，極大的節省了時間，所以說Struts是一個非常不錯的應用框架。【StrutsIDE：用於Struts輔助開發的一個Eclipse插件】
Hibernate 【Java開源 持久層框架】
Hibernate 是一個開放源代碼的對象關系映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱資料庫。 Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序實用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任。Eclipse平台下的Hibernate輔助開發工具:【Hibernate Synchronizer】【MiddlegenIDE】
Quartz 【Java開源 Job調度】
Quartz 是OpenSymphony開源組織在Job scheling領域又一個開源項目,它可以與J2EE與J2SE應用程序相結合也可以單獨使用。Quartz可以用來創建簡單或為運行十個，百個，甚至是好幾萬個Jobs這樣復雜的日程序表。Jobs可以做成標準的Java組件或 EJBs。Quartz的最新版本為Quartz 1.5.0。
Velocity 【Java開源 模板引擎】
Velocity 是一個基於java的模板引擎（template engine）。它允許任何人僅僅簡單的使用模板語言（template language）來引用由java代碼定義的對象。當Velocity應用於web開發時，界面設計人員可以和java程序開發人員同步開發一個遵循MVC架構的web站點，也就是說，頁面設計人員可以只關注頁面的顯示效果，而由java程序開發人員關注業務邏輯編碼。Velocity將java代碼從web頁面中分離出來，這樣為web站點的長期維護提供了便利，同時也為我們在JSP和PHP之外又提供了一種可選的方案。 Velocity的能力遠不止web站點開發這個領域，例如，它可以從模板（template）產生SQL和PostScript、XML，它也可以被當作一個獨立工具來產生源代碼和報告，或者作為其他系統的集成組件使用。Velocity也可以為Turbine web開發架構提供模板服務（template service）。Velocity+Turbine提供一個模板服務的方式允許一個web應用以一個真正的MVC模型進行開發。 【VeloEclipse ：Velocity在Eclipse平台下的一個輔助開發插件】
IBATIS 【Java開源 持久層框架】
使用ibatis 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象， 這一層與通過Hibernate 實現ORM 而言基本一致，而對於具體的數據操作，Hibernate 會自動生成SQL 語句，而ibatis 則要求開發者編寫具體的SQL 語句。相對Hibernate等 「全自動」ORM機制而言，ibatis 以SQL開發的工作量和資料庫移植性上的讓步，為系統設計提供了更大的自由空間。作為「全自動」ORM 實現的一種有益補充，ibatis 的出現顯 得別具意義。

『貳』 java 系統架構

開始的架構設計也是最難的，需要調研同類產品的情況以及技術特徵，了解當前世界上對這種產品所能提供的理論支持和技術平台支持，再結合自己項目的特點(需要透徹的系統分析)，才能逐步形成自己項目的架構藍圖。
比如要開發網站引擎系統，就從Yahoo的個人主頁生成工具 到虛擬主機商提供的網站自動生成系統，以及IBM Webphere Portal的特點和局限 從而從架構設計角度定立自己產品的位置。

好的設計肯定需要經過反復修改，從簡單到復雜的循環測試是保證設計正確的一個好辦法。

由於在開始選擇了正確的方向，後來項目的實現過程也驗證了這種選擇，但在一些架構設計的細部方面，還需要對方案進行修改，屬於那種螺旋上升的方式，顯然這是通過測試第一的思想和XP工程方法來實現的。

如果我們開始的架構設計在技術平台定位具有一定的世界先進水平，那麼，項目開發實際有一半相當於做實驗，是研發，存在相當的技術風險。

因此，一開始我們不可能將每個需求都實現，而是採取一種簡單完成架構流程的辦法，使用最簡單的需求將整個架構都簡單的完成一遍(加入人工干 預)，以檢驗各個技術環節是否能協調配合工作(非常優秀先進的兩種技術有時無法在一起工作)，同時也可以探知技術的深淺，掌握項目中的技術難易點。這個過 程完成後，我們就對設計方案做出上面的重大修改，豐富完善了設計方案。

設計模式是支撐架構的重要組件

架構設計也類似一種工作流，它是動態的，這點不象建築設計那樣，一開始就能完全確定，架構設計伴隨著整個項目的進行過程之中，有兩種具體操作保證架構設計的正確完成，那就是設計模式(靜態)和工程項目方法(RUP或XP 動態的)。

設計模式是支撐架構的一種重要組件，這與建築有很相象的地方，一個建築物建立設計需要建築架構設計，在具體施工中，有很多建築方面的規則和模式。

我們從J2EE藍圖模式分類http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE這樣一個框架軟體的架構與設計模式的關系。

架構設計是骨架，設計模式就是肉

這樣，一個比較豐富的設計方案可以交由程序員進一步完成了，載輔助以適當的工程方法，這樣就可保證項目的架構設計能正確快速的完成。

時刻牢記架構設計的目標

由於架構設計是在動態中完成的，因此在把握架構設計的目標上就很重要，因此在整個項目過程中，甚至每一步我們都必須牢記我們架構設計的總體目標，可以概括下面幾點：

1. 最大化的重用：這個重用包括組件重用 和設計模式使用等多個方面。

比如，我們項目中有用戶注冊和用戶許可權系統驗證，這其實是個通用課題，每個項目只是有其內容和一些細微的差別，如果我們之前有這方面成功研發經 驗，可以直接重用，如果沒有，那麼我們就要進行這個子項目的研發，在研發過程中，不能僅僅看到這個項目的需求，也要以架構的概念去完成這個可以稱為組件的 子項目。

2. 盡可能的簡單明了：我們解決問題的總方向是將復雜問題簡單化，其實這也是中間件或多層體系技術的根本目標。但是在具體實施設計過程中，我們可能會將簡單問題復雜化，特別是設計模式的運用上很容易范這個錯誤，因此如何盡可能的做到設計的簡單明了是不容易的。

我認為落實到每個類的具體實現上要真正能體現系統事物的本質特徵，因為事物的本質特徵只有一個，你的代碼越接近它，表示你的設計就是簡單明了， 越簡單明了，你的系統就越可靠。更多情況是，一個類並不能反應事物本質，需要多個類的組合協調，那麼能夠正確使用合適的設計模式就稱為重中之重。

我們看一個具備好的架構設計的系統代碼時，基本看到的都是設計模式，寵物店(pet store)就是這樣的例子。或者可以這樣說，一個好的架構設計基本是由簡單明了的多個設計模式完成的。

3. 最靈活的拓展性：架構設計要具備靈活性 拓展性，這樣，用戶可以在你的架構上進行二次開發或更加具體的開發。

要具備靈活的拓展性，就要站在理論的高度去進行架構設計，比如現在工作流概念逐步流行，因為我們具體很多實踐項目中都有工作流的影子，工作流中有一個樹形結構許可權設定的概念就對很多領域比較通用。

樹形結構是組織信息的基本形式，我們現在看到的網站或者ERP前台都是以樹形菜單來組織功能的，那麼我們在進行架構設計時，就可以將樹形結構和 功能分開設計，他們之間聯系可以通過樹形結構的節點link在一起，就象我們可以在聖誕樹的樹枝上掛各種小禮品一樣，這些小禮品就是我們要實現的各種功 能。

有了這個概念，通常比較難實現的用戶級別許可權控制也有了思路，將具體用戶或組也是和樹形結構的節點link在一起，這樣就間接實現了用戶對相應功能的許可權控制，有了這樣的基本設計方案的架構無疑具備很靈活的拓展性。

Java架構設計

軟體架構作為一個概念，體現在技術和業務兩個方面。

從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。

先說一些基本原則：

分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。

還有兩個比較小但很重要的原則：

細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade(外觀)模式就很能體現這個原則的精神。

依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視 為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下當前流行的技術，以及當前我們能採用的架構。

因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用 戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層 次架構談起：

因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實 現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能 相當完備。推薦作為持久層的首選

在業務層,因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。

在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構,但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非 常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。

因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致 性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務 (tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我 們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大 多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼,但採用開源代碼卻常常是件不輕松的事。

隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而隨著 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式,然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移,使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。最近還有一個趨勢, microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現在還很難定論。

aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、 nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標志性的語言,也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。

有關架構設計的一些忠告：

盡量建立完整的持久對象層.可獲得高回報
盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀
不能依賴靜態數據來實現IOC模式，應該依賴數據特徵介面，靜態數據僅是數據特徵介面實現方式之一
架構設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現

從業務角度說：軟體架構應是深刻體現業務內部規則的業務架構，但因為業務變化頻紝，所以軟體架構很難保持恆定不變，但業務的頻繁變化不應是軟體架構大規模頻繁變化的原因，軟體架構應是基於變化的架構。

一種業務有其在一段時間內穩定存在的理由(暫且不談)，業務內部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項 從某一維度來觀察都是可測量的，我們的架構首先必須保證完美適應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化 中。

每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而後來的業務改變常常又證明這種看法是錯誤的，然而常常我 們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。所以我們的架構要盡可能適應規則的變化，盡可能建立規則模版。

每個用例都關系著不同的角色。每一個用例的產生都必然是因為角色的變更(注意：不是替換，而是增強或減弱)，所以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們當前的三層架構里，角色完美地對應介面概念。

在一個系統里很多用例都相互關聯,考慮到每個用例均有可能有不同的特例，所以在架構設計中，盡量採用依賴倒置原則。如架構許可可採用消息通信模式(JMS)。這樣可降低耦合度。

現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。

在架構設計中有幾個原則可以考慮：

用例盡量細分
用例盡量抽象
角色盡量獨立
項測量獨立原則
追求簡單性
這里未提供相關的例子，例子會在以後的更新時提供。

業務和模式之間的關系

業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.

『叄』 Java的技術架構有哪些

服務分離

隨著系統的的上線，用戶量也會逐步上升，很明顯一台伺服器已經滿足不了系統的負載，這時候，我們就要在伺服器還沒有超載的時候，提前做好准備。

由於我們是單體架構，優化架構在短時間內是不現實的，增加機器是一個不錯的選擇。這時候，我們可能要把應用和資料庫服務單獨部署，如果有條件也可以把文件伺服器單獨部署。

反向代理

為了提升服務處理能力，我們在Tomcat容器前加一個代理伺服器，我一般使用Nginx，當然你如果更熟悉apache也未嘗不可。

用戶的請求發送給反向代理，然後反向代理把請求轉發到後端的伺服器。

嚴格意義上來說，Nginx是屬於web伺服器，一般處理靜態html、css、js請求，而Tomcat屬於web容器，專門處理JSP請求，當然Tomcat也是支持html的，只是效果沒Nginx好而已。

反向代理的優勢，如下：

• 隱藏真實後端服務

• 負載均衡集群

• 高可用集群

• 緩存靜態內容實現動靜分離

• 安全限流

• 靜態文件壓縮

• 解決多個服務跨域問題

• 合並靜態請求(HTTP/2.0後已經被弱化)

• 防火牆

• SSL以及http2

動靜分離

基於以上Nginx反向代理，我們還可以實現動靜分離，靜態請求如html、css、js等請求交給Nginx處理，動態請求分發給後端Tomcat處理。

Nginx 升級到1.9.5+可以開啟HTTP/2.0時代，加速網站訪問。

當然，如果公司不差錢，CDN也是一個不錯的選擇。

服務拆分

在這分布式微服務已經普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經有相對比較成熟的技術，比如阿里開源的Dubbo(官方明確表示已經開始維護了)，spring家族的spring cloud，當然具體如何去實施，無論是技術還是業務方面都要有很好的把控。

Dubbo

SpringCloud

• 服務發現——Netflix Eureka

• 客服端負載均衡——Netflix Ribbon

• 斷路器——Netflix Hystrix

• 服務網關——Netflix Zuul

• 分布式配置——Spring Cloud Config

微服務與輕量級通信

• 同步通信和非同步通信

• 遠程調用RPC

• REST

• 消息隊列

持續集成部署

服務拆分以後，隨著而來的就是持續集成部署，你可能會用到以下工具。

Docker、Jenkins、Git、Maven

圖片源於網路，基本拓撲結構如下所示：


整個持續集成平台架構演進到如下圖所示：

服務集群

Linux集群主要分成三大類( 高可用集群， 負載均衡集群，科學計算集群)。其實，我們最常見的也是生產中最常接觸到的就是負載均衡集群。

負載均衡實現

• DNS負載均衡，一般域名注冊商的dns伺服器不支持，但博主用的阿里雲解析已經支持

• 四層負載均衡(F5、LVS)，工作在TCP協議下

• 七層負載均衡(Nginx、haproxy)，工作在Http協議下

分布式session

大家都知道，服務一般分為有狀態和無狀態，而分布式sessoion就是針對有狀態的服務。

分布式Session的幾種實現方式

• 基於資料庫的Session共享

• 基於resin/tomcat web容器本身的session復制機制

• 基於oscache/Redis/memcached 進行 session 共享。

• 基於cookie 進行session共享

分布式Session的幾種管理方式

• Session Replication 方式管理 (即session復制)
  簡介：將一台機器上的Session數據廣播復制到集群中其餘機器上
  使用場景：機器較少，網路流量較小
  優點：實現簡單、配置較少、當網路中有機器Down掉時不影響用戶訪問
  缺點：廣播式復制到其餘機器有一定廷時，帶來一定網路開銷

• Session Sticky 方式管理
  簡介：即粘性Session、當用戶訪問集群中某台機器後，強制指定後續所有請求均落到此機器上
  使用場景：機器數適中、對穩定性要求不是非常苛刻
  優點：實現簡單、配置方便、沒有額外網路開銷
  缺點：網路中有機器Down掉時、用戶Session會丟失、容易造成單點故障

• 緩存集中式管理
  簡介：將Session存入分布式緩存集群中的某台機器上，當用戶訪問不同節點時先從緩存中拿Session信息
  使用場景：集群中機器數多、網路環境復雜
  優點：可靠性好
  缺點：實現復雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入

『肆』 Java的三種技術架構是什麼

Java從1998年誕生到現在已經20多年了。使用它開發的軟體不計其數。

在整個發展過程中，出現的架構方式有：

1. 單體架構：將所有的功能代碼寫在一個工程中

2. 垂直架構：將功能代碼按業務進行拆分成一個個的單體架構模式

3. 分布式微服務架構：將功能按照業務分為一個個微小的服務，每個服務都是獨立的進程，單獨部署，容易擴展，能夠很好的應對高並發等

4. 網格架構：未來的可能的架構模式。
   

『伍』 java的三大框架是什麼,功能各是什麼

常說的三大框架指：SSH，即：Spring、Struts、Hibernate。

Spring：功能強大的組件粘合濟，能夠將你的所有的java功能模塊用配置文件的方式組合起來成為一個完成的應用。Spring是一個解決了許多在J2EE開發中常見的問題的強大框架。Spring提供了唯一的數據訪問抽象，包括簡單和有效率的JDBC框架，極大的改進了效率並且減少了可能的錯誤。Spring的數據訪問架構還集成了Hibernate和其他O/R mapping解決方案。Spring還提供了唯一的事務管理抽象，它能夠在各種底層事務管理技術。

Struts：把Servlet、JSP、自定義標簽和信息資源(message resources)整合到一個統一的框架中，開發人員利用其進行開發時不用再自己編碼實現全套MVC模式，極大的節省了時間，所以說它是大名鼎鼎的功能強大的MVC架構。

Java由四方面組成：Java編程語言，即語法。Java文件格式，即各種文件夾、文件的後綴。Java虛擬機(JVM)，即處理*.class文件的解釋器。Java應用程序介面(Java API)。

『陸』 什麼是java架構

問題有點大，不知從何入手。
我就以我個人觀點瞎說吧。

一、語法的構成，java和c、c++沒啥太大的差別
在程序的控制方面：
循環（for,while），分歧（if,whish），頭文件（改成引入包），預處理指令貌似是取消了，
內存控制方面：
java與c最大的不同是無法直接操作指針，使得java程序更安全，
java採用了資源回收機制，自動清理內存中被丟棄的碎片，
模塊關系：
java是單向繼承，這樣防止了程序模塊之間的關系過於復雜。
java廣泛採用介面，超級介面，超級父類來規范和擴展程序功能。

二、從執行環境來看：
眾所周知，java程序是依託於虛擬機來執行的，這樣編譯過的java代碼不是真正意義的可以運行的代碼，而是一個介於兩者之間的中立體，這樣就可以在任何平台上互補沖突的執行而不犯錯誤這也是java最大的特點之一。

三、API以及擴展
java基本功能都依賴於核心函數庫（類庫，方法庫）來執行。所有基本方法和類，都可以在api文檔中查看，並且為了功能擴展，java支持導入新的api