Java ee 8 + security overview
•Download as PPTX, PDF•
3 likes•3,756 views
Java EE 8 Overview (Sept 2015). A lot of work is already done by the Expert Groups so lets have a brief look for what we can expect in the some areas. - Servlet 4 will embrace the new HTTP/2 protocol. - JSON-B will bring the same high level features of JAXB to the JSON data format. - Server-Sent Events(SSE) is the WebSocket variant where you only send data from the server to the client. - MVC will be the Action based MVC complement of the Component based MVC of JSF. - Some major restructuring of CDI so that we can use it standardised in Java SE to mention one thing. The Java EE security API will be covered in more detail. Security related things became old and dusty and needs to move away from proprietary configuration to be able to make the transition to the cloud. An introduction to JSR 375 is given, which promotes self-contained application portability across Java EE servers, and promotes the use of modern programming concepts such as Expression Language, and CDI. It will holistically attempt to simplify, standardize, and modernize the Security API across the platform in areas identified by the community.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Java ee 8 + security overview
Similar to Java ee 8 + security overview (20)
More from Rudy De Busscher
More from Rudy De Busscher (14)
Recently uploaded
Recently uploaded (20)
Java ee 8 + security overview
- 1. What can we expect in Java EE 8 and in particular for Java EE Security?
- 2. Who Am I Rudy De Busscher C4J: Senior Java Web Developer, Java Coach JSR375: Java EE Security API Expert group member Java EE believer @rdebusscher http://jsfcorner.blogspot.be http://javaeesquad.blogspot.be
- 3. Agenda ▪ Java EE ▪ How We Got Here ▪ Where We Are Going ▪ Servlet 4 ▪ JSON-B ▪ Server sent Events ▪ MVC ▪ CDI ▪ Java EE Security API ▪ Why ▪ Terminology ▪ API for Authentication Mechanism ▪ API for Identity Store ▪ API for Role/Permission Assignment ▪ API for Security Context ▪ API for Authorization Interceptors
- 4. J2EE 1.3 CMP, JCA J2EE 1.4 Web Services, Mgmt, Deplymnt Java EE 5 Ease of Use, EJB 3, JPA, JSF, JAXB, JAX-WS Java EE 6 Pruning, Ease of Use, JAX-RS, CDI, Bean- Validation Web Profile Servlet 3, EJB 3.1 Lite Java EE 7 JMS 2, Batch, TX, Concurr, Web- Sockets, JSON Web Profile JAX-RS 2 J2EE 1.2 Servlet, JSP, EJB, JMS, RMI Java EE Past, Present, & Future
- 5. J2EE 1.3 CMP, JCA J2EE 1.4 Web Services, Mgmt, Deplymnt Java EE 5 Ease of Use, EJB 3, JPA, JSF, JAXB, JAX-WS Java EE 6 Pruning, Ease of Use, JAX-RS, CDI, Bean- Validation Web Profile Servlet 3, EJB 3.1 Lite Java EE 7 JMS 2, Batch, TX, Concurr, Web- Sockets, JSON Web Profile JAX-RS 2 J2EE 1.2 Servlet, JSP, EJB, JMS, RMI Java EE Past, Present, & Future
- 6. J2EE 1.3 CMP, JCA J2EE 1.4 Web Services, Mgmt, Deplymnt Java EE 5 Ease of Use, EJB 3, JPA, JSF, JAXB, JAX-WS Java EE 6 Pruning, Ease of Use, JAX-RS, CDI, Bean- Validation Web Profile Servlet 3, EJB 3.1 Lite Java EE 7 JMS 2, Batch, TX, Concurr, Web- Sockets, JSON Web Profile JAX-RS 2 J2EE 1.2 Servlet, JSP, EJB, JMS, RMI Java EE Past, Present, & Future
- 7. J2EE 1.3 CMP, JCA J2EE 1.4 Web Services, Mgmt, Deplymnt Java EE 5 Ease of Use, EJB 3, JPA, JSF, JAXB, JAX-WS Java EE 6 Pruning, Ease of Use, JAX-RS, CDI, Bean- Validation Web Profile Servlet 3, EJB 3.1 Lite Java EE 7 JMS 2, Batch, TX, Concurr, Web- Sockets, JSON Web Profile JAX-RS 2 J2EE 1.2 Servlet, JSP, EJB, JMS, RMI Java EE Past, Present, & Future
- 8. J2EE 1.3 CMP, JCA J2EE 1.4 Web Services, Mgmt, Deplymnt Java EE 5 Ease of Use, EJB 3, JPA, JSF, JAXB, JAX-WS Java EE 6 Pruning, Ease of Use, JAX-RS, CDI, Bean- Validation Web Profile Servlet 3, EJB 3.1 Lite Java EE 7 JMS 2, Batch, TX, Concurr, Web- Sockets, JSON Web Profile JAX-RS 2 J2EE 1.2 Servlet, JSP, EJB, JMS, RMI Java EE Past, Present, & Future
- 9. Connector 1.7 Managed Beans 1.0 EJB 3.2 Servlet 3.1 Eco- system JSF 2.2 JAX-RS 2 JMS 2JPA 2.1 EL 3 JTA 1.2 JSP 2.3 Interceptors 1.2 CDI 1.1 Common Annotations 1.2 UpdatedMajor Release New Concurrency Utilities Batch Applications Java API for JSON Java API for WebSocket Bean Validati on 1.1 Java EE 7
- 10. https://java.net/downloads/javaee-spec/JavaEE8_Community_Survey_Results.pdf https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee Java EE 8 Community Survey
- 11. Java EE 8 Possibilities ▪ Web Standards/HTML5 Alignment • HTTP2, SSE, JSON-B, JSON-P, action-oriented web framework, hypermedia ▪ Cloud • Simple security providers, REST management/monitoring ▪ CDI Alignment • CDI 2, EJB services outside EJB, security interceptors, EJB pruning ▪ Enterprise • JCache, Configuration, JMS ▪ Java SE 8 alignment
- 12. ▪ Java EE 8 (JSR 366) ▪ CDI 2 (JSR 365) ▪ JSON-B (JSR 367) ▪ JMS 2.1 (JSR 368) ▪ Servlet 4 (JSR 369) ▪ JAX-RS 2.1 (JSR 370) Current JSR ▪ MVC (JSR 371) ▪ JSF 2.3 (JSR 372) ▪ Java EE Management (JSR 373) ▪ JSON-P 1.1 (JSR 374) ▪ Java EE Security (JSR 375)
- 13. ▪ Principal goal to support HTTP/2 • Request/response multiplexing over single connection • Multiple streams • Stream Prioritisation • Server Push • Binary Framing • Header Compression Servlet 4
- 14. Servlet 4 resoures • Edward Burns - Devnexus 2015 presentation - http://www.slideshare.net/edburns/http2-comes-to-java-what- servlet-40-means-to-you-devnexus-2015 • Mark Nottingham - Http/2 presentation - http://www.slideshare.net/mnot/what-http20-will-do-for-you
- 15. Java API for JSON Binding JSON-B ▪ API to marshal/unmarshal POJOs to/from JSON • Very similar to JAXB in the XML world ▪ Default mapping of classes to JSON • Annotations to customise the default mappings • @JsonProperty, @JsonTransient, @JsonValue ▪ Draw from best of breed ideas in existing JSON binding solutions • MOXy, Jackson, GSON, Genson, Xstream, … • Allow switching providers ▪ Provide JAX-RS a standard way to support “application/json” for POJOs • JAX-RS currently supports JSON-P
- 16. Server-Sent Events (SSE) ▪ Lesser known part of HTML 5 • Standard JavaScript API on the browser ▪ Server-to-client streaming • “Stock tickers”, monitoring applications ▪ Just plain long-lived HTTP • Between the extremes of vanilla request/response and WebSocket • Content-type ‘text/event-stream’ ▪ Support via JAX-RS.next() • Already supported in Jersey JAX-RS reference implementation
- 17. MVC ▪ Standard action-based web framework for Java EE • JSF to continue on it’s evolution path, but not restricted too. ▪ Model • CDI, Bean Validation, JPA ▪ View • (Standard) Facelets, JSP (Other) Freemarker, … ▪ Controller • Majority of work here • Based on JAX-RS
- 18. • Component-based MVC • like JSF, Wicket, … • Action-based MVC • like Struts 2, Spring MVC MVC types
- 19. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Component based MVC
- 20. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Action Based MVC
- 21. @Path("/") @View("my-index.xhtml") public class Bookstore { ... @GET public List<Item> getItems() { ... return items; } } MVC Possibilities
- 22. CDI 2 ▪ Java SE Bootstrap ▪ XML configuration ▪ Asynchronous events ▪ @Startup for CDI beans ▪ Portable Extension SPI simplification ▪ Small features and enhancements
- 23. Adopting Java SE 8 ▪ Most of Java SE 8 can already be used with Java EE • GlassFish, WildFly and WebLogic support JDK 8 ▪ Some APIs could adopt features • Repeatable Annotations • Date-Time API/JDBC 4.2 • Completable Future • Lambda expressions, streams • Default methods
- 24. • Expert Group nominations: EE API veterans: many JSRs, many years struggling with Security API 3rd party security framework creators/developers EE platform security implementers • March 2015: Expert Group started discussions Java EE Security API JSR-375
- 25. What’s wrong with Java EE Security? • Java EE Security viewed as not portable, abstract/confusing, antiquated • Doesn’t fit cloud app developer paradigm: requires app server configuration • "The ultimate goal is to have basic security working without the need of any kind of vendor specific configuration, deployment descriptors, or whatever. ” – Arjan Tijms
- 27. What to do? • Plug the portability holes • Modernize Context Dependency Injection (CDI) • Intercept at Access Enforcement Points: POJO methods Expression Language (EL) • Enable Access Enforcement Points with complex rules • App Developer Friendly • Common security configurations not requiring server changes • Annotation defaults not requiring XML
- 28. Ideas • Terminology • API for Authentication Mechanism • API for Identity Store • API for Password Aliasing • API for Role/Permission Assignment • API for Security Context • API for Authorization Interceptors To modernize, standardise, simplify
- 29. Ideas - Terminology • EG discussions revealed inconsistency in security API terms • Different EE containers have different names for the same concepts • When “something” gets authenticated, is that something a... A User? (e.g. HttpServletRequest.getUserPrincipal) A Caller? (e.g. EJBContext.getCallerPrincipal) • What is a group? A group of users? A permission Vs Role?
- 30. Ideas - Terminology • What is that “something” where identities are stored? security provider (WebLogic) realm (Tomcat, some hints in Servlet spec) (auth) repository (auth) store login module (JAAS) identity manager (Undertow) authenticator (Resin, OmniSecurity, Seam Security) authentication provider (Spring Security) identity provider
- 31. API for Authentication Mechanism • Application manages its own users and groups • Application needs to authenticate users in order to assign Roles • Application authenticates based on application-domain models • Application needs to use an authentication method not supported on the server, like OpenID Connect or OAuth2 • Developer wants to use portable EE Authentication standard
- 32. • Java Authentication Service Provider Interface for Containers • JSR 196, Maintenance Release 1.1, in 2013 • Standardised, portable, thin, low- level authentication framework • JAAS (LoginModule) is Java SE and thus not standard within Java EE JASPIC
- 33. Authentication Events • Throw standardised CDI events at important moments PreAuthenticate Event PostAuthenticate Event PreLogout Event PostLogout Event • Possible uses: Tracking number of logged-in users Tracking failed login attempts per account Side effects, like creating a new local user after initial successful authentication via a remote authentication provider Loading application-specific user preferences
- 34. • Where is the “user” info stored? API for Identity Store • Custom stores by annotated POJO’s
- 35. API for Role/Permission Assignment • After user/Caller is authenticated: • Need to retrieve the roles/permissions/grants • API to manage these assignments • Dynamic role/permission assignment
- 36. Why role to group? • Application; similar users are grouped in a Role • Identity store Used for more then 1 application Probably has already some kind of grouping of users (department, …) • Map application Role to Identity store Group • Today supported Support in Deployment Descriptors, e.g. web.xml
- 37. Role vs Permission • Role Grouping of users When “allowed actions” for a Role changes Application needs to be changed an redeployed • Permission • “Key” to unlock some functionality. Permission is linked in code. • User/Caller or even role has some permissions • Changes -> only external where permissions are linked to users.
- 38. API for Security Context • Application needs to access the security API To get the authenticated user To check roles To invoke runAs. • Application needs the same API to access security context, regardless of container
- 39. API for Authorisation Interceptors • Application needs to restrict specific methods to authorised users • Application-model rules are used to make access decisions • Annotation based • My requirements Screen parts (like on JSF Component) needs certain permission URL’s are protected based on permissions/roles/…
- 40. EL Authorization Rules • To be used in security annotations • Refer to any object, system or application defined • Security rules tailored to the application. • @EvaluateSecured("security.hasRoles('MANAGER') && schedule.nowIsOfficeHrs") void transferFunds() {..};
- 41. Complex rules • AccessDecisionVoter • Concept from DeltaSpike / Octopus • Complex logic written out in Java code (CDI bean) • @Secured(AccountAccessDecisionVoter.class) void transferFunds() {..}; • public void checkPermission (AccessDecisionVoterContext ctx, Set<SecurityViolation> violations) {
- 42. Get Involved • Project Page: The starting point to all resources https://java.net/projects/javaee-security-spec • Users List: Subscribe and contribute users@javaee- security-spec.java.net • Github Playground: Fork and Play! https://github.com/javaee-security-spec/javaee- security-proposals
- 43. • What’s Coming in Java EE 8? - Reza Rahman • http://www.slideshare.net/reza_rahman/javaee8 • Finally, EE Security API JSR 375 - Alex Kosowski • http://www.slideshare.net/a_kosowski/devoxx-fr-ee8jsr375securityapiv1 • MVC in JavaEE 8 - Manfred Riem • https://java.net/projects/ozark/downloads/download/Presentations/2014-javaone- mvc-in-javaee8.pptx Acknowledgements
- 44. Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Public The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Safe Harbor statement
- 45. Q&A
Editor's Notes
- For many folks that have not kept up-to-date with the evolution of Java EE, historical context is very important.
- The J2EE period (prior to Java EE 5) is marked with a successful effort to establish the server-side Java standards based ecosystem. Though widely criticized for complexity J2EE remains one of the most influential and groundbreaking technologies in the enterprise. The Java community stepped in to meet the programming model challenges in J2EE with projects like Spring and Hibernate.
- Java EE 5 absorbed many of the programming model changes from the community and included it’s own set of key innovations. The key changes in Java EE 5 were POJO programming, annotations over XML, intelligent defaults and zero-configuration systems. As a result of the changes in Java EE 5, Java EE remains one of the easiest to use platforms available today.
- The key change in Java EE 6 was to introduce first-class generic dependency injection as a built-in part of the platform through CDI. The industry reception of Java EE 6 has been great resulting in the growing adoption of Java EE. Java EE 6 also introduced the Web Profile and a pruning process to make the platform as lightweight as possible.
- Java EE 7 is an opportunity to build upon the success of Java EE 6 to make sure enterprise developers are ready for emerging challenges.
- Some new APIs were added in Java EE 7, some have gone through major changes and others are point releases. Almost every Java EE API has gone through a change. The point releases have important changes and taken together outweigh the new APIs and major updates. The Java API for JSON, the Java API for WebSocket, JAX-RS 2, JSF 2.2, Servlet 3.1, Bean Validation 1.1, etc all contribute towards the HTML 5 theme. JMS 2, CDI 1.1, JPA 2.1 and JTA 1.2 are examples of a laser focus on productivity while Java Batch and Java EE Concurrency Utilities are clearly geared towards meeting enterprise needs. It is always important to remember Java EE forms the stable core of a vibrant ecosystem. Things like Arquillian, DeltaSpike, Forge, PrimeFaces continually move the ecosystem forward by building on the standard.
- Java EE 7 has seen significantly increased community involvement as compared with previous releases like Java EE 6 and Java EE 5. We want to significantly improve upon that towards making Java EE 8 one of the most community driven technologies ever developed. Towards this goal we started off Java EE 8 with a series of public surveys asking developers for feedback into what should go into the next revision of the platform. The first two parts asked about specific features we thought were important. We also allowed for any open ended feedback anyone may have. The last part of the survey asked the community to prioritize features. The survey was run for about three months and we received about 4,500 inputs. The data represented all sorts of folks from around the globe and many kinds of organizations. The results of the survey are available for anyone to see. They have important insights into what the community thinks. The graphic depicts the final prioritization of features for Java EE 8.
- Based largely on the survey we have drawn some possible themes for Java EE 8 – further web standards alignment, cloud features, CDI alignment, enterprise features as well as Java SE 8 alignment. In the next part of the presentation we will take a high level look at these features. The web standards/HTML 5 alignment will consist of support for HTTP 2 via Servlet 4, JSON binding, updates to the lower level JSON processing API added in Java EE 7, a new action-oriented framework for Java EE and building upon the hypermedia support in JAX-RS 2 added in Java EE 7. A number of possible Java EE 8 features are geared towards making it easier for applications to be deployed to the cloud. These include simplifications to the way Java EE application security is handled as well as being able to administer Java EE containers using a standard RESTful API. We have been gradually aligning as many Java EE APIs as possible with CDI in Java EE 6 and Java EE 7. The eventual goal as desired by the community is to make CDI the central programming model in Java EE. One of the most important goals in Java EE 8 is to have a significant release of the CDI specification itself. Other possibilities include making more EJB services available to all Java EE managed components through CDI as well as pruning older EJB features such as CORBA interoperability. There are a smaller number of important features on the enterprise front. JCache 1.0, the Java Caching standard, was originally planned to be included in Java EE 7 but was delayed. JCache is now finalized and could be used on top of Java EE 7 applications. The goal in Java EE 8 is to include JCache 1.1 into the platform. JCache 1.1 could make it a lot easier to use the API in Java EE applications. One of the goals the community thought was important was to make it easier to configure Java EE applications so this is something we will take a closer look at. JMS 2.1 will explore how to make messaging even easier in Java EE applications by utilizing CDI. Finally we always try to make sure that Java EE is aligned with Java SE. Java SE 8 brings a number of useful features and we want to make sure Java EE developers can take maximum advantage of those features.
- Java EE 8 is already in full swing. Many key JSRs including the Java EE 8 platform JSR were launched in the JavaOne 2014 time frame. Those expert groups are now fully active. A second smaller batch of key JSRs including Java EE Security, Java EE Management and JSON-P 1.1 were launched more recently and are now solidifying their progress. Many other JSRs like minor releases of WebSocket, Java EE Concurrency Utilities and JPA are yet to come. There is still plenty of opportunities to participate and help shape Java EE 8.
- Servlet 4 is easily one of the most important changes in Java EE 8. The principal goal of Servlet 4 is to bring HTTP 2 support to Java EE developers. HTTP 2 is a very fundamental modernization of the protocol that keeps the internet together. HTTP was designed with a very simple web in mind – a request is expected to produce just one artifact, likely a plain HTML page with some hyperlinks. The web today is a far more complex beast. A single page contains many possible dependent resources – images, style-sheets, scripts, videos and so on. As a result we currently lose a lot of performance as each dependent resource is retrieved through a separate HTTP request. HTTP 2 is aimed to boost web performance manifolds by fixing this impedance mismatch. HTTP 2 accomplishes this by allowing the transfer of a number of resources from the server in a given request over a single initial TCP connection. Given a request from the client the server can send down as many related resources as needed by multiplexing the connection into streams. These streams can be assigned priorities such that the client browser can first retrieve what is absolutely needed for rendering such as the main page and some images while retrieving less important resources in the background. In addition HTTP 2 uses binary framing for significantly improved bandwidth usage as well as header sharing/compression across related resources. We hope that a majority of these changes can be completely transparent to developers and simply be handled by Servlet runtime. However some of these changes will inevitably result in changes to the Servlet API. A majority of these changes can definitely be handled very transparently by higher level APIs such as JSF and JAX-RS.
- Java EE 7 includes a low-level JSON parsing API akin to JAXP in the XML world. On of the most popular features the community has asked for in Java EE 8 is a higher level binding API similar to JAXB in the XML world. The API should be highly transparent and mostly just work with POJOs as is. There will likely be a small number of annotations to override default mappings such as renaming fields or marking fields transient. The API will draw from existing non-standard JSON binding solutions like MOXy, Jackson, GSON and Genson as well as allow switching providers at runtime. For the most part, developers do not even need to be aware of the actual API as it will be seamlessly integrated into higher level Java EE APIs such as JAX-RS. The idea is that the binding will simply take effect on POJOs when the runtime encounters the ‘application/json’ content-type. JSON-P is currently integrated with JAX-RS in a similar fashion. Note that JSON binding has long been supported in GlassFish and WebLogic through the non-standard MOXy project.
- Java EE has had strong support for REST as of Java EE 6. In Java EE 7, we added support for WebSocket. REST is intended for traditional HTTP based stateless request-response style communication. In this model the client initiates a single request, the server furnishes a response and the connection is closed. The vast majority of communication on the web is based on this model. WebSocket is almost the opposite of plain HTTP and REST. It is a stateful, fully bi-directional, asynchronous communication model. Once a connection is established, either the client or the server can send messages whenever they need to. The connection is kept open as long as necessary. WebSocket is ideal for situations like chat, real-time online collaboration, online multiplayer games and the like. SSE or Server-Sent Events are something between the extremes of plain HTTP and WebSocket. Using SSE once the client connects to the server, the server can send messages down over a period of time, in theory for as long as needed. SSE is good for use cases like stock tickers, monitoring applications, live maps and the like. Like WebSocket, SSE was introduced as part of HTML 5. It is really just a very long lived HTTP connection with a specialized content-type – ‘text/event-stream’. Just like WebSocket, there is a standard JavaScript API for it on the browser. SSE was one of the items that there was very strong support for in the Java EE 8 survey. SSE will be supported in Java EE 8 through JAX-RS 2.1. Note that the Jersey JAX-RS reference implementation included in both GlassFish and WebLogic has long had non-standard support for SSE.
- The oldest web framework in the Java space – Struts – was action based. Struts creator Craig McClanahan helped create JSF and supported the more abstract component based approach closer to the original Smalltalk MVC pattern. While JSF clearly continues to have a very strong following, action based frameworks continue to move forward even after Craig’s recommendation to move to JSF. More recently some developers feel that the action based approach is particularly well suited to the HTML 5 ecosystem, among other benefits long touted by proponents. We wanted to utilize the Java EE 8 survey as an opportunity to gage developer sentiment on the debate. What we found is that there is fairly strong developer interest in having a standard action-based web framework in Java EE. To meet these community desires Java EE 8 will include an action-based alternative alongside JSF. JSF will still continue it’s evolutionary path with JSF 2.3. The model portion of this framework will be centered around CDI, JPA and Bean Validation. The view portion will have built-in support for Facelets and JSP. The majority of the work in this new specification is in defining the controller portion. The expert group has decided to base this work on JAX-RS.
- The code illustrates the basics of how the controller portion may look like and should be fairly familiar to action based web framework developers as well as experienced Java EE/JAX-RS developers. While the @Path and @GET annotations would come from JAX-RS, @View annotation would be defined in the new specification. If omitted the view could default to something like bookstore.jsp. The idea is that the view would be populated from the model generated by the GET method handler – in this case a list of bookstore items.
- After Java EE 6 there has been two minor point releases of CDI – CDI 1.1 and CDI 1.2. The goal in Java EE 8 is to include a major CDI 2 revision. The goals for CDI 2 are quite ambitious. Thus far CDI has been a Java EE centric technology. Major CDI implementations also support Java SE runtimes, but such support is currently non-standard. The goal in CDI 2 is to support a feature subset in Java SE environments including a standard bootstrap API. Much like newer Java EE APIs such as JAX-RS and WebSocket, CDI so far does not provide any support for XML based configuration. However some in the community have long felt that there are important use cases in CDI that cannot be met without XML configuration support such as incorporating CDI into non-Java EE products like enterprise integration frameworks and ESBs. CDI 2 will explore adding XML configuration support alongside annotations. CDI has a very elegant and type-safe event mechanism. While CDI events are synchronous today CDI 2 will explore making them asynchronous. CDI will also likely be the primary vehicle for making EJB annotations like @Startup, @Asynchronous and @Schedule available to all managed beans. The portable extension SPI is an extremely important part of CDI. It is intended to create a plug-in ecosystem for CDI. CDI 2 will look for ways to simplify the SPI as much as possible.
- Java SE 8 brings about a very useful set of changes that has been extremely well received by the community. We have ensured that developers can take maximal advantage of Java SE 8 by certifying both GlassFish 4.1 and WebLogic 12.1.3 against it. Similarly WildFly 8 is also certified against Java SE 8. The vast majority of Java SE 8 features like the new Date-Time API, lambdas, streams and CompletableFuture should be readily usable with Java EE 7, Java EE 6 and Java EE 5 APIs. In Java EE 8 we will make sure all APIs align with Java SE 8 as much as possible. Some features that such alignment could utilize include repeatable annotations, the Date-Time API, JDBC 4.2, CompletableFuture, the fork/join common pool, lambdas, streams and default methods.
- Standard corporate legal disclaimer essentially stating that any forward looking features may change in the future ☺.