Java EE7 in action

Editor's Notes

• #2: 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.
• #3: 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.
• #4: 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. We will finish the workshop with a brief look into what may be coming in Java EE 7, how attendees can learn more and get involved.
• #5: For many folks that have not kept up-to-date with the evolution of Java EE, historical context is very important.
• #6: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #12: The industry is on the path to adopting Java EE 7. There are already three certified compatible implementations – GlassFish 4, WildFly 8 and TmaxSoft JEUS. WebLogic is well on the way to Java EE 7 certification and uses many of the OSS components from GlassFish 4. JBoss EAP is the upstream project for WildFly and will be Java EE 7 compatible soon. IBM is aggressively working on Java EE 7 certification through monthly beta releases of the strategic WebSphere Liberty Profile platform. TomEE, the Tomcat based open source Java EE application server is also working on Java EE 7. The rest of the available Java EE platforms will likely catch up gradually.
• #13: Both GlassFish 4.1 and WebLogic 12.1.3 were released in the JavaOne 2014 time-frame. GlassFish 4.1 fixes a large number of bugs, brings support for CDI 1.2 and WebSocket 1.1 as well as support for Java SE 8. GlassFish 4.1 is in affect a platform update on top of Java EE 7. NetBeans now bundles GlassFish 4.1. WebLogic 12.1.3 brings partial Oracle commercial support for some of the most key Java EE 7 APIs - WebSocket, JSON-P, JAX-RS 2 and JPA 2.1. It also has support for SSE (Server-Sent Events) and WebSocket fallback for older browsers. In addition WebLogic 12.1.3 brings improved Maven support as well as official Docker images. Like GlassFish 4.1, WebLogic 12.1.3 fully supports Java SE 8. The next major release of WebLogic will be fully Java EE 7 certified.
• #14: 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 email alias if you need help.
• #15: JMS was one 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.
• #16: 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.
• #17: 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.
• #18: 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.
• #19: 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.
• #20: 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.
• #21: 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.
• #22: 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.
• #23: Java EE provides several high-level APIs for asynchronous processing including JMS, Message-Driven Beans, EJB @Asynchronous, EJB @Scheduled, 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.
• #24: 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.
• #25: Besides the preceding Java EE 7 includes many more new features and APIs. JTA 1.2 adds an @Transactional 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.
• #26: 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.
• #27: 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. 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, making it easier to use shared resources such as databases and JMS destinations in a multi-tenant application 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.
• #28: The diagram shows the rough timelines for Java EE 8 and GlassFish 5 – the Java EE 8 reference implementation. We have already finished a number of JSR submissions and many expert groups are now in full swing. There are a small number of further JSRs to be launched. We have also released GlassFish 4.1 as well as WebLogic 12.1.3. In 2015 we plan to release a fully Java EE 7 compatible version of WebLogic and have a number of JSR early drafts as well as public review drafts. By 2016 we hope to finish proposed final drafts as well as final drafts. The end of 2016 should being a final release of both GlassFish 5 and Java EE 8.
• #29: 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.