1. BluePrints Reimagined
Java EE 7 in Action
BluePrints Reimagined
The workshop is designed to introduce the changes in Java EE 7.
The majority of significant Java EE 7 APIs and features are overviewed.
Some key Java EE 7 APIs and features are shown using real running code in the context of a non-trivial cohesive application.
The application is similar in concept to the J2EE BluePrints sample Pet Store application from years ago.
Reza Rahman
Java EE Evangelist
@reza_rahman
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Public

2. The standard Oracle legal disclaimer.
Java EE 7 is finalized and not subject to change.
Java EE 8 future directions shared are subject to change.
Public

3. Program Agenda 1
Java EE 7 Overview Cargo Tracker The API Changes + The Code! 2
The general outline of the workshop is as follows.
The workshop will start with a brief high level overview of Java EE 7.
After the Java EE 7 overview we will introduce the sample application used in the workshop – Cargo Tracker. If desired you will be able to setup the application on your own laptop during the workshop. This is completely optional and it is possible to successfully participate in the workshop without doing so. It is expected that most attendees will not setup the application on their own machine but simply watch the code and demos during the workshop. It is recommended that attendees setup the application on their laptop and explore the code after the workshop at their own pace.
After introducing the sample application we will begin the deep dive into Java EE 7. We will overview each major API/feature change in Java EE 7. Due to the amount of changes in Java EE 7, it is impossible to demo every feature in a reasonable amount of time. Instead, we will pick some key changes in each API to explore in depth using the sample application. Throughout the deck, the items in light gray will be discussed, but not demoed. 3
Public

4. Java EE 7 Themes DEVELOPER MEETING ENTERPRISE DEMANDS PRODUCTIVITY 4
The primary themes of Java EE 7 are HTML 5, productivity and enterprise features.
Productivity is always going to be a focus for Java EE as we want to make sure developers are as efficient with the platform as possible. Enterprise features are also an obvious mainstay for the platform.
We are very fortunate to finally see some sustained momentum behind the web standards – HTML 5, WebSocket, CSS 3, etc. We want to make sure that Java EE developers are well prepared to take advantage of these changes.
Java EE 7 is easily the largest set of changes to the platform in it’s history in terms of the amount of changes.
Public 4

5. Concurrency Utilities Batch Applications (JSR 352)
Java EE 7
Portable
Extension
Ecosystem
JSP 2.2
JSF 2.2
JAX-RS 2.0
EL 3.0
Bean Validation 1.1
Concurrency Utilities
(JSR 236)
Servlet 3.1
Batch Applications (JSR 352)
Common Annotations 1.1
Interceptors 1.1
CDI 1.1
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 API for JSON (JSR 353)
Managed Beans 1.0
EJB 3.2
Java API for WebSocket
(JSR 356)
Connector 1.7
JPA 2.1
JTA 1.2
JMS 2.0
New
Major Release
Updated
Public 5

6. Java EE in Action http://cargotracker.java.net 6
We will take a look at Java EE 7 through an extensive realistic sample web application.
The application uses many key Java EE 7 features and APIs, but not all. Similar to the J2EE BluePrints Pet Store sample application of past the core goal of the application is to show architectural best practices for developing Java EE applications. The application uses Domain-Driven Design (DDD) as a key architectural paradigm. For the purposes of the workshop we will focus on the Java EE 7 features, not the architectural aspects of the application.
The application has it’s own dedicated public site. A key goal is that after the workshop you should explore Java EE 7 on your own using the application. The public site includes instructions on how to set up the application as well as an alias if you need help.
Public 6

7. JMS 2 API modernization New features Platform alignment
Dependency injection
Fluent APIs
Intelligent defaults
Unchecked exceptions
New features
Delivery delay, async send
Platform alignment
MDB activation properties, JMS resource definition, default JMS resources
JMS was one of the last of the J2EE APIs to go through Java EE style modernization. It is a great example of the continuing productivity focus in Java EE 7.
The old JMS API had a lot of boilerplate that JMS 2 removes by applying modern programming practices.
In addition JMS 2 adds a small amount of new features.
JMS 2 was a great opportunity to maximize alignment with the overall Java EE platform as well as key APIs like CDI and EJB. There are now more standard MDB activation properties improving portability, default JMS resources such as connection factories available out-of-the-box as well as the capability to define JMS resources like queues or topics with the application improving portability and usability.
Public 7

8. Java API for WebSocket High level API for HTML 5 WebSockets
Full-duplex TCP-like communication on the Web utilizing HTTP
Both client and server-side (Java SE and Java EE)
Both declarative and programmatic
Pluggable and extensible
WebSocket is a key part of the HTML 5 family of standards. It allows for TCP like stateful, full-duplex, bi-directional, asynchronous communication over the web. Unlike stateless vanilla HTTP, WebSocket is useful for cases such as online multiplayer game-like applications, online chat-like applications or stock ticker-like applications.
The Java API for WebSocket is a high level API similar to JAX-WS and JAX-RS. There is both a server-side and a client-side API for easily developing with WebSockets. Most of the time you will likely be writing Java server-side endpoints while the client side is written in JavaScript.
There is both a declarative annotation centric API as well as an interface centric programmatic API. You will most often likely use the annotation-centric API. The programmatic API is useful for dynamically changing WebSocket endpoints at deployment time, perhaps very helpful for framework writers.
Public 8

9. Java API for JSON Processing
Low level API to parse, generate, transform, query JSON
JSON equivalent of JAXP
Object Model and Streaming API
Similar to DOM and StAX
Binding JSON to Java objects forthcoming
JSON equivalent of JAXB
JSON is quickly becoming the de-facto data serialization protocol on the web, especially with HTML 5.
The goal of the Java API for JSON Processing (JSON-P) in Java EE is to standardize JSON for Java, reduce dependence on party frameworks and reduce application complexity.
Similar to the Java API for XML Processing (JAXP), JSON-P is a lower level API to handle JSON. It is not a higher level declarative binding API like the Java API for XML Binding (JAXB). Such an API is forthcoming in Java EE 8 and will be named the Java API for JSON Binding (JSON-B). JSON-P is an essential step towards JSON-B and meets important use-cases on it’s own right when JSON binding is not the right solution.
JSON-P has two different API styles – an object model API similar to DOM and a streaming API similar to StAX. The APIs have tradeoffs similar to the tradeoffs between DOM and StAX. While the object model API is simpler and allows random access, the streaming API uses far less memory.
Public 9

10. Bean Validation 1.1 Method constraints CDI Alignment EL 3 integration
Very useful for JAX-RS and WebSocket
CDI Alignment
All Bean Validation artifacts now injection capable
EL 3 integration
More expressive validation messages
Though Bean Validation 1.1 is a point release, it includes some very useful changes.
You are now able to place constraints on method parameters and return types instead of just on properties. This is very useful for remote endpoints such as the ones for JAX-RS and WebSocket on the server-side as well as general contract-first development even for local EJB and CDI beans.
One of the gaps in Bean Validation 1.0 was that CDI injection was not enabled in artifacts like custom validators and you could not use CDI to inject these artifacts into other beans either. Bean Validation 1.1 has been fully aligned with CDI such that all artifacts are not injectable and injection capable.
Another very useful enhancement in Bean Validation 1.1 is that you can now use EL inside validation messages, significantly improving usability.
Bean Validation 1.1 is now integrated with CDI, JAX-RS and EJB in addition to JSF and JPA.
Public 10

11. JAX-RS 2 Client API Message Filters & Entity Interceptors
Servlet filters and CDI interceptors for JAX-RS
Asynchronous Processing – Server & Client
Hypermedia support
Transitional and structural links
Content negotiation
The primary goal of JAX-RS 2 is improving portability by standardizing common non-standard features in JAX-RS implementations like Jersey, RESTEasy and Axis.
One of the most significant changes is adding a client-side REST API. The Fluent API uses the builder pattern and is at the same time very simple but powerful.
The addition of message filters and entity interceptors significantly improve the extensibility of JAX-RS. While message filters are conceptually similar to Servlet filters, entity interceptors are similar to CDI interceptors. While it is possible for end users to use message filters and entity interceptors the more likely users are framework and plug-in writers.
Asynchronous processing can significantly improve scalability for the most demanding applications. JAX-RS 2 adds simple asynchronous processing capabilities both on the client and server sides.
Hypermedia is an important emerging concept in the REST ecosystem. It applies the concept of hyperlinks to RESTful web services. Transitional links help make client side APIs more flexible by providing URIs for actions that can be performed on a REST resource. Structural links are URI placeholders for additional data that can be embedded in the REST response body content. JAX-RS 2 adds support for transitional links while JAX-RS 2.1 may add support for structural links.
JAX-RS 2 also adds a simple mechanism for content negotiation. This is useful for expressing preferences for response content type when multiple types (e.g. XML and JSON) are supported by both the server and client.
Public

12. JPA 2.1 Schema generation Stored procedures
Unsynchronized persistence contexts
Entity Graphs
Entity converters
Although JPA 2.1 is a point release it brings an important set of changes.
Schema generation is a common non-standard JPA implementation feature than has now been standardized. It is now possible to generate a schema to the database or a script on application deployment. The schema can be generated from JPA metadata and/or scripts. It is also possible to load data via script during application startup.
Support for database stored procedures is a common non-standard feature in JPA implementations that has been frequently requested to be added to the standard. JPA 2.1 adds standardized support for database stored procedures.
Prior to JPA 2.1 persistence context changes are automatically flushed to the database on transaction commit. JPA 2.1 unsynchronized persistence contexts is a specialized mode that allows control over whether or not to flush changes to the database on transaction commit. With this kind of persistence context changes are flushed to the database on commit only when the user explicitly joins a transaction. This is useful in workflows where some data may be flushed on commit, but not all. If there is data that should not be flushed, they could be placed in an unsynchronized persistence context instead of a normal persistence context.
Entity graphs are an important query optimization technique. They allow specifying the exact entity data set to be loaded for a given named use case/query. This allows for significantly more flexibility as compared to specifying lazy and eager loading settings at the entity level that is hard to vary for a use case. Entity graphs are also more granular than FETCH JOINs.
Entity converters allow for modularizing entity data conversation logic and applying them in a declarative, cross-cutting concern-like fashion where needed using annotations. This avoids repeating data conversion logic across the data layer either while retrieving entities from the database or storing entities into the database.
Public 12

13. JSF 2.2 HTML5 Support Managed beans deprecated/CDI alignment
Pass-through elements and attributes
Managed beans deprecated/CDI alignment
@ViewScoped for CDI
@FlowScoped
Stateless views
Resource library contracts
View actions
File upload component
Although JSF 2.2 is a point release it contains a number of features important to the community.
In general there are few issues using HTML 5 with JSF. HTML 5 features such as JavaScript, WebSocket, local storage, canvas and web workers can easily be used with JSF. The only identified issue thus far had been using newer HTML 5 markup with JSF components since JSF components do not recognize these markup elements out of the box. The solution in JSF 2.2 is to allow for freely mixing and matching HTML 5 markup with JSF via pass-through elements and attributes.
The older and redundant managed bean model is now being deprecated in favor of the CDI programming model. This is part of the overall platform alignment with CDI. As part of this alignment the very useful view scope previously limited to JSF managed beans is now available to CDI beans.
The flow scope is an extremely useful addition to JSF. It allows for beans that automatically live and die within a given boundary in the application (e.g. account management section, catalog section, search section). A flow can be as simple as all pages in a directory or as complex as you need to define it to be – spanning arbitrary views, entry points and exit points. You can think of it as garbage collection for web applications.
Stateless views are an important way to optimize the amount of memory a JSF application uses. If you have a page that simply uses the request scope and makes no use of state (such as the session, conversation or view) you can mark it as stateless. This means that JSF will not save a UI state for the view, saving memory.
Resource library contracts are a way to modularize JSF page resources such as templates, images, CSS and the like. This means that such resources can be properly isolated, reused and applied dynamically when needed to affect the look and feel of a JSF application at runtime.
View actions are a very useful feature that allows backing beans to take some actions before a page is rendered (such as loading data to be shown on the page). This significantly improves the ease-of-use and bookmarkability of JSF pages.
JSF 2.2 has now standardized a file upload component. While JSF implementations have long provided this feature, it could not be standardized until now since JSF is backward compatible with the last two versions of the Servlet specification. Since Servlet 3.0 standardizes multi-part forms, file upload can now be standardized in JSF.
Public 13

14. Batch Applications for the Java Platform
API for robust batch processing targeted to Java EE, Java SE
Common architecture
Operator, repository, job, step, reader-processor-writer pattern
Common features
Chunking, check-pointing, transactions, retries, exceptions, workflow, parallelism
The ever increasing pervasiveness of Java means that there is a desire to write batch applications previously written in legacy platforms like COBOL in Java. This new API enables the trend by standardizing batch for Java. While the API is included in Java EE, it can also be used standalone in Java SE. Using the API with Java EE means being able to leverage all other Java EE APIs and running within the infrastructure of application servers including thread pooling, security, management, monitoring, clustering and load-balancing.
The API was led by IBM and standardizes well understood common concepts in batch such as operators to control batch jobs, repositories to store historical batch run data, defining batch jobs themselves, defining the steps that compose a job as well as the reader-processor-writer pattern common to batch processing.
The API also standardizes common features required for batch processing such as chunking/check-pointing for reliably and efficiently processing large amounts of data, declarative transactions, retries and exception handling as well as flows, conditional processing and parallelism.
Public 14

15. Concurrency Utilities for Java EE
Provides simple, safe API for concurrency in Java EE
Builds on Java SE concurrency
ManageExecutorService
ManagedScheduledExecutorService
ManagedThreadFactory
Relatively low-level API
Important enabler for Java EE ecosystem
Java EE provides several high-level APIs for asynchronous processing including JMS, Message-Driven Beans, Servlet async, JAX-RS async and the like. Furthermore in Java EE environments you are discouraged from using Java SE threads and thread pools directly. The reason for this is that Java SE threads are not managed by the application server in any way – they do not go through the application server thread pool, they are not managed or monitored in any way, they have no access to the Java EE security, naming and class-loading context and so on.
In some cases, however, it is necessary to use lower level threads. Such cases include very custom workloads, fine grained control over threads, third-party framework writers that need to spawn threads on the application server and so on. To meet these cases Java EE 7 introduces the Java EE Concurrency Utilities.
Using the API you can use low-level asynchronous constructs in a Java EE environment. This is possible because the API includes managed Java EE versions of Java SE concurrency APIs such as the executor service and thread factory.
Public 15

16. Concurrency Utilities for Java EE
Managed Task Executor
public class TestServlet extends HTTPServlet { @Resource ManagedExecutorService executor; Future future = executor.submit(new MyTask()); class MyTask implements Runnable { public void run() { // Task logic } } }
The code example shows very basic usage of the Java EE Concurrency Utilities. It is a Servlet that spawns a thread to process a potentially long-running task asynchronously.
Instead of using a native thread, a Runnable is submitted to an injected managed executor service. Note a default executor service is always available but you can also use a custom configured one if needed.
The executor service executes the Runnable from the application server’s thread pool in a completely managed fashion.
Public 16

17. Yet More… JTA 1.2 EL 3.0 Servlet 3.1 CDI 1.1 EJB 3.2
EL 3.0
Standalone API, lambda expressions, collections, operators
Servlet 3.1
Non-blocking I/O, upgrade to WebSocket, security
CDI 1.1
EJB 3.2
Truncating CMP/BMP
Besides the preceding Java EE 7 includes many more new features and APIs.
JTA 1.2 adds annotation that makes it possible to use declarative transactions outside EJB in any CDI managed bean. This is part of platform wide CDI alignment. The API also adds the very valuable transaction scoped annotation used under the hood by JMS 2.
EL 3.0 is now it’s own API separated from JSP. It includes a standalone bootstrap API for Java SE, forward-looking support for lambda expressions and significantly better support for constructs like collections, static fields and operators.
Servlet 3.1 adds support for non-blocking I/O to bolster the async support added in Servlet 3.0, HTTP upgrade support to help enable WebSocket and some important security enhancements.
CDI 1.1 is now enabled by default in Java EE 7, making the beans.xml file completely optional. CDI 1.1 also includes many useful additions like around construct to apply interceptors to constructors as well as vetoed to stop a component from being scanned by CDI.
EJB 3.2 includes some minor changes such as truncating some old EJB 2 features.
Public 17

18. Resources Java EE Tutorials
Digging Deeper
Java EE Transparent Expert Groups
Java EE Reference Implementation
The Aquarium
There are many resources available for you to learn Java EE and Java EE 7.
One of the most valuable resources you should follow up on is the Cargo Tracker application used in the demo.
The Java EE tutorials have been updated for Java EE 7. They are a great first learning resource.
To dig deeper you can also utilize the First Cup application as well as the official Java EE 7 Hands-on Lab.
The best place to start getting involved with Java EE is the transparent expert group.
You are always welcome to download GlassFish to learn Java EE 7.
The Aquarium blog is an excellent resource to stay up-to-date with the Java EE ecosystem.
Public 18