Java EE 7 三大新特性的介绍

Sky-Tiger

cpus_allowed 和 mems_allowed 定义了该 cpuset 包含的 cpu 和内存节点。
Parent 字段用于维持 cpuset 的树状结构，stack_list 则用于遍历 cpuset 的层次结构。
Pn 和 relax_domain_level 是跟 Linux 调度域相关的字段，pn 指定了 cpuset 的调度域
的分区号，而 relax_domain_level 表示进行 cpu 负载均衡寻找空闲 cpu 的策略。
除此之外，进程的 task_struct 结构体里面还有一个 cpumask_t cpus_allowed 成员，
用以存储进程的 cpus_allowed 信息;一个 nodemask_t mems_allowed 成员，用于存储进
程的 mems_allowed 信息。
Cpuset 子系统的实现是通过在内核代码加入一些 hook 代码。由于代码比较散，我们逐条
分析。
在内核初始化代码（即 start_kernel 函数）中插入了对 cpuset_init 调用的代码，这个
函数用于 cpuset 的初始化。
下面我们来看这个函数：
int __init cpuset_init(void)
{
int err = 0;
if (!alloc_cpumask_var(&top_cpuset.cpus_allowed, GFP_KERNEL))
BUG();
cpumask_setall(top_cpuset.cpus_allowed);
nodes_setall(top_cpuset.mems_allowed);
fmeter_init(&top_cpuset.fmeter);
set_bit(CS_SCHED_LOAD_BALANCE, &top_cpuset.flags);
top_cpuset.relax_domain_level = -1;
err = register_filesystem(&cpuset_fs_type);
if (err < 0)
return err;
if (!alloc_cpumask_var(&cpus_at

Sky-Tiger

　6月12日，Java EE 7 发布。对企业社区来说，这是一个非常激进的 Java EE 的主要版本。特点：
下一代的 Web 应用开发技术
提升开发者生产力
满足企业要求
　　首先：包含全新的 Web 应用开发方法，包括 HTML5, WebSockets, JSON, RESTful 服务和 Servlet 3.1 NIO. 这些技术允许实现可伸缩、可移植低延迟的 Web 应用。
　　其次：提升开发者生产力的策略是基于 Java 编程语言的注解功能，减少了样板代码，更方便的开发各种集成服务，包括 标准化的 RESTful 服务。
　　最后：这是关于 Java EE 首次实现批量应用，包括并发工具包和 JMS 的修订。
　　Java EE 7 的网站： New Java EE 7 .
　　致敬，全新的 Java EE 7，真的非常棒，是否意味着 Spring 框架过时了呢？

Sky-Tiger

提高开发人员的生产力
从 Java EE 5 开始，重心就一直放在提高开发人员的生产力上。这对于 Java 开发者来说非常重要，因为这使得使用 Java EE 进行开发更加便捷，更重要的是能够满足快速管理和生产的需求。鉴于此，Java EE 7 大大提高了开发人员的生产力。首先，减少了编写大量核心业务逻辑所需要的样板代码。其次，该平台引入更多的注释 POJOS 来降低 XML 配置的复杂性。最后，Java EE 7 使用更紧密集成的技术，提供一个更加无缝的开发体验。
减少冗余代码
Java EE 7 一直在致力于减少在核心业务逻辑代码运行前必须执行的样板代码。减少样板代码的三大核心区域是默认资源、JMS 2.0 和 JAX-RS 客户端 API。默认资源是一个新的功能，要求平台提供商预配置一个默认的数据源和一个默认的 JMS 连接工厂。这可以让开发人员直接使用默认的资源而无需进行额外的定义。JMS2.0 在可伸缩性和可移植性上经历了重大的改进，减少了冗余代码，已运用在无数的产品部署上，事实证明它是一个良好的规范，能够较好地满足企业的需求。
更多带注释的POJO
通过注释 Java EE 使开发人员更专注于 Java 对象的编程而无需关注繁琐的配置。
CDI 现在默认情况下已不需要使用 beans.xml 文件就可以直接使用。开发人员可以不需要任何配置而是简单的使用 @Inject 来注入任何 Java 对象。包括新的资源注释 @JMSDestinationDefinition 和 @MailSessionDefinition ，使得开发人员在源代码中就可以指定元数据资源，简化了 DevOps 体验。
更紧密集成的平台
Java EE 6 引入了 Managed Beans 1.0 作为第一步来朝着 EJBs、JSF Managed Beans 和 CDI beans 发展。Java EE 7 继承了这一点，例如，对 JSF Managed Beans 进行了改进来更好支持 CDI Beans。Java EE 7 为平台引入了易用的 EJB 容器管理事物，使用基于 CDI 拦截器的解决方案来保证事务可用在 CDI managed beans 和其它 Java EE 组件中，把注释 @Transactional 应用到任何 CDI bean 或者任何支持事务的方法中。
Bean Validation 在 Java EE 7 中使用广泛，现在可以用于方法级别的验证，包括内置和自定义的约束。约束可被应用于方法的参数以及返回值。约束也可以使用灵活渲染和违反约束的字符串格式的 Java EE 的表达语言。
Bean Validation 也延伸到 JAX-RS 2.0。注释约束可以应用到公共构造函数的参数、方法参数、字段和 bean 的属性。此外，他们还可以修饰资源类、实体参数和资源的方法。例如，约束可以通过 @ POST 和 @ PUT 应用于 JAX-RS 方法参数来验证表单提交的数据。
通过精简现有技术来简化Java EE
Java EE 7 中新增加了许多新的特性，有些老的特性和功能已经被更简单的特性所替代或直接弃用。Java EE 6 为过时技术的弃用和功能的修剪引入了一个正式的流程，以下的 API 在 Java EE 7 中已成可选，但在 Java EE 8 中将会被移除：
Java EE Management (JSR-77)，原本是用于为应用 服务器创建监控管理的 API，可各大供应商对此 API 热情并不高涨；
Java EE Application Deployment (JSR-88)，JSR 88 是当初用于 J2EE 应用程序在应用 服务器上进行配置和部署的标准 API 。可是该 API 始终没有得到众供应商的支持；
JAX-RPC，是早期通过 RPC 调用和 SOAP web services 进行交互的编程模型。由于 Web services 成熟后从 RPC 模型中分离出来，被更加健壮和具备更多特性的 JAX-WS API 所替代；
EJB 2.x Entity Beans CMP，复杂、笨重、过度复杂的 EJB2.* 的 Entity Bean 模型已经被 Java EE 5 的基于 POJO 的流行轻量级 JPA 持久层模型所代替。

Sky-Tiger

对 HTML 5 动态可伸缩应用程序的支持
HTML5 是包括 HTML、JavaScript 和 CSS3 在内的一套技术组合，它加快了开发人员创建高度互动的应用程序的步伐。开发出的应用程序都是以高度互动的方式提供实时的数据，如聊天应用程序，比赛实况报导等，并且这些应用程序只需要编写一次，就可以应用在桌面、移动客户端等不同设备上，具有非常好的跨平台性。这些高度动态的应用程序，使得用户可以在任何地点任何时间进行访问，从而对服务器端向客户端传送数据的规模提出了更高的要求。Java EE 7 在更新现有技术如 JAX-RS 2.0、Java Server Faces 2.2、和 Servlet 3.1 NIO 基础上，又借助新的应用技术 WebSockets 和 JSON 处理为支持动态应用程序 HTML5 奠定了坚实的基础。
低延迟数据交换：Java API for WebSocket 1.0
越来越多的 web 应用程序依赖于从中央服务器及时获取并更新数据。基于 HTTP 的 WebSockets 为解决低延迟和双向通信提供了一种解决方案。在 WebSocket API 的最基层是一个带注释的 Java 对象（POJO），如清单 1 所示：
清单 1. 带注释的 Java 对象（POJO）
@ServerEndpoint("/test")
public class TestEndpoint{
@OnOpen
         public void onOpen(...){ }
@OnClose
         public void onClose(...){ }
     @OnError
public void onError(...){ }
@OnMessage
public void testMessage(String message,...){ }
}
通过注释 @ServerEndpoint 来指定一个 URI。诸如客户端连接、接收消息和客户端断开这样的回调函数都可以用注释来指定。WebSocket API 的最基层支持发送和接收简单文本和二进制信息。API 的简单性也使得开发人员可以快速入门。
当然，功能丰富的应用拥有更复杂的需求，因此需要支持对最基础的网络协议进行控制和自定义，而 WebSocket API 正好能够满足以上需求。另外，WebSocket 利用现有 Web 容器的安全特性，开发人员只需付出较少的代价就可以建立良好的保密通信。
简化应用数据分析和处理：Java API for JSON Processing 1.0
JSON 作为一个轻量级的数据交换格式被应用在许多流行的 Web 服务中用来调用和返回数据。许多流行的在线服务都是使用基于 JSON 的 RESTful 服务。在 Java EE 7 之前，Java 应用程序使用了不同的类库去生成和解析 RESTful 服务中的 JSON 对象。然而，现在这个功能已被标准化。
通过 Java API 中的 JSON Processing 1.0，JSON 处理过程标准化为一个单一的 API，应用程序不需要使用第三方的类库。这样使得应用程序更小更简便。同时 API 包括了支持任何转换器和生成器实现的插件，使得开发人员可以选择最好的实现方式去完成工作。
可扩展的RESTful服务：JAX-RS 2.0
JAX-RS 2.0 增加了异步响应处理，这对于支持对数据有着高要求的 HTML5 客户端的扩展是至关重要的。异步处理是一种更好更有效利用线程处理的技术。在服务器端，处理请求的线程在等待外部任务去完成时应该避免阻塞，从而保证在这一时间段内到达的其他请求能够得到响应。
同样的，在客户端，一个发出请求的线程在等待响应的时候也会发生阻塞，这影响了应用程序的性能。新的 JAX-RS 2.0 异步客户端 API 使得客户端调用 RESTful 可以和其他客户端活动并行执行。异步的好处是使得一个客户端可以同时调用多个后台服务，对于一个使用者来说减少了总体的延迟时间。
同时为了增强 RESTful 服务，JAX-RS 2.0 开发人员可以使用过滤器和实体拦截器。这样开发人员就可以使用标准的 API 来实现过滤和拦截功能，使开发过程变得更加便捷和高效。
增强开发的易用性：JSF 2.2
JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的 Java 新标准框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化了开发。在这个版本中，JSF 增加了对 HTML5 的支持。JSF 2.2 增加了一个叫“pass-through elements”的新功能。并为现有的元素增加了一系列的新属性，如输入元素“tel”、“range”和“date”等。不幸的是，现有的 JSF 组件不能识别这些新的属性，因此 JSF 应用程序会忽略这些属性不能进行使用，直到创建专有的解决方案。对于“pass-through elements”，JSF 渲染器将会忽略这些元素，只是把它们传给支持 HTML5 的浏览器，这使得可以利用现有的 JSF 组件来利用 HTML5 的特性来正常渲染。
JSF 引入了一个新的 pass-through 命名空间 http://xmlns.jcp.org/jsf/passthrough 映射到“p:”，任何组件的 name/value 对都可以以“p:” 开始，然后传给浏览器。如清单 2 所示，HTML 5 “type=color”不需要 JSF 组件的任何解析就可以传递给浏览器。
<h:inputText Value=”#{bean.color}” P:type=”color” />
HTML5 的动态性使得服务器端处理信息更新的请求不断增多。在 Java EE 6，Servlet 异步 I/O 通过移除“一个请求需要一个线程”的限制，使一个线程可以处理多个并发请求。这可以使 HTML5 客户端快速得到响应。但是，如果服务器端读取数据的速度比客户端发送的速度要快，那么可能会由于缓慢的客户端连接而不能提供更多的数据导致线程阻塞，这样就限制了扩展性。在 Java EE 7 中使用新的事件驱动 API Servlet 3.1 从客户端读取数据将不会造成阻塞。如果有数据可用时，Servlet 线程将会读取和处理这些数据，否则就去处理其他请求。

Sky-Tiger

满足苛刻的企业需求
Java EE 十几年来一直努力满足企业的需求，使用 Java 连接器连接到企业服务端、使用 Java 事务支持事务处理、使用 Java 消息服务让系统间可以进行相互通信。现在企业希望利用开发人员的 Java 技能编写基于标准的 API 并能够跨平台运行的批处理应用程序。企业也需构建高度可扩展的应用来满足更高的服务要求并提高现有资产的利用率。Concurrency Utilities 使得 Java EE 开发人员编写可扩展的应用程序成为可能。
在Java平台中，提高批处理应用程序的效率使开发过程变得更加便捷和高效
绝大部分的 Java EE 应用都是在线用户驱动的系统，但同时有一些需要进行批处理的服务器端应用程序，尤其是离线分析和 ETL 等。这些面向批处理的应用程序是非交互式的、需要长时间运行，这些任务通常需要大量计算，同时可以按顺序或者并行执行，并可以通过特定的事件启动或者定时调度。批处理较适合选择闲置的时间进行处理，这样可以有效利用计算机资源。
以前，对于批处理程序没有标准的 Java 编程模型。现在，批处理应用程序为 Java 平台提供了如图 2 非常容易理解的模型。批处理过程包括任务、步骤、存储库、读取 - 处理 - 写入模式和工作流等。
如图 2 所示，一个任务 job 代表一系列执行离散业务流程但又密切相关的步骤。步骤可以按顺序或者并行执行。同时，在同一个工作流，当前步骤是可选的，基于前一步骤的运行结果决定当前步骤将被执行或者跳过。另外，步骤可以根据实际的需要被重新执行。存储库 (repository) 存储了当前任务的信息，比如任务的最后执行时间。通过操作员 (operator) 可以对任务进行排序、开始、停止、暂停和取消操作。

Sky-Tiger

Java EE 8 展望
在 Java EE 7 发布后，开发人员对此似乎并不满足，对 Java EE 8 的新特性提出了一些设想与展望：
改进 CDI（Contexts and Dependency Injection for Java EE，上下文与依赖注入）。Java EE 8 应该支持所有 JSF 组件，包括转换器和验证器，以及 JASPIC 组件。
更深入的修剪 Pruning（）和 Deprecating（弃用）。应该延续 Java EE 6 和 Java EE 7 修剪与弃用的步伐，比如可以修剪 EJB 编程模型相关的所有东西。
标准化的缓存 API。JCache 缓存 API 原本将包含在 Java EE 7 中，但由于该 API 错过了重要的公共审查的最后期限，导致其没能成为 Java EE 7 的一部分。
平台范围内的配置。Java EE 应用程序可以使用部署描述文件（比如 web.xml）进行配置，但该方法对于不同的开发阶段（如 DEV、BETA、LIVE 等）来说比较麻烦，因为不同阶段会对应不同的服务器，从而导致配置也要随之改变。 期望 Java EE 8 能够以一种彻底的、统一平台的方式来解决这些配置问题。
综合的现代化的安全框架。在 Java EE 中，安全一直是一个棘手的问题。缺乏整体和全面的安全框架是 Java EE 的主要缺点之一，尤其是在讨论或评估竞争框架（如 Spring）时，这些问题会被更多地提及。期望在 Java EE 8 中，能够构建一个综合的和现代化的安全框架。
Java EE 8 目前尚处于规划初期，但愿上面提到的大多数特性能够以某种方式加以解决。

Sky-Tiger

Java EE 7规范JSR 342，它用自己的方式通过早期的草案审查专家小组，在一些开放问题上希望得到社区的反馈。包括新的APIs是否应当加入到Java EE Full Profile和Web Profile，以及如何更好的结合CDI和Java EE。这里有一个简短的调查。

同时，Java EE 7的范围已经缩小了很多--尤其是为了支持PaaS 提供者而计划的EE 7多租户（multi-tenancy）技术，也已经推迟到Java EE 8-- 这个规范仍包含一些重要更新。尤其是用于批处理的新的APIs，JCACHE（长时间运行的临时缓存API：一种对Java对象临时在内存中进行缓存的框架），处理JSON的新API和对Web Socket/HTML5的支持。

此外，3个较早的API将进行比较大的调整。

JAX-RS 2.0，为RESTfulWeb服务的Java API，有了一个新的客户端API，服务器端异步HTTP，过滤器和拦截器。
表达式语言（Expression Language，简称EL） ，EL 3.0支持在一个web容器外运行，新的操作符，Lambda表达式，还有一些其他特性。
JMS 2.0，强调简单化，包括实现Java 7java.lang.AutoCloseable接口的JMS 对象，以及简化在Java EE中定义JMS资源。此外，JMSXDeliveryCount将强制规定，让应用更简单地处理有害信息。新特性包括一个JMS客户端，能处理未来消息的传递，只要收到来自服务器端确认信息,就发送一个消息并得到无阻塞返回。

Sky-Tiger

完整计划的更新列表如下：

Java平台批处理应用程序(JSR 352)
Bean验证1.1 (JSR 349)
上下文和依赖注入1.1 (JSR 346)
企业级JavaBeans 3.2 (JSR 345)
表达式语言（EL) 3.0 (JSR 341)
处理 JSON 的 Java API 2.0 (JSR 353)
支持RESTfulweb 服务的 Java API 2.0 (JSR 339)
支持WebSocket的 Java API (JSR 356)
Java消息服务2.0 (JSR 343)
Java持久化 API 2.1 (JSR 338)
JavaServer Faces 2.2 (JSR 344)
JCACHE Java临时缓存API (JSR 107)
Java Servlet 3.1 (JSR 340)
Java EE 6是在2009年12月10日发布的，这意味着EE6和EE7发布间隔超过3年，这在规范发展史中是最长的。

Sky-Tiger

JAX-RS 2.0 using JSON and Persistence with JEE7
This post is about building a basic RESTful application with Maven using the JAX-RS 2.0 API (JSR339: JAX-RS 2.0). The data is exchanged using the JSON format. You will also see how JEE7 can simplify persistence for you. As server we will use Glassfish4 which contains the reference implementation of JEE7. At the end we will test our service with curl and with a unit test.

You can checkout this project from Github or download the archive here.

POM
So let's start. The only dependency we need in our pom.xml is the following:

?
1
2
3
4
5
6
<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>7.0</version>
    <scope>provided</scope>
</dependency>

Persistence
To be able to persist the data we first create a basic entity class, nothing special about that.

?
1
2
3
4
5
6
7
8
9
10
@Entity
public class Customer {

    @Id
    private long id;
    private String name;
     
    // getters, setters and others
    ...
}

Using JEE7 we now have the possibility of using a default datasource for persistence. The persistence.xml file looks a bit shorter though.

?
1
2
3
4
5
<persistence-unit name="mypu" transaction-type="JTA">
    <properties>
        <property name="javax.persistence.schema-generation.database.action" value="drop-and-create">
    </property></properties>
</persistence-unit>

That's all about your persistence configuration. Featured by JEE7 we will use a default datasource under java:comp/DefaultDataSource. This is defined in Glassfish4 and connects to an integrated Derby database instance.

Sky-Tiger

CRUD
To work with the Customer object we first need a service that handles the persistence. The following stateless bean offers the common CRUD functionality.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@Stateless
public class CustomerService {

    @PersistenceContext
    EntityManager em;

    public void create(Customer entity) {
        em.persist(entity);
    }

    public void update(Customer entity) {
        em.merge(entity);
    }

    public void remove(long id) {
        Customer customer = find(id);
        em.remove(customer);
    }

    public Customer find(long id) {
        return em.find(Customer.class, id);
    }
}

To make sure that Glassfish find our bean we also need the beans.xml in the WEB-INF directory.

?
1
2
3
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xsi:schemalocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all"></beans>

Make sure you use the bean-discovery-mode attribute because otherwise the container will not find your bean. At this point we are done with persistence so far.