注解式编程

⑴ 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 {}............