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大会交谈 ,如果你想了解整个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-ControllerAPI。 对于长期的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 的最新演讲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的一般使用模式/术语将类似于JAXBUnmarshaller jsonUnmarshaller = jsCtx.createUnmarshaller(); Speaker speaker = (Speaker) jsonUnmarshaller.unmarshal(new File("speaker-detail.json"));JSONContext jsCtx = JSONContext.getInstance(Speaker.class);
快速链接
JCP官方页面 参考实现– EclipseLink JavaOne 的最新演讲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应用程序中处理密码存储和检索的安全和标准化方法。
快速链接
JCP官方页面JCache(JSR 107)
JSR 107提供了一个标准的可移植API,供需要Java对象的内存缓存的应用程序使用。 好消息是,此JSR的工作已经完成。 就Java EE 7而言,它错过了总线,但是很可能会从Java EE 8开始集成到Java EE堆栈中。
快速链接
JCP官方页面 规格文件 参考实施 兼容实现列表 JavaOne 的最新演讲我将在以后的文章中写有关Java EE 8中更新的规范。 有关Java EE的最新信息和最新信息,敬请关注The Aquarium !
翻译自: //12/whats-up-with-java-ee-8.html
java与java ee