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平台支持)
注 :*的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"));
快速链接
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应用程序中处理密码存储和检索的安全和标准化方法。
快速链接
JCache(JSR 107)
JSR 107提供了一个标准的可移植API,供需要Java对象的内存缓存的应用程序使用。 好消息是,此JSR的工作已经完成。 就Java EE 7而言,它错过了总线,但是很可能会从Java EE 8开始集成到Java EE堆栈中。
快速链接
我将在以后的文章中写有关Java EE 8中更新的规范。 有关Java EE的最新信息和最新信息,敬请关注The Aquarium !
翻译自: https://www.javacodegeeks.com/2014/12/whats-up-with-java-ee-8.html
java与java ee