java与java ee_Java EE 8怎么了？

java与java ee

Java EE 8的工作进展顺利。是时候赶上了！无需费力就可以潜入…

不要忘记Java EE 7…..

围绕三个重要主题

HTML 5对齐–用于WebSocket的Java API（JSR 356），JSON处理（JSR 353），JAX-RS 2.0（JSR 339）
开发人员生产力– CDI 1.x，JMS 2.0（JSR 343）
满足企业需求–并发实用程序（JSR 236），批处理应用程序API（JSR 352）

其他规格的重大改进

EJB 3.2
JMS 2.0
Servlet 3.1
JPA 2.1
JSF 2.2
Bean验证1.1
拦截器1.2

注意：Java EE 7中新增了用于WebSocket的Java API（JSR 356），JSON处理（JSR 353），并发实用程序（JSR 236）和批处理应用程序API（JSR 352）。

认证的应用服务器（全面的Java EE平台支持）

玻璃鱼
野蝇
麦克斯
OracleWeblogic

注：*的Oracle WebLogic 12.1.3具有以下的Java EE 7 种规格的支持- JAX-RS 2.0，可将WebSocket 1.0，JSON-P 1.0 *

Java EE 7在现实世界又称为生产环境中的表现如何？

看看Arun Gupta的这张幻灯片分享（我相信您很快就会获得实际的JavaOne演讲）。我敢肯定会有更大更好的部署。

继续支持Java EE 7并为之贡献力量！

访问认养JSR对Java EE和绝对看看这个JavaOne大会2014交谈，如果你想了解整个JCP过程和具体细节WRT认养JSR为Java EE 7和Java EE 8

JavaEE7.next（）= JavaEE8！

Java EE 8 aka JSR 366是Java Enterprise Edition Platform的下一版本。

主要主题和驱动因素

支持Java SE 8 –增强API以使用Java SE 8的最新功能
与不断发展HTML 5标准保持同步 –根据最新标准增强Web层技术（WebSocket，JSONP等）
与HTTP 2.0兼容 – Servlet 4.0捆绑了对HTTP 2.0标准的支持
与CDI的紧密集成 –将CDI支持扩展，改进和标准化到规范的其他部分（JAX-RS，WebSocket等）
改善基于云的应用程序的功能 –改善应用程序安全性，基于REST的管理API，多租户支持等

新规格

MVC 1.0（JSR 371）
JSON-B 1.0（JSR 367）
Java EE安全性1.0（JSR 375）
JCache（JSR 107）

更新规格

即将更新的规格如下

Servlet 4.0
CDI 2.0
JAX-RS 2.1
JSF 2.3
JMS 2.1
JSON-P 1.1
…。还有更多要遵循的

这篇文章将处理新的规格（到现在为止宣布）

MVC 1.0

顾名思义，目标是为Java EE定义标准的Model-View-Controller API。对于长期的Java EE开发人员，专家和追随者来说，第一个问题可能是， 为什么除了JSF之外还需要另一个MVC ？好吧，我强烈建议 Ed Burns （Oracle的JSF Spec Lead）撰写的这篇文章，这将有助于清除您可能存在的任何疑问。

带走以上帖子中的要点

JSF不会去任何地方。放心！实际上，JSF 2.3将成为Java EE 8的一部分（在以后的文章中对此有更多介绍）
从基于操作的MVC框架而不是基于组件的框架（如JSF）的角度来看待MVC 1.0 –因此，基本上，它们彼此之间有很大的不同

Java EE 8社区调查（PDF的第3页）的结果高度支持与JSF一起使用的另一个MVC框架。

显着特征

利用现有的Java EE技术
模型部分可能使用JPA（双向绑定黑白模型和DB），CDI（出于明显的原因）以及Bean验证
视图部分可能会重用现有的视图技术，例如JSP
控制器部分有一些选择–也许是JAX-RS或新规范？

注意： Jersey （JAX-RS参考实现）已经通过扩展提供了对MVC的支持（当然，这是专有的，到目前为止还不是JAX-RS标准的一部分）。 我建议偷看一下

快速链接

JCP官方页面
参考实施– Ozark
JavaOne 2014的最新演讲

JSON-B（JSR 367）

如果您使用过或使用过JAXB API，则JSON-B听起来会很熟悉。它是JAXB的JSON对应版本，其目标是定义一个API，该API将使开发人员能够借助注释将JSON数据绑定到Java域模型（类），并将这些POJO转换（编组/取消编组）为/在运行时从JSON中获取。在没有标准/纯JSON API的情况下，我们使用第三方库和框架，这些库和框架基本上以不同的方式解释POJO上的JAXB批注，以生成JSON而不是XML。当然，这带有一些缺点+警告，并且JSON-B希望通过提供标准且可移植的API来解决此问题，从而使我们更轻松地使用JSON数据和相应的Java域对象。

显着特征

将利用现有的JSON-P （Java EE 7中引入的JSON处理）API，即在其之上构建一个API层
与其他几个规范（针对Java SE 8和Java EE 8）不同，它可以在Java SE 7和Java EE 7上运行
为了促进快速和容易的采用，API的一般使用模式/术语将类似于JAXB

JSONContext jsCtx = JSONContext.getInstance(Speaker.class); Unmarshaller jsonUnmarshaller = jsCtx.createUnmarshaller(); Speaker speaker = (Speaker) jsonUnmarshaller.unmarshal(new File("speaker-detail.json"));

快速链接

JCP官方页面
参考实现– EclipseLink
JavaOne 2014的最新演讲

Java EE安全性1.0（JSR 375）

Java EE安全性规范旨在提供简化的安全性API（duh！），可使Java EE应用程序以独特但可移植的方式管理其自己的安全性参数。像JSON-B和MVC一样，此JSR也是社区强烈反馈的结果。请参阅Java EE 8社区调查结果的第12,13页。此JSR背后的另一个主要动机是帮助基于云的Java EE应用程序部署，其中定义安全性方面的标准且可移植的方式是非常需要的功能。

注意：如果您使用过PicketLink或听说过PicketLink ，则此API听起来可能很相似

显着特征

用户和角色管理

这两个领域尚未通过Java EE进行标准化
这个想法是提供一个API与用户和角色存储库（RDBMS，符合LDAP的目录服务器等）进行交互，并执行与用户和角色相关的操作，例如用户CRUD，角色-用户关系CRUD

认证方式

提供针对特定Java EE应用程序的存储库的功能（基于上述用户和角色管理API）
通过HttpServletRequest进行身份验证的异步API
借助不同的身份验证方法在单个Java EE应用程序中启用不同的Servlet，例如，您可以为属于单个Web应用程序的不同Servlet配置基于表单和基本的身份验证机制

授权 – 除了已经存在的基于角色的访问控制之外，还为方法级别访问引入细粒度的标准（基于应用程序要求的规则）。

密码别名 – 引入密码别名 （基于标准语法）的概念，该概念需要解析为实际的密码值，该密码本身将与应用程序一起存储在安全的自包含档案中。 总体而言，目标是促进在Java EE应用程序中处理密码存储和检索的安全和标准化方法。