註解式編程

⑴ java 注釋編程 怎麼通過注釋 得到 類的方法 。。就是通過解析 改注釋得到方法 @請高手指教。

盡供你參考!
EJB是sun的伺服器端組件模型，最大的用處是部署分布式應用程序，類似微軟的.com技術。憑借java跨平台的優勢，用EJB技術部署的分布式系統可以不限於特定的平台。

EJB (Enterprise JavaBean)是J2EE的一部分，定義了一個用於開發基於組件的企業多重應用程序的標准。其特點包括網路服務支持和核心開發工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)稱為Java 企業Bean，是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。

1.Session Bean用於實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個Session Bean來為客戶端服務。Session Bean可以直接訪問資料庫，但更多時候，它會通過Entity Bean實現數據訪問。

2.Entity Bean是域模型對象，用於實現O/R映射，負責將資料庫中的表記錄映射為內存中的Entity對象，事實上，創建一個Entity Bean對象相當於新建一條記錄，刪除一個Entity Bean會同時從資料庫中刪除對應記錄，修改一個Entity Bean時，容器會自動將Entity Bean的狀態和資料庫同步。

3.MessageDriven Bean是EJB2.0中引入的新的企業Bean，它基於JMS消息，只能接收客戶端發送的JMS消息然後處理。MDB實際上是一個非同步的無狀態Session Bean，客戶端調用MDB後無需等待，立刻返回，MDB將非同步處理客戶請求。這適合於需要非同步處理請求的場合，比如訂單處理，這樣就能避免客戶端長時間的等待一個方法調用直到返回結果。

EJB實際上是SUN的J2EE中的一套規范,並且規定了一系列的API用來實現把EJB概念轉換成EJB產品.EJB是BEANS,BEANS是什麼概念,那就是得有一個容納她,讓她可勁造騰的地方,就是得有容器.EJB必須生存在EJB容器中.這個容器可是功能強大之極!她首先要包裝你BEAN,EJB的客戶程序實際上從來就不和你編寫的EJB直接打交道,他們之間是通過HOME/REMOTE介面來發生關系的.它負責你的BEAN的所有的吃喝拉薩睡,比如BEAN的持續化,安全性,事務管理...

一.什麼是 EJB?

一個技術規范：EJB 從技術上而言不是一種"產品"
EJB 是一種標准描述了構建應用組件要解決的:
可擴展 (Scalable)
分布式 (Distributed)
事務處理 (Transactional)
數據存儲 (Persistent)
安全性 (Secure)

二.Sun 對 EJB 的期望

提供一個標準的分布的、基於 OO 的組件架構
屏蔽復雜的系統級功能需求
Write once, run anywhere
與非 Java 應用之間的互操作能力
兼容 CORBA 標准

三.為什麼選擇 EJB?

EJB 伺服器完成"繁雜"的工作：應用開發人員關注於業務邏輯的實現而不是底層的實現機制(類似於 4GL 語言設計的目標)
支持事務處理
多個業務操作同時成功，或全部失敗
可以通過在代碼外的描述來定義事務處理級別
可擴展性
EJB 可以根據您應用的增長而擴展
EJB 伺服器往往還提供了負載均衡和
安全性：由 EJB 伺服器提供資源的訪問許可權控制

四.EJB 架構

為了滿足架構的目標，規范中描述了
伺服器 (Server)
容器 (Container)
類 (Class) 和實例 (Instance)
Home 和 Remote 介面
客戶端 (Client)

五. 簡化的編程模型

關注於業務邏輯實現：EJB 負責生命周期 (lifecycle), 數據存儲 (persistence), 事務處理語義 (transactional semantic), 安全(security), ...
通用的編程模型：各種服務的高層 API
Java 是其編程語言

EJB( 業務邏輯代碼 ) 表示了與特定商業領域（例如銀行、零售等行業）相適應的邏輯。它由
運行在業務邏輯層的 enterprise bean 處理。一個 enterprise bean 可以從客戶端接受數據，對
它進行處理，並將其發送到企業信息系統層以作存儲；同時它也可以從存儲器獲取數據，
處理後將其發送到客戶端應用程序。
有三種類型的 enterprise beans：session beans、entity beans 和 message-driven beans。
Session bean 描述了與客戶端的一個短暫的會話。當客戶端的執行完成後，session bean 和
它的數據都將消失；與之相對應的是一個 entity bean 描述了存儲在資料庫表中的一行持久
穩固的數據，如果客戶端終止或者服務結束，底層的服務會負責 entity bean 數據的存儲。
Message-driven bean 結合了 session bean 和 Java 信息服務（JMS）信息監聽者的功能，它允
許一個商業組件非同步地接受 JMS 消息。

EJB3.0的介紹
[編輯本段]

由於EJB2.0的復雜性，在Spring和Hibernate等輕量級框架出現後，大量的用戶轉向了，在大家的呼聲中，EJB3.0規范終於發布了。
期待已久的EJB3.0規范在終於發布了。在本文中將對新的規范進行一個概要性的介紹，包括新增的元數據支持，EJBQL的修改，實體Bean模型訪問 bean上下文的新方法和運行時環境等等。作者還討論了EJB在未來要作出的調整以及EJB3.0與其他開發規范之間的關系。

開始

無論如何由於EJB的復雜性使之在J2EE架構中的表現一直不是很好。EJB大概是J2EE架構中唯一一個沒有兌現其能夠簡單開發並提高生產力的組建。EJB3.0規范正嘗試在這方面作出努力以減輕其開發的復雜性。EJB3.0減輕了開發人員進行底層開發的工作量，它取消或最小化了很多(以前這些是必須實現)回調方法的實現，並且降低了實體Bean及O/R映射模型的復雜性。

在本文中，我首先會介紹EJB3.0中幾個主要的改變。它對進一步深入了解EJB3.0是非常重要的。隨後，我會從更高的層面來描述已經被提交到EJB3.0規范中的細節，並一個個的講解新的規范中的改變:實體Bean,O/R映射模型，實體關系模型和EJB QL(EJB查詢語言)等等。

背景

EJB3.0中兩個重要的變更分別是:使用了Java5中的程序注釋工具和基於Hibernate的O/R映射模型。

Java5中的元數據工具

Java5(以前叫J2SE1.5或Tiger) 中加入了一種新的程序注釋工具。通過這個工具你可以自定義注釋標記，通過這些自定義標記來注釋欄位、方法、類等等。這些注釋並不會影響程序的語義，但是可以通過工具(編譯時或運行時)來解釋這些標記並產生附加的內容(比如部署描述文件)，或者強制某些必須的運行時行為(比如EJB組件的狀態特性)。注釋的解析可以通過源文件的解析(比如編譯器或這IDE工具)或者使用Java5中的APIs反射機制。注釋只能被定義在源代碼層。由於所有被提交到 EJB3.0草案中的注釋標記都有一個運行時的RetentionPolicy，因此會增加類文件佔用的存儲空間，但這卻給容器製造商和工具製造商帶來了方便。

Hibernate

目前Hibernate非常受歡迎，它是開發源代碼的Java O/R映射框架，目的是把開發人員從繁瑣的數據持久化編程中解脫出來。它也有一個標準的HQL(Hibernate 查詢語言)語言，你可以在新的EJB QL中看到它的影子。Hibernate在處理如數據查詢、更新、連接池、事務處理、實體關系處理等方面非常簡單。

概覽

在已經提交的EJB3.0規范中主要涉及兩個方面的改變:

1. 一套以注釋為基礎的EJB編程模型，再加上EJB2.1中定義的通過部署描述符和幾個介面定義的應用程序行為。
2. 新的實體Bean持久化模型，EJBQL也有許多重要的改變。

還有一些有關上述的提議，比如:一個新的客戶端編程模型，業務介面的使用以及實體Bean的生命周期。請注意EJB2.1編程模型(包括部署描述符和home/remote介面)仍然是有效的。新的簡化模型並沒有完全取代EJB2.1模型。

EJB注釋

EJB規范組織一個重要的目標是減輕原始代碼的數量，並且他們為此給出了一個完美而簡介的辦法。在EJB3.0的里，任何類型的企業級 Bean只是一個加了適當注釋的簡單Java對象(POJO)。注釋可以用於定義bean的業務介面、O/R映射信息、資源引用信息，效果與在 EJB2.1中定義部署描述符和介面是一樣的。在EJB3.0中部署描述符不再是必須的了;home介面也沒有了，你也不必實現業務介面(容器可以為你完成這些事情)。

比如，你可以使用@Stateless注釋標記類把Java類聲明為一個無狀態回話bean。對於有狀態回話bean來說，@Remove注釋可以用來標記一個特定的方法，通過這個注釋來說明在調用這個方法之後bean的實例將被清除掉。

為了減少描述組件的說明信息，規范組織還採納了由異常進行配置(configuration-by-exception)的手段，意思是你可以為所有的注釋提供一個明確的預設值，這樣多數常規信息就可以據此推斷得出。

新的持久化模型

新的實體bean也是一個加了注釋的簡單Java對象(POJO)。一旦它被EntityManager訪問它就成為了一個持久化對象，並且成為了持久化上下文(context)的一部分。一個持久化上下文與一個事務上下文是松耦合的;嚴格的講，它隱含的與一個事務會話共存。

實體關系也是通過注釋來定義的，O/R映射也是，並提供幾種不同的資料庫規范操作，在EJB2.1中這些要通過開發人員自己的設計模式或者其它技術來完成的(比如，自增長主鍵策略)。

深入研究

現在是時候詳細了解EJB3.0草案了。讓我們開始探討所有EJB中四種企業級bean，並看看他們在新的規范中是什麼樣子。

無狀態回話bean

在EJB3.0規范中，寫一個無狀態回話bean(SLSB)只需要一個簡單的Java文件並在類層加上@Stateless注釋就可以了。這個bean可以擴展javax.ejb.SessionBean介面，但這些不是必須的。

一個SLSB不再需要home介面，沒有哪類EJB再需要它了。Bean類可以實現業務介面也可以不實現它。如果沒有實現任何業務介面，業務介面會由任意public的方法產生。如果只有幾個業務方法會被暴露在業務介面中，這些方法可以使用@BusinessMethod注釋。預設情況下所有產 生的介面都是local(本地)介面，你也可以使用@Remote注釋來聲明這個介面為remote(遠程)介面。

下面的幾行代碼就可以定義一個HelloWorldbean了。而在EJB2.1中同樣的bean至少需要兩個介面，一個實現類和幾個空的實現方法，再加上部署描述符。

import javax.ejb.*;

/**
* A stateless session bean requesting that a remote business
* interface be generated for it.
*/
;@Stateless
;@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}

有狀態回話bean

除了幾個SFSB的特別說明之外，有狀態回話bean(SFSB)和SLSB一樣精簡:

一個SFSB應該有一個方法來初始化自己(在EJB2.1中是通過ejbCreate()來實現的)。在EJB3.0的規范中建議這些初始化操作可以通過自定義方法完成，並把他們暴露在業務介面中。在使用這個bean之前由客戶端來調用相應的初始化方法。目前規范組織就是否提供一個注釋來標記某個方法用於初始化還存在爭議。

Bean的提供者可以用@Remove注釋來標記任何SFSB的方法，以說明這個方法被調用之後bean的實例將被移除。同樣，規范組織仍然在討論是否要有一種機制來處理這種特殊的情況，即當這個方法出現異常的情況下bean的實例是否被移除。

下面是對以上問題我個人的觀點:

是否應該有一個注釋來標明一個方法進行初始化呢?我的觀點是――應該有，這樣容器就可以在調用其他方法之前至少調用一個方法來進行初始化。這不僅可以避免不必要的錯誤(由於沒有調用初始化方法)而且可以使容器更明確的判斷是否可以重用SFSB實例。我暫且把這個問題放一放，規范組織只考慮為一個方法提供一個注釋來聲明它是一個初始化方法。

對於第二個問題我的觀點也是肯定的。這有利於Bean的提供者合客戶端程序對其進行控制。只有一個遺留的問題:那就是一旦調用這個方法失敗，是否能移除這個bean 的實例?答案是不能，但是它將會在回話結束的時候被移除。

消息驅動Bean

消息驅動Bean是唯一一種必須實現一個業務介面的Bean。這個介面指出bean支持的是哪一種消息系統。對於以JMS為基礎的MDB來說，這個介面是javax.jms.MessageListener。注意MDB業務介面不是一個真正意義上的業務介面，它只是一個消息介面。

實體Bean

實體Bean使用@Entity注釋來標記，所有實體bean中的屬性/欄位不必使用@Transient注釋來標記。實體bean的持久化欄位可以通過JavaBean-style機制或者聲明為public/protected欄位來實現。

實體bean可以使用助手類來描述其狀態，但是這些類的實例並沒有持久化唯一性(persistent identity)的特性(即，唯一標識這個bean的欄位等)，實際上這些助手類與他們的實體bean實例是緊密結合的;並且這些對象還是以非共享方式來訪問實體對象的。

實體關聯

EJB3.0同時支持Bean之間雙向的合單向的關聯，它們可以是一對一、一對多、多對一或者是多對多的關聯。然而雙向關聯的兩端還要分為自身端 (owning side)和對方端(inverse side)不同的端。自身端負責向資料庫通告關聯的變更。對於多對多的關聯自身端必須明確的聲明。實際上對方端通過isInverse=true進行注釋 (由此自身端就不必說明了而是由另一段推斷出)。看來上面的描述，規范組織還能說讓EJB變的簡單了嗎?

O/R映射

EJB3.0中的O/R映射模型也有了重要的改變，它從原來的abstract-persistence-schema-based變成了現在的Hibernate-inspired模式。盡管目前規范組織還在就此進行討論但是一個明確的模型將會出現在下一個版本的草案中。

舉例來說，O/R映射模型將通過bean類中的注釋來聲明。而且此方法還會指出對應的具體表和欄位。O/R映射模型提供了一套自有的SQL; 而且除了提供一些基本的SQL外還支持某些高層開發的功能。比如，有一個通過@Column注釋聲明的欄位columnDefinition，那麼可以寫這 樣的SQL:columnDefinition="BLOB NOT NULL"

客戶端程序模型

一個EJB客戶端可以通過@Inject注釋以一種「注入」的方式獲得一個bean的業務介面引用。你也可以使用另一個注釋 @javax.ejb.EJBContext.lookup()來完成上面的操作，但是規范中沒有告訴我們一個普通的Java客戶端怎樣獲得一個Bean 的實例，因為這個普通的Java客戶端是運行在一個客戶端容器中，它無法訪問@javax.ejb.EJBContex對象。現在還有另外一種機制來完成上面的工作那就是使用一個超級上下文環境對象:@javax.ejb.Context()。但是規范中沒有指出該如何在客戶端中使用這個對象。

EJB QL

EJB QL可以通過@NamedQuery來注釋。這個注釋有兩個成員屬性分別是name和queryString.一旦定義了這些屬性，就可以通過 EntityManager.createNamedQuery(name)來指向這個查詢。你也可以創建一個標準的JDBC風格的查詢並使用 EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery (nativeSqlString)(這個方法用於執行一個本地查詢)來執行查詢。

EJB QL有兩個地方可以定義其參數。javax.ejb.Query介面提供了定義參數、指向查詢、更新數據等等方法。下面是一個EJBQL指向查詢的例子:

查看復制到剪切板列印

. ..
;@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECT c FROM Customer c WHERE c.name LIKE :custName"
)
.. ..
;@Inject public EntityManager em;
customers = em.createNamedQuery("findAllCustomersWithName")
.setParameter("custName", "Smith")
.listResults();

下面列出了一些EJB QL的增強特性:

支持批量更新和刪除。

直接支持內連接和外連接。FETCH JOIN運行你指出關聯的實體，Order可以指定只查詢某個欄位。

查詢語句可以返回一個以上的結果值。實際上，你可以返回一個依賴的類比如下面這樣:

SELECT new CustomerDetails(c.id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100 l 支持group by 和having。

支持where子句的嵌套子查詢。

在提交的EJB3.0草案中，EJB QL與標准SQL非常的接近。實際上規范中甚至直接支持本地的SQL(就像我們上面提到的那樣)。這一點對某些程序員來說也許有些不是很清楚，我們將在下面進行更詳細的講解。

多樣性

方法許可(Method permissions)可以通過@MethodPermissions和@Unchecked注釋來聲明;同樣的，事務屬性也可以通過 @TransactionAttribute注釋來聲明。規范中仍然保留資源引用和資源環境引用。這些一樣可以通過注釋來聲明，但是有一些細微的差別。比如，上下文(context)環境要通過注入工具控制。容器根據bean對外部環境引用自動初始化一個適當的已經聲明的實例變數。比如，你可以象下面這樣獲得一個數據源(DataSource):

;@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;

在上面的例子中如果你不指定引用資源的名稱(name)那麼其中的customerDB會被認為是默認值。當所有的引用屬性都可得到時侯@Injec注釋就可以這樣寫:

查看復制到剪切板列印

1. ;@Inject public DataSource customerDB;

;@Inject public DataSource customerDB;

容器負責在運行時初始化customerDB數據源實例。部署人員必須在此之前在容器中定義好這些資源屬性。

更好的消息是:那些以前必須檢測的異常將一去不復返。你可以聲明任意的應用程序異常，而不必在再拋出或捕獲其他類似 CreateException和FinderException這樣的異常。容器會拋出封裝在javax.ejb.EJBException中的系統級異常或者只在必要時候拋出IllegalArgumentException或IllegalStateException異常。

EJB文件處理模式

在我們結束本節之前，讓我的快速的瀏覽一下容器提供商在EJB處理模式方面可能的變更。規范中對此並沒有明確的表態，但我可以想到至少兩種模式。

一種辦法是首先利用EJB文件生成類似於EJB2.1部署模式的文件(包括必要的介面和部署描述符)然後再用類似於EJB2.1的方式來部署這個EJB組件。當然，這樣產生的部署描述符可能並不標准但是它可以解決同一個容器對EJB2.1和EJB3.0兼容的問題。下面這幅圖描述了這一過程。

另一種方法是一種類似於JSP托放的部署模式。你可以把一個EJB文件放到一個預先定義的目錄下，然後容器會識別這個EJB並處理它，然後部署並使之可以使用。這種方法可以建立於上面那種方法之上，在支持反復部署時有很大的幫助。考慮到部署的簡單性也是EJB3.0規范的目的之一，我真誠的希望在下一個草案出來時能夠確定一個模式(至少能有一個非正式的)。

你有什麼想法?

EJB3.0規范的制定正在有序的進行，為了使EJB的開發變得更加容易，EJB規范組織作出的努力是有目共睹的。就像他們說的那樣，一切對會變得簡單，但做到這一點並不容易。目前已經定義了50個注釋標記(還有幾個將在下一個草案中發布)，每一個都有自己的預設規則和其他的操作。當然，我真的不希望EJB3.0變成EJB2.1的一個翻版"EJB 3.0 = EJB 2.1 for mmies"(希望這個等式不要成立)。最後，我還是忍不住要提一些我自己的觀點:

首先，規范確實使反復部署變得容易了，並且有一個簡單的模式來訪問運行時環境。我還是覺得home介面應該放棄。

在早期的EJB規范中，實體bean用於映射一個持久化存儲。理論上(也許只是理論上)可能需要把實體bean映射到一個遺留的EIS (enterprise information system)系統中。出於將來擴展的考慮這樣作是有好處的，並且可以使更多的業務數據模型採用實體bean。也因此其伴隨的復雜性使得實體bean不被看好。在本次提交的草案中，一個實體bean只是一個資料庫的映射。並且是基於非抽象持久化模式和簡單的數據訪問模式的更加簡單開發。

我對模型變更持保留態度，我認為在EJB中包含SQL腳本片斷並不是個好注意。一些開發人員完全反對包含某些「SQL片段 (SQLness)」(比如@Table 和 @Column注釋)。我的觀點是這些SQLness是好的，據此我們可以清楚的知道我們到底要資料庫作些什麼。但是某些SQL段我看來並不是很好，比如 columnDefinition="BLOB NOT NULL"，這使得EJB代碼和SQL之間的耦合太過緊密了。

盡管對於本地SQL的支持看似很誘人，其實在EJB代碼中嵌入SQL是一個非常糟糕的主意。當然，有些辦法可以避免在EJB中硬編碼SQL，但是這應該在規范中說明，而不能是某些開發人員自己定義的模式。

假設@Table注釋只用於類。在運行時通過@Table注釋的name屬性定義的表名稱將必須對應一個實際的資料庫表。規范對此應該給予清楚的說明和一致的模式。

規范還需要更清楚的說明客戶端編程模型，尤其是普通java客戶端。規范中所有的參考都假設或者隱含的使用EJB客戶端。而且規范中對客戶端的向後兼容方面也沒有給出明確的說法。

Transient注釋應該重新命名以避免和已有的transient關鍵字發生沖突。事實上，在這一點上我們更樂於稍微的背離一下 configuration-by-exception原則並且定義一個@Persistent注釋來明確的定義持久化欄位 @Persistent注釋 可以僅僅是一個標記注釋或者它可以有幾個屬性來關聯O/R映射注釋。

與其他規范的關聯

目前可能影響到EJB3.0的JSR有JSR175(java語言元數據工具)和JSR181(Java Web服務元數據)

JSR175已經初步完成並且不會和EJB3.0有太大的沖突;但是JSR181與EJB3.0有兩個關聯的地方:

Web service介面:EJB規范將採用一種機制適應JSR181以便可以把一個bean實現為一個Web service並告訴Web service如何被客戶端調用。

JSR 181計劃採用不同的機制來處理安全問題。在早期的規范中EJB建議使用一個一致的機制(MethodPermissions)，但是JSR 181計劃使用一個稍微不同的方式(SecurityRoles和SecurityIdentity注釋)。同樣的RunAs注釋的定義也存在這些許差別。這一問題還在解決中最終會在J2EE層的規范中維持其一致性。

在J2EE 1.5中的一些開發規范可能與EJB3.0有關聯。除了上面說到的幾個關聯之外現在沒有其他的開發規范與EJB3.0有沖突。

結束語

在使EJB的開發變得簡單高效之前，我們還有很長一段路要走。規范組織在降低EJB的開發難度方面起了個好頭。O/R映射模型的提議還處在早期階段，規范組織正在完善它。我希望它不要太復雜也不要與SQL過分的耦合。

⑵ 編程中的注釋分為三類 單行注釋，多行注釋，文檔注釋；

暈~~~ 自己還是找到了 ·· 留給後來人吧···

http://www.diybl.com/course/3_program/java/javajs/2008911/141971.html

java文檔注釋（有示例）

Java代碼規范--注釋

@author LEI

@version 1.10 2005-09-01

1 注釋文檔的格式注釋文檔將用來生成HTML格式的代碼報告，所以注釋文檔必須書寫在類、域、構造函數、方法、定義之前。注釋文檔由兩部分組成——描述、塊標記。

例如：

/**

* The doGet method of the servlet.

* This method is called when a form has its tag value method equals to get.

*

* @param request

* the request send by the client to the server

* @param response

* the response send by the server to the client

* @throws ServletException

* if an error occurred

* @throws IOException

* if an error occurred

*/

public void doGet (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

doPost(request, response);

}

前兩行為描述，描述完畢後，由@符號起頭為塊標記注視。

2 注釋的種類2.1 文件頭注釋
文件頭注釋以 /*開始，以*/結束，需要註明該文件創建時間，文件名，命名空間信息。

例如：

/*

* Created on 2005-7-2

* /

2.2 類、介面注釋
類、介面的注釋採用 /** … */，描述部分用來書寫該類的作用或者相關信息，塊標記部分必須註明作者和版本。

例如：

/**Title: XXXX DRIVER 3.0
*Description: XXXX DRIVER 3.0
*Copyright: Copyright (c) 2003
*Company:XXXX有限公司
*
* @author Java Development Group
* @version 3.0
*/

例如：

/**
* A class representing a window on the screen.
* For example:
*
* Window win = new Window(parent);
* win.show();
*
*
* @author Sami Shaio
* @version %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/

class Window extends BaseWindow {

...

}

2.3 構造函數注釋
構造函數注釋採用 /** … */，描述部分註明構造函數的作用，不一定有塊標記部分。

例如：

/**

* 默認構造函數

*/

有例如：

/**

* 帶參數構造函數,初始化模式名,名稱和數據源類型

*

* @param schema

* Ref 模式名

* @param name

* Ref 名稱

* @param type

* byVal 數據源類型

*/

2.4 域注釋
域注釋可以出現在注釋文檔裡面，也可以不出現在注釋文檔裡面。用/** … */的域注釋將會被認為是注釋文檔熱出現在最終生成的HTML報告裡面，而使用/* … */的注釋會被忽略。

例如：

/* 由於triger和表用一個DMSource，所以要區分和表的遷移成功標記 */

boolean isTrigerSuccess = false;

又例如：

/** 由於triger和表用一個DMSource，所以要區分和表的遷移成功標記 */

boolean isTrigerSuccess = false;

再例如：

/**

* The X-coordinate of the component.

*

* @see #getLocation()

*/

int x = 1263732;

2.5 方法注釋
方法注釋採用 /** … */，描述部分註明方法的功能，塊標記部分註明方法的參數，返回值，異常等信息。例如：

/**

* 設置是否有外碼約束

*

* @param conn

* Connection 與資料庫的連接

*/

2.6 定義注釋
規則同域注釋。

3 注釋塊標記3.1 標記的順序
塊標記將採用如下順序：

…

*

* @param (classes, interfaces, methods and constructors only)

* @return (methods only)

* @exception (@throws is a synonym added in Javadoc 1.2)

* @author (classes and interfaces only, required)

* @version (classes and interfaces only, required. See footnote 1)

* @see

* @since

* @serial (or @serialField or @serialData)

* @deprecated (see How and When To Deprecate APIs)

* …

一個塊標記可以根據需要重復出現多次，多次出現的標記按照如下順序：

@author 按照時間先後順序（chronological）

@param 按照參數定義順序（declaration）

@throws 按照異常名字的字母順序（alphabetically）

@see 按照如下順序：

@see #field

@see #Constructor(Type, Type...)

@see #Constructor(Type id, Type id...)

@see #method(Type, Type,...)

@see #method(Type id, Type, id...)

@see Class

@see Class#field

@see Class#Constructor(Type, Type...)

@see Class#Constructor(Type id, Type id)

@see Class#method(Type, Type,...)

@see Class#method(Type id, Type id,...)

@see package.Class

@see package.Class#field

@see package.Class#Constructor(Type, Type...)

@see package.Class#Constructor(Type id, Type id)

@see package.Class#method(Type, Type,...)

@see package.Class#method(Type id, Type, id)

@see package

3.2 標記介紹
3.2.1 @param標記
@param後面空格後跟著參數的變數名字（不是類型），空格後跟著對該參數的描述。

在描述中第一個名字為該變數的數據類型，表示數據類型的名次前面可以有一個冠詞如：a,an,the。如果是int類型的參數則不需要註明數據類型。例如：

…

* @param ch the char 用用來……

* @param _image the image 用來……

* @param _num 一個數字……

…

對於參數的描述如果只是一短語，最好不要首字母大寫，結尾也不要句號。

對於參數的描述是一個句子，最好不要首字母大寫，如果出現了句號這說明你的描述不止一句話。如果非要首字母大寫的話，必須用句號來結束句子。（英文的句號）

公司內部添加ByRef和ByVal兩個標記，例如：

* @param _image the image ByRef 用來……

說明該參數是引用傳遞（指針），ByVal可以省略，表示是值傳遞。

3.2.2 @return標記
返回為空（void）的構造函數或者函數，@return可以省略。

如果返回值就是輸入參數，必須用與輸入參數的@param相同的描述信息。

必要的時候註明特殊條件寫的返回值。

3.2.3 @throws 標記
@throws以前使用的是@exception。

@throws的內容必須在函數的throws部分定義。

3.2.4 @author標記
類注釋標記。

函數注釋裡面可以不出現@author。

3.2.5 @version
類注釋標記。

文章出處：http://www.diybl.com/course/3_program/java/javajs/2008911/141971.html

⑶ 運用Spring+MyBatis基於註解方式編程時，大致的流程是什麼請大蝦說的簡單易懂點。。

spring和mybatis與spring與hibernate感覺沒什麼太大的區別...只不過就是hibernate中的裡面的對資料庫的操作放在mybatis的mapper文件中...

如圖...service調用的是層裡面的介面....為了方便每個介面都對應一個mapper文件...

這個執行層介面裡面的方法的時候會找到mapper文件去執行對應的配置....不知道我這樣解釋樓主能不能看懂...

⑷ C語言里有哪些注釋方法

答：在用C語言編程時，常用的注釋方式有如下幾種：
（1）單行注釋 //…
（2）多行注釋 /*…*/
（3）條件編譯注釋 #if 0…#endif
拓展資料：

對於(1)，注釋只能顯示在一行內，通常出現在一條語句的右邊或者上方，對於注釋符」//」，一個注釋里只要有多餘2個』/』都可以。
對於(2)，」/*…*/」不能嵌套使用，正如」if…else」中的」else」總是和隔它最近的」if」配對一樣，」/*」總是和離它最近的」*/」相配對。
針對(1)和(2)各自的缺陷，資深的程序員提出如(3)所示的注釋，該注釋的好處是能注釋大塊的程序，並且沒有嵌套的限制，也就是說在」#if 0…#endif」的」…」處可以有」//」或」/*…*/」這樣的注釋。

⑸ 程序注釋的方式有幾種

一，在Java語言中，注釋有兩種：

1. 單行注釋

   //注釋內容

2. 多行注釋

   /**

   *注釋內容

   */

二，在xml或者HTML中；注釋主要為

<!--注釋內容-->

三，在Python和一般項目配置文件中；注釋主要為

#注釋內容

具體情況要具體分析，你編程使用什麼語言的可以寫出來；一般學習編程教程的初始過程中都會有這方面的知識介紹的，你可以留意一下。

⑹ spring的事務使用有幾種方式註解式事務如何配置和使用

Spring提供的事務管理可以分為兩類：編程式的和聲明式的。

編程式的，比較靈活，但是代碼量大，存在重復的代碼比較多；聲明式的比編程式的更靈活方便。

1、傳統使用JDBC的事務管理

以往使用JDBC進行數據操作，使用DataSource，從數據源中得到Connection，我們知道數據源是線程安全的，而連接不是線程安全的，所以對每個請求都是從數據源中重新取出一個連接。一般的數據源由容器進行管理，包括連接池。例如TOMCAT，WEBSPHERE，WEBLOGIC等這些J2EE商業容器都提供了這個功能。

以往的我們使用JDBC在寫代碼時，事務管理可能會是這樣：

Connection conn = null;
try{
conn = DBConnectionFactory.getConnection;
conn.setAutoCommit(false);
//do something
conn.commit(); //commit transcation
}catch(Exception e){
conn.rollback();
}
finally{
try{
conn.close();
} catch(SQLException se){ //do sth.}
//close ResultSet,PreparedStatement,Connection
//notice:Maybe ocurr Exception when u close rs,pstmt,conn
}

按照以往的思路來寫代碼，代碼量比較長，而且容易疏忽，忘掉一些try/catch，引發一些異常無法catch，雖然有時候我們會寫DBTool類，來關閉這些資源，並且保證在關閉這些資源時，不向外拋異常，但是這樣做會導致額外的麻煩。

2、Spring提供的編程式的事務處理

Spring提供了幾個關於事務處理的類：TransactionDefinition //事務屬性定義

TranscationStatus //代表了當前的事務，可以提交，回滾。

PlatformTransactionManager這個是spring提供的用於管理事務的基礎介面，其下有一個實現的抽象類，我們使用的事務管理類例如DataSourceTransactionManager等都是這個類的子類。

我們使用編程式的事務管理流程可能如下：

(1) 聲明數據源。

(2) 聲明一個事務管理類，例如：DataSourceTransactionManager,HibernateTransactionManger,JTATransactionManager等

(3) 在我們的代碼中加入事務處理代碼：

TransactionDefinition td = new TransactionDefinition();
TransactionStatus ts = transactionManager.getTransaction(td);
try{
//do sth
transactionManager.commit(ts);
}catch(Exception e){transactionManager.rollback(ts);}

使用Spring提供的事務模板TransactionTemplate：

void add()
{
transactionTemplate.execute( new TransactionCallback(){
pulic Object doInTransaction(TransactionStatus ts)
{ //do sth}
}
}

TransactionTemplate也是為我們省去了部分事務提交、回滾代碼；定義事務模板時，需注入事務管理對象。

3、Spring聲明式事務處理

Spring聲明式事務處理也主要使用了IoC，AOP思想，提供了TransactionInterceptor攔截器和常用的代理類TransactionProxyFactoryBean，可以直接對組件進行事務代理。

使用TransactionInterceptor的步驟：

（1）定義數據源，事務管理類

（2）定義事務攔截器,例如：

＜bean id = "transactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor"＞
＜property name="transactionManager"＞＜ref bean="transactionManager"/＞＜/property＞
＜property name="transactionAttributeSource"＞
＜value＞
com.test.UserManager.*r=PROPAGATION_REQUIRED
＜/value＞
＜/property＞
＜/bean＞

（3）為組件聲明一個代理類：ProxyFactoryBean

＜bean id="userManager" class="org.springframework.aop.framework.ProxyFactoryBean"＞
＜property name="proxyInterfaces"＞＜value＞com.test.UserManager＜/value＞＜/property＞
＜property name="interceptorNames"＞
＜list＞
＜idref local="transactionInterceptor"/＞
＜/list＞
＜/property＞
＜/bean＞

使用TransactionProxyFactoryBean：

＜bean id="userManager"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"＞
＜property name="transactionManager"＞＜ref bean="transactionManager"/＞＜/property＞
＜property name="target"＞＜ref local="userManagerTarget"/＞＜/property＞
＜property name="transactionAttributes"＞
＜props＞
＜prop key="insert*"＞PROPAGATION_REQUIRED＜/prop＞
＜prop key="update*"＞PROPAGATION_REQUIRED＜/prop＞
＜prop key="*"＞PROPAGATION_REQUIRED,readOnly＜/prop＞
＜/props＞
＜/property＞
＜/bean＞

TransactionProxyFactoryBean只是為組件的事務代理，如果我們要給組件添加一些業務方面的驗證等，可以使用TransactionTemplate加攔截器方式，為組件添加多個攔截器，spring AOP中提供了三類Advice,即前增強，後增強，拋出異常時的增強，可以靈活使用。

⑺ 程序為什麼要加註釋加註釋有幾種方法各有何特點

注釋為對代碼的解釋和說明，其目的是讓人們能夠更加輕松地了解代碼。注釋為編寫程序時，寫程序的人給一個語句、程序段、函數等的解釋或提示，能提高程序代碼的可讀性。注釋只是為了提高可讀性，不會被計算機編譯。

注釋通常會分為行注釋和塊注釋。

行注釋：在符號後那一行不會被編譯（顯示）；塊注釋：被塊注釋符號中間的部分不會被編譯。

(7)註解式編程擴展閱讀

C語言的注釋符以「/*」開頭並以「*/」結尾的串。在「/*」和「*/」之間的即為注釋。程序編譯時，不對注釋作任何處理。注釋可出現在程序中的任何位置。

注釋用來向用戶提示或解釋程序的意義。在調試程序中對暫不使用的語句也可用注釋符括起來，使翻譯跳過不作處理，待調試結束後再去掉注釋符。

可以使用多種方法創建文字。對簡短的輸入項使用單行文字。對帶有內部格式的較長的輸入項使用多行文字（也稱為多行文字）。也可創建帶有引線的多行文字。

雖然所有輸入的文字都使用建立了默認字體和格式設置的當前文字樣式，但也可以使用其他的方法自定義文字外觀。有一些工具可以方便用戶修改文字比例和對正、查找和替換文字以及檢查拼寫錯誤。

⑻ 關於各種編程語言的注釋

c
行注釋：none
塊注釋：/*這里是注釋*/
擴展名：.c/.h

c++
行注釋：//這里是注釋
塊注釋：/*這里是注釋*/
擴展名：.cpp/.h

vb
行注釋：'這里是注釋
塊注釋：none
擴展名：.bas

java
行注釋：//這里是注釋
塊注釋：/*這里是注釋*/
擴展名：.java

.net
dotnet is not a language!
is a platform.

vb.net
行注釋：'這里是注釋
塊注釋：none
xml注釋：///這里是xml注釋
擴展名：.vb

perl
行注釋：#這里是注釋
塊注釋：none
擴展名：.pm

c#
行注釋：//這里是注釋
塊注釋：/*這里是注釋*/
xml注釋：///這里是xml注釋
擴展名：.cs

html
行注釋：none
塊注釋：<!--這里是注釋-->
擴展名：.htm/.html

⑼ 三菱GX編程軟體中，註解、聲明、這兩項是什麼意思，怎麼使用

聲明編輯是對一段程序進行注釋，只能在一段程序（LD開始的地方）的上方左母線處，註解編輯是對靠近右母線處的輸出進行注釋

⑽ java中常用註解分別是什麼及漢語意思!

Annotation(註解)是JDK5.0及以後版本引入的。它可以用於創建文檔，跟蹤代碼中的依賴性，甚至執行基本編譯時檢查。注釋是以『@注釋名』在代碼中存在的，根據注釋參數的個數，我們可以將注釋分為：標記注釋、單值注釋、完整注釋三類。它們都不會直接影響到程序的語義，只是作為注釋（標識）存在，我們可以通過反射機制編程實現對這些元數據的訪問。另外，你可以在編譯時選擇代碼里的注釋是否只存在於源代碼級，或者它也能在class文件中出現。

元數據的作用
如果要對於元數據的作用進行分類，目前還沒有明確的定義，不過我們可以根據它所起的作用，大致可分為三類：
編寫文檔：通過代碼里標識的元數據生成文檔。
代碼分析：通過代碼里標識的元數據對代碼進行分析。
編譯檢查：通過代碼里標識的元數據讓編譯器能實現基本的編譯檢查。

基本內置註解

@Override java中覆寫
@Deprecated的作用是對不應該在使用的方法添加註釋，當編程人員使用這些方法時，將會在編譯時顯示提示信息，它與javadoc里的
@deprecated標記有相同的功能，准確的說，它還不如javadoc
@deprecated，因為它不支持參數

@SuppressWarnings,其參數有：
deprecation，使用了過時的類或方法時的警告
unchecked，執行了未檢查的轉換時的警告
fallthrough，當 Switch 程序塊直接通往下一種情況而沒有 Break 時的警告
path，在類路徑、源文件路徑等中有不存在的路徑時的警告
serial，當在可序列化的類上缺少 serialVersionUID 定義時的警告
finally ，任何 finally 子句不能正常完成時的警告
all，關於以上所有情況的警告

自定義注釋
它類似於新創建一個介面類文件，但為了區分，我們需要將它聲明為@interface,如：public @interface NewAnnotation {}............