JSR Review
- Java EE 8 Platform, JSR 366
- Latest web standards: Server-Sent Events, JSON Binding, HTTP 2.0, improvements to WebSocket and JSON-P, MVC
- Ease-of-use: Declarative security using CDI, notification of timed events using CDI event and observer mechanism
- Infrastructure for cloud support: Configuration of multiple tenants, simplified and improved security configuration; and REST-based APIs for monitoring and management
- Alignment with Java SE 8: Repeating annotations, lambda expressions, Date/Time API, Type annotations, Completable features, etc.
- Candidate JSRs: JCache, JSON-B, Java Configuration
- Web Profile: JSON-B will likely be included
- Pruning: EJB 2.x client view APIs and support for CORBA IIOP interoperability
- MVC 1.0 (JSR 371)
- Leverage existing Java EE technologies
- Model part should leverage CDI and Bean Validation
- View part should leverage existing view technologies like JSPs and Facelets
- Controller could be either JAX-RS based, invent a new technology, or defined a technology-independent way of defining
- Out of scope to define a new templating language, existing language should be evaluated, possibly define an SPI for additional ones to be integrated
- JSON Binding 1.0 (JSR 367)
- Standard way to convert JSON into Java objects and vice versa.
- JSON-B will leverage JSON-P and provide a conversion layer above it.
- A default mapping algorithm will be defined for converting existing Java classes to JSON. The default mappings can be customized through the use of Java annotations and will be leveraged by the JSON-B runtime to convert Java objects to/from JSON.
- Requirements from upper layers of JAX-RS
- JSON-B will have a similar feel to JAXB
- CDI 2.0 (JSR 365, @cdispec)
- Split CDI into two parts: Core CDI programming model and Java EE integrations for CDI
- Define a portable bootstrap API for CDI
- Overhaul thread-bound request-response context model, allow the application or container to portably push the active context to CDI when it requires the use of CDI
- Introduce modularity to CDI, CDI 2.0 Modularity Proposal
- Define a lightweight container
- Servlet 4.0 (JSR 369, @servlet_spec)
- Expose support for the upcoming IETF standard HTTP/2 to users of the Servlet API
- Request/response multiplexing
- Stream prioritization
- Server push
- Upgrade from HTTP 1.1
- Refresh the Servlet API with to achieve compliance with new features in
HTTP 1.1
- Responding to community input
- Java EE Security API 1.0 (JSR 375)
- Holistically attempt to simplify, standardize, and modernize the Security API
- User management: Standardized user service which would enable an application to perform user management operations, such as create, delete, update, and group users
- Password aliasing: Standardized syntax for indicating password alias, and a means for resolving the alias to a password value
- Role mapping: Standardized role service which would enable an application to perform role mapping operations, such as granting, revoking, and querying user and group roles
- Authentication
- Configurable user service and role service
- Each servlet to be configured with different authentication methods within a single web application
- Add an API to enable HttpServletRequest.authenticate to operate asynchronously
- Authorization: Standardized method interceptor annotation capable of incorporating application-based rules into the method access decision
- Java EE Management API 2.0 (JSR 373)
- Supersede the current Management EJB APIs and define new REST-based interfaces for describing managed objects
- REST interfaces will expose managed objects as a URL, and CRUD operations will be provided. SSE/WebSocket will be considered to provide notifications
- Deployment will be included directly into the management REST interface
- Application deployment, resource definition, and management can be done using the same interface
- JAX-RS 2.1 (JSR 370)
- Adding support for Server-Sent Events
- Improving integration with CDI
- Exploring support for non-blocking I/O in providers (filters, interceptors, etc)
- Evaluating ways in which declarative security can be supported either directly in this JSR or by leveraging other EE-platform JSRs
- Making JAXB conditional on runtimes where it is available
- Providing integration with JSON-B
- Building upon the hypermedia API added in version 2.0
- Investigate the reactive programming paradigm as a way to improve the JAX-RS asynchronous client API
- Evaluating any requirements necessary to support the use of JAX-RS resource classes as as controllers in the MVC 1.0 JSR
- JSF 2.3 (JSR 372, @jsf_spec)
- Ajax method invocation: Allows invoking CDI managed bean methods directly from Ajax, all owing the response to be sent using standard JSON
- Community input: multi-field validation, @Inject FacesContext, EL
performance optimizations, and cross-form Ajax clarifications
- Better integration with Java EE 8 and Java SE 8
- JMS 2.1 (JSR 368, @jms_spec)
- Simplifying and extending the API required to receive messages asynchronously
- Portability of JMS providers within Java EE servers will be improved
- Clarify “application server facilities” in chapter 11 of JMS 2.0
- Clarify JCA resource adapter relationship
- Improvements in JMS provider in Java EE transaction
- Corrections and minor enhancements
- Java API for JSON Processing 1.1 (JSR 374)
- Support for JSON Pointer and JSON Patch
- Add editing/transformation operations to JSON object model
- Update the API to work with Java SE 8
- Java API for WebSocket 1.1 (JSR 356)
- Session.addMessageHandler(MessageHandler) now work with lambda
expressions (WEBSOCKET_SPEC-226)
JSR TBD
- Configuration (May 15, 2014) (@javaconfig)
Other Links
- Java EE 8 Community Survey Results
- Completed JSRs
Java EE 8 is nice.
What is the future of JSF and JavaFX. Especially I am interested in JSF which was adopted widely in industry, but now is rejected. Still there are jobs in JSF, and also support for existing JSF applications is required. Java students should learn JSF as it is easy to develop and is different from other UI development frameworks.
I believe a new version of JSF should be worked on. A JSF which is client side, which means a UI framework with HTML, CSS, JavaScript, etc. which is more suitable for modern UI development. Newer JSF can competete with Angular, etc.
May be JSF 3.0 or a new name, a framework which makes very easy for a Java developer to develop UI with minimal or no knowledge of HTML, CSS, Angular.
My favorite ones are JCache and JSON-B.
The user management from Java EE security sounds promising, but that’s to be seen in real life. Though there are a number of applications that do authentication within the application, there’s also the other side of the fence with enterprise applications to provide a single-sign-on capability which JASPI already provides.
As far as UI facing technologies such as JSF, I think they should abandon it. It can’t catch up fast enough to UI technologies such as HTML5, Angular, iOS Native, Android Native etc. However, JSPs should still be around primarily for legacy and quick test applications.
Please,
make jee8 web profile as similar as possible to seam 2.3 jpa application framework …
after 7 years there is no real replacement to the EntityHome / EntityQuery pattern with open session in view and page scope (ViewScope) …
even jsf 2.2 + cdi + deltaspike is not yet simple and powerful as seam 2.3 … my 2 cents after 6 years of seam programming 😉