java与java ee
在Java EE 7发布一年多之后，Java Community Process（JCP）机制再次开始在Java EE上发展。 目标是创建Java Enterprise Edition的下一个主要版本。 符合Java EE 8和JSR 366 ！
该版本将以该平台非常成功的先前版本为基础，并增加了许多新功能。 某些主要由于调度约束而不能包含在最后一个发行版中的JSR，也打算在此处包含。 那么，发布的主要主题是什么？
支持最新的Web标准，例如HTML5服务器发送的事件，JSON文本和Java对象之间的标准化绑定，HTTP / 2支持，基于动作的MVC，针对WebSocket和JSON处理的Java API更新。
HTTP / 2，基于动作的MVC和JSON绑定等某些功能是对该平台的相当大的补充，并作为单独的JSR归档。 其他一些是相关的，但可以在其他组件JSR中轻松使用。
通过跨规格的CDI对齐，可以进一步简化编程模型 。 今天，声明性安全性和@Schedule只能在Enterprise JavaBeans上指定。 我们的目标是使其更普遍地适用于POJO。
现在，这会使EJB编程模型过时吗？ 只有时间和开发人员才能证明。 但是，如果是这样，则需要提取EJB的一些独特功能，例如远程处理，并发性和池化，并将其更广泛地应用于POJO。 JAX-RS有一些需要清除的区域，例如CDI对齐，服务器端异步和更简单的超媒体API。 较早的EJB 2样式API和CORBA IIOP互操作性也针对修剪。
-
云支持的基础架构 。 Java EE 7中添加了对云基础结构的一些基本支持，例如JPA 2.1中的模式生成和JSF 2.2中的资源库模板。 此版本将对其进行扩展，以增加应用程序的灵活配置，例如多租户和简化的安全性。 用于管理和监视的基于REST的API将允许构建自定义的仪表板，该仪表板可在不同的应用程序服务器之间移植。
Java SE 8对齐。 Java SE 8引入了一些新功能，例如重复注释 ，lambda表达式，Date / Time API，类型注释和CompletableFuture 。 鼓励组件JSR利用这些功能。 例如，可以弃用@ DataSourceDefinitions，@ JMSConnectionFactoryDefinitions，@ MailSessionDefinitions，@ Schedules和其他类似的注释，以便重复注释。 表达式语言自己添加了对Lambda表达式的支持，这主要是由于Java EE 7和JDK 8计划未对齐。 现在将需要用JDK 8标准替换该支持。 JPA还可以利用Date / Time API中的所有优势。
这是到目前为止已提交的组件JSR的功能的快速概述：
-
利用现有的Java EE技术
模型应利用CDI和Bean验证
视图应利用现有的视图技术，例如JSP和Facelets
控制器可能基于JAX-RS，或者可能是使用某些新技术定义的。 还可以考虑定义控制器的与技术无关的方式。
定义新的模板语言已超出范围。 应该评估现有的语言，例如Freemarker，Velocity和其他语言，并可能定义一个SPI以集成其他语言
-
将JSON转换为Java对象的标准方法，反之亦然。
JSON-B将利用JSON-P并在其上方提供一个转换层。
将定义默认的映射算法，用于将现有的Java类转换为JSON。 可以通过使用Java注释自定义默认映射，并且JSON-B运行时将利用默认映射在Java对象与JSON之间进行转换。
来自JAX-RS上层的需求
JSON-B将具有与JAXB类似的感觉
-
CDI 2.0（JSR 365） （ @cdispec ， cdi -dev ）
将CDI分为两部分：核心CDI编程模型和针对CDI的Java EE集成
为CDI定义可移植的引导API
检修线程绑定的请求-响应上下文模型，允许应用程序或容器在需要使用CDI时将活动上下文可移植地推送到CDI
向CDI， CDI 2.0模块化提案中介绍模块化
定义一个轻量级的容器
-
Servlet 4.0（JSR 369） （ @ servlet_spec ， users @ servlet-spec ）
-
向Servlet API用户公开对即将到来的IETF标准HTTP / 2的支持
请求/响应多路复用
流优先级
服务器推送
从HTTP 1.1升级
刷新Servlet API，以实现与的新功能兼容
HTTP 1.1
回应社区的意见
-
-
JAX-RS 2.1（JSR 370） （ users @ jax-rs-spec ）
添加对服务器发送事件的支持
改善与CDI的集成
在提供程序（过滤器，拦截器等）中探索对非阻塞I / O的支持
评估可以直接在此JSR中或通过利用其他EE平台JSR支持声明式安全性的方式
使JAXB取决于可用的运行时
提供与JSON-B的集成
基于2.0版中添加的超媒体API
研究React式编程范例，作为改进JAX-RS异步客户端API的一种方法
与MVC JSR保持一致
-
JSF 2.3（JSR 372） （ @jsf_spec ， users@javaserver-faces-public.java.net ）
Ajax方法调用：允许直接从Ajax调用CDI托管bean方法，从而允许使用标准JSON发送响应
社区输入：多字段验证，@ Inject FacesContext，EL性能优化和跨格式Ajax澄清
与Java EE 8和Java SE 8更好的集成
-
JMS 2.1（JSR 368） （ @jms_spec ， users@jms-spec.java.net ）
简化和扩展异步接收消息所需的API
JMS提供程序在Java EE服务器中的可移植性将得到改善
澄清JMS 2.0第11章中的“应用服务器设施”
阐明JCA资源适配器关系
Java EE事务中JMS提供程序的改进
更正和较小的增强
JCache 1.0（JSR 107）终于进入了最终定论，因此将成为该平台的候选者。 同样，还将考虑将MVC 1.0和JSON-B 1.0包括在内。 请注意，专家组将决定是否将此规范包含在Java EE 8中。即使没有明显的理由让EG否则采用，该决定仍然取决于他们。
Anatole Tresch与Configuration JSR共享了建议 。 根据Java EE 8社区调查 ，有64％的人要求此JSR。 如果无法将其包含在平台中，那将是一种耻辱，但现在看来，它已经死在水里了 。
调查结果还显示，有超过70％的人要求进行标准化的测井，但该地区似乎没有发生任何事情。 还为简化安全性提供了强有力的支持。 但是，有传言称要使用单独的JSR来解决安全问题，所以让我们拭目以待。
其他一些组件JSR已经通过维护版本发布，因此平台中将包含更新的版本。 未来几天应提交更多的组件JSR。
接下来会发生什么？ JSR已提交，最近已由JCP执行委员会一致批准 。 现在，将成立专家组，届时将开始大部分工作。 这通常涉及讨论范围，准备提案，召开EG会议，javadocs，API，审阅等。所有JSR都遵循JCP 2.9 ，这需要早期草案，公共评审，提议的最终草案和最终发布中的一项或多项。 当然，参考实现和TCK以及所有这些。
尽管Oracle取消了 GlassFish的商业支持，但仍会在Java EE 8中为GlassFish提供参考实现。因此，不同组件的初始实现将在其各自的项目中开始，例如，CID的Weld，JAX-RS的Jersey，新的。专为JSON-B和MVC创建的项目，等等。 但是最终他们将开始集成到GlassFish 5中。
Java EE 8的暂定时间表是：
2014年第三季度专家组成立
2015年第一季度初稿
2015年第三季度公众评论
2015年第4季度拟议最终草案
2016年第三季度最终版本
鉴于Java EE 7 （JSR 342）的原始时间表已从2012年第3季度更改为2013年第1季度，让我们看一下该时间表的现实程度。 Java社区中的每个人都将密切关注规范的发展。 但就是不要坐在外面看。 像上次一样，将采用JSR，只是这次是从早开始。 通常，请阅读每个JSR的建议范围，并至少就其中一些共享您对上述别名的评论。 至少在这里分享您的想法。 JCP已安排JavaOne的Hackergarten来获得有关Java EE 8的早期反馈，因此请务必检查一下。
就个人而言，我希望看到规范过程中的更多开放性。 特别是，我希望看到使用AsciiDoc编写的所有Java EE 8规范，因为它们真正促进了协作。 CDI和Bean验证已经使用它来进行规范创作，这使每个人都可以透明地观察过程。
JavaOne即将来临，很高兴看到社区对Java EE 8的React。
您始终可以在此处找到Java EE 8的最新状态。
java与java ee
扫一扫
2564
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
