This is the second part in my little
Java EE 7 refresher series. After a first introduction with a brief overview, I decided to ask
Arjan Tijms to write about his favorite new backend features in Java EE 7. You will know Arjan if you're following the Java EE space. He is a long time Java EE developer, JSF and Security EG member and he created
OmniFaces together with
Bauke Scholtz (aka BalusC) and helps building
zeef.com.
1. App Provided Administrative Objects
Java EE has long had the concept of an “administrative object”. This is a kind of resource that is defined on the application server instead of by the application. For some classes of applications using these is a best practice, for others it’s not such a good practice.
Java EE 6 started a small revolution with the introduction of @DataSourceDefinition, which lets an application define its own data source. Java EE 7 expands on this with @MailSessionDefinition (JavaMail 1.5), @ConnectionFactoryDefinition & @AdministeredObjectDefinition (JCA 1.7) and @JMSConnectionFactoryDefinition & @JMSDestinationDefinition (JMS 2.0).
In practice, many applications already used the programmatic API of JavaMail to create mail sessions, and JCA usage is relatively rare. JMS is much more widely used though and lacked an (EE compatible) programmatic API to create destinations (queues and topics).
The importance of this seemingly small feature is that for the first time in the history of JMS it can be used in a fully standard way, without requiring vendor specific xml files in the application archive or vendor specific configuration in the application server.
Note that none of these application provided resource definitions strongly tie the rest of the application code to these. That application code still only sees a JNDI name, and doesn’t depend on whether the resource is put in JNDI by a standard annotation, standard XML file, proprietary XML file or with proprietary config on the application server.
Further reading:
Automated provisioning of JMS resources in Java EE 7
2. Default resources
Closely related to app provided administrative objects, Java EE also introduced the notion of several default resources.
In the case of a default resource, the Java EE platform provides a ready to use resource of a specific type. Java EE 7 introduced defaults for a data source, the platform’s default JMS connection factory, and the default thread pool.
What characterizes these defaults is that they can’t be further configured in any standardized way. You have to do with whatever is provided by your server.
In the case of a data source, this means you get “something” to which you can send SQL, but there are no further guarantees with respect to performance or even durability (the data base the data source accesses could be fully memory based, although it practice it’s almost always a file in a server specific directory).
For the JMS connection factory, you get a connection to the default JMS provider of the server. Since JMS, unlike a SQL database, is a mandated part of Java EE you usually have a very good idea of what you get here. E.g. if the server in question is a production ready server, the default JMS provider is practically always a production ready one either.
Finally several actual resources such as a ManagedExecutorService gives you access to what is essentially the system’s default thread pool. Such thread pool can be used in much the same way as you would use the @Asynchronous annotation from Java EE 6. You don’t exactly know how many threads are in the pool or whether the ManagedExecutorService is backed by the same pool as @Asynchronous, but for simple ad-hoc multi-threaded work the defaults are typically good enough.
A particular nice aspect of the default resources is that in several situations you don’t even have to say that you want the default. The default data source that a JPA persistence unit for instance uses if you don’t specify any is well, the default data source.
Further reading:
Default DataSource in Java EE 7: Lesser XML and More Defaults
Defaults in Java EE 7
3. App provided and portable authentication mechanisms
Next to the administrative objects mentioned above, another thing that traditionally had to be defined and configured on the application server side are authentication mechanisms and identity stores (both known by many alternative names).
The Servlet spec does define 4 standardised authentication mechanisms that an application can choose from via its web.xml deployment descriptor (FORM, BASIC, DIGEST, CLIENT-CERT), but did not standardise the actual classes or interfaces for these and subsequently didn’t standardise any API/SPI for custom authentication mechanisms. Furthermore, there’s nothing in the spec about the actual location where caller names/credentials/groups are stored.
Just like with @DataSourceDefinition, Java EE 6 started a small revolution by standardising an API/SPI for authentication mechanisms as well as a programmatic API to register these from within the application: JASPIC 1.0.
Unfortunately, the Java EE 6 version of JASPIC had a few critical omissions that made it hard to actually use those portable authentication mechanisms. The most important of those were addressed in Java EE 7.
Just as with the app provided administrative objects, an app provided authentication mechanism does not tie the rest of the application code to these and they can be transparently swapped out for container provided ones.
Further reading:
What's new in Java EE 7's authentication support?
4. CDI based @Transactional
Before Java EE 7, high level declarative transactions were the domain of EJB. In this model, EJB was intended as a universal facade for a lot of functionality that the platform offers. While EJB evolved from an arcane heavyweight spec in J2EE 1.4 to something that’s actually quite lightweight in Java EE 6, the model of one spec functioning as a facade was not seen as ideal anymore.
While Java EE 6 brought the biggest change with if of actually introducing CDI, Java EE 7 started another small revolution where other specs starting to depend on CDI instead. With this the model of one bean type being a facade started to change to the competing model of one bean type functioning as a base and other specs providing extensions on top of that.
Specifically setting this in motion was JTA 1.2 with the introduction of @Transactional and @TransactionScoped. These are based on an interceptor from the Interceptors spec and a scope from the CDI spec. Both are mainly applicable to CDI beans. The way that this turns the model around is that with EJB, JTA was invisibly used under the hood, while with CDI, JTA (somewhat less invisibly) uses CDI under the hood.
Further reading:
JTA 1.2 - It's not your Grandfather's Transactions anymore!
JTA 1.2 on Arjan's ZEEF page
5. Method validation
Perhaps one of the most versatile and cross layer spec in Java EE is the bean validation spec. Bean validation makes it possible to put validation constraints on various beans, such as CDI beans and JPA entities.
But, those validation constraints only worked at the field level and by extension of that on the class level (which effectively validates multiple fields).
In Java EE 7 the applicability of bean validation took a huge leap by the ability of placing such constraints on methods as well, aptly called method validation. More precisely, constraints can now be put on the input parameters of a method as well as on its return value, and the input constraints can be on individual parameters as well as on multiple parameters.
Whereas field level constraints are validated at a specific moment, e.g. when the JPA entity manager persists an entity or after a postback in JSF, method validation takes place every time a method is called by arbitrary code.In Java EE this works when the method is in a (proxied) CDI managed bean, and the method is indeed accessed via the proxy.
Further reading:
Bean Validation 1.1 Feature Spotlight - Method validation
Bean Validation 1.1 on Arjan's ZEEF page
6. Expression language can be used everywhere
Expression language is a mini script language that’s used within Java EE. It has a long history, from being specifically to JSTL, to being natively incorporated in JSP, natively incorporated in JSF and later on unified between JSP and JSF.
In Java EE 7 this expression language took its biggest leap ever and became a totally independent spec that’s fully usually outside JSP and JSF, and even outside Java EE.
This means that expression language can be used in things like annotations, email templates, configuration files and much more. Just as with the introduction of CDI in Java EE 6, the introduction of a separately usable expression language has the potential to be used by many other specs in the future.
Further reading:
Standard Deviation: An Illustration of Expression Language 3.0 in Servlet Environment
EL 3.0 on Arjan's ZEEF page
7. Greatly simplified JMS API
One of the older specs in Java EE is JMS, which is about (asynchronous) messaging. JMS is also one of the specs that hadn’t been updated for a very long time (not since 2002!), and although still surprisingly usable its age did begin to show a little.
With JMS 2.0 Java EE 7 brought one of the biggest changes to JMS ever; a thoroughly and greatly simplified API. Part of these simplifications piggy back on the default resources mentioned above, but it also takes advantage of Java SE 7’s auto closeable feature and many smart defaults to minimize the amount of objects a user has to manage and juggle with for simple things like sending a message.
Further reading:
What's New in JMS 2.0, Part One: Ease of Use
JMS 2.0 on Arjan's ZEEF page
8. Entity graphs in JPA
Arguably one of the most important specs next to CDI in Java EE is JPA. Whether a Java EE application is a JSF based MVC one, or a JAX-RS based web-service, they pretty much always have some persistence requirements.
One of the difficulties in persistence is determining what is just the right amount of data to be fetched. This should obviously not be too little, but also not be too much since that typically comes with great performance implications.
An important tuning parameter of JPA has always been the eager and lazy loading of specifically relations. This choice is primarily structurally and hard coded on the entities itself. The problem with this is that in different situations the same entity may be required with more or less data. E.g. in an overview of all users you may only want to display the user name, while in a detail view also the address and other contact details.
Before Java EE 7 this could be done without fetching too little or too much data for each case by means of writing separate queries. While this solves the problem it’s not optimal, especially not when it concerns large queries and the only difference is how much associated data is fetched for some entity.
With JPA 2.1, Java EE 7 introduced the concept of entity graphs for this. Via a (named) graph, it’s now possible to determine exactly what data needs to be fetched in a graph style notion. These graphs are defined separately and can be associated at runtime with many different queries.
Further reading
JPA 2.1 Entity Graph – Part 1: Named entity graphs
JPA 2.1 on Arjan's ZEEF page
9. Access to managed thread pools
Briefly mention above when the default resources were discussed is that in Java EE 7 access is provided to the default thread pool.
The support actually goes a bit further than just that and Java EE 7 introduced an entire specification behind this; the concurrency utils for Java EE spec. With this spec you can not just get that default thread pool, but also obtain and work with separate thread pools. This is important for QoS use cases, and specifically to prevent a number of dead locking cases if work that depends on each other is scheduled to the same pool.
Unfortunately the practical usability of these additional pools is somewhat limited by that fact that it’s not possible to actually define those pools in a standard way. This somewhat contradicts the “App provided administrative objects” item in the beginning of this overview.
Despite that issue, for somewhat lower level asynchronous and parallel programming this spec opens up a world of options.
10. Etc; CDI tuning, Interceptors spec, Batching
In Java EE 7 the Interceptors spec was split off from CDI paving the road for CDI to focus more on being the core bean model of Java EE, while simultaneously making interceptors more generally reusable throughout the platform.
CDI itself didn’t get a major overhaul or a really major new feature, but instead got an assortment of smaller but very welcome features such as a (much) easier way to programmatically obtain bean instances, and events that fire when scopes are activated and de-activated.
Automatic enablement of CDI (CDI activated without needing a beans.xml) should have been a major feature, but appeared to be of rather limited use in practice. Without a beans.xml file only beans with so-called “bean defining annotations” are scanned, and especially for beginning users this is not always clear.
Java EE traditionally deals mostly with requests and responses that are generally rather short running. There’s a timer service available for background jobs, but that’s a relatively basic facility. There’s hardly any notion of job management, check-pointing or restarting.
In Java EE a brand new spec was introduced that specifically addresses these concerns; the Batch Applications for Java Platform 1.0 spec. This resolves around XML files in which jobs are specified, which themselves contains so-called steps that perform the actual sequential application logic.
Further reading
CDI 1.1
Interceptors 1.2
Batch 1.0
Thank you Arjan for taking the time to compile all of this. The next post is going to cover the top 10 features of the fronted technologies and will also feature a prominent guest blogger. Until then, there is plenty of time to play around with Java EE 7. Here are some resources to get you started with JBoss EAP 7 and WildFly:
