Oracle is officially launching Java EE 7 with a webcast later today. Ahead of the release InfoQ sat down with Anil Gaur, vice president of software development at Oracle, to find out more about this release and future plans
InfoQ: Given that this was the first version of Java EE since Oracle took over the reins, was the process any different from that for EE 6?
We have been developing the Java EE reference implementation as an open source project since Java EE 5, under Project GlassFish. Under Oracle's stewardship, the JCP process has also become more transparent. Oracle and the JCP members have a strong desire to engage with the wider Java developer community earlier in the process, so they can review and provide feedback as the specifications are developed. We filed JSR 348 to define the rules by which a JSR needs to be run in a transparent manner. All the Oracle-led JSRs are now following that process. The Expert Groups have open e-mail aliases for technical discussions and the interim specification drafts are visible on the project pages.
All Java EE 7 specs were developed as defined by JSR 348 with involvement of the broader community, in addition to the JCP Expert Groups and Java EE vendors. I'm pleased to say that this transparency has worked really well and we've seen a significant increase in community participation for this release.
InfoQ: With cloud support having been dropped, is there an overarching theme for Java EE 7?
There are actually 3 top-level themes we are driving for Java EE 7:
1) Deliver HTML5 Dynamic Scalable Applications.
Developers have been rapidly adopting HTML5 to create a richer user experience in the browser. To facilitate this, we introduced WebSocket support as a means to create a low-latency bi-directional communication channel between the Java EE and the browser where the user owns the communication protocol. For RESTful services over HTTP, on the other hand, we introduced an asynchronous API to improve scalability by executing RESTful business logic in the background and not holding onto a thread. RESTful services often exchange information using JSON. Java EE 7 introduces the JSON Processing API to parse JSON-formatted data using a StAX-like approach and a DOM object-model like approach. Last, JSF has introduced JSF-friendly markup, meaning that JSF pages can now be rendered directly in a web browser, without the need for executing a JSF application just to see what a rendered page looks like.
2) Increase Developer Productivity
Java EE 7 offers significant productivity improvements for developers. For example, we've reduced the amount of boilerplate code needed before developers can get to the core business logic. For example, JMS 2.0 leverages annotations, dependency injection, AutoCloseable, a simplified API, and default resource definitions to reduce the amount of effort needed to simply place a message on a queue, to just a few lines of code. Default resource definitions like JMS connection factories and data sources have a default definition, so deploying an application to a Java EE runtime requires less configuration. One much-requested feature we've added is a standard RESTful client API so that developers can productively make RESTful calls without using a proprietary client API. We've also done a lot of work to improve the integration of JSRs, to make Java EE 7 an even more integrated platform. Bean Validation, for example, can now be used in method declarations to validate parameter and return values, and container-managed transactions are now available to more than just EJBs. Transactional interceptors and the new @Transactional annotation enable transactions to be applied to any managed bean method, making it transactional. Last, CDI is enabled by default, so a beans.xml is no longer required to simply use a CDI bean.
3) Meet the most demanding enterprise requirements
Two new JSRs are directed at addressing some pretty important enterprise requirements. The first is the Batch API, which was led by IBM. The Batch API is best suited for non-interactive, bulk-oriented and long running or computationally-intensive tasks. We expect this API to be pretty popular among enterprise customers. In addition to the Batch API, we've also added the Concurrency Utilities API to execute more tasks in parallel. Java EE is a managed environment, so applications are not allowed to create their own threads. The Concurrency Utility API enables developers to create thread pools that execute tasks concurrently.
InfoQ: JCache missed the deadline for EE 7. Does that mean we have to wait until EE 8 to use it, or can it potentially be dropped in and used on an EE 7 standard server?
We're working towards finalizing the JCache APIs well before Java EE 8 and we expect there will be incremental progress in the platform to enable developers to use the new APIs on top of Java EE 7.
InfoQ: The combination of Java EE 6's managed beans and the annotation-based programming model introduced in version 5 of the EE Platform looked like it could ultimately allow developers to pick and choose from any of the services offered by the EE container on any component. Has EE 7 continued to build on that idea?
Yes, we continue to move in that direction. The best example is the overall alignment of managed beans in Java EE. Transactional Interceptors, which I mentioned earlier, is an example where you can apply transactions in a much more flexible manner. Bean Validation is more pervasive - use them if you need them. The JSF specification strongly recommends using CDI beans for example, instead of using JSF managed beans. And, of course, CDI beans are enabled by default, so again, just use them if you need them.
InfoQ: Another key feature of Java EE 6 was portable extensions. Have they been further exploited in EE 7?
Portable extensions are used everywhere both inside Java EE and in user applications. In Java EE 7, JMS, Bean Validation, and JTA all have portable extensions. There's also an Apache project called DeltaSpike that is devoted solely to portable extensions. HK2 (in GlassFish) uses a portable extension which allows client code to use CDI to inject HK2 services.
There has inevitably been some controversy around Java EE 7. As well as JCache and cloud features being delayed, the London Java Community criticised the Java Message Service 2.0 spec for being unambitious, stating on the final release ballot
The LJC supports the technical work done in the context of this JSR, but feels that given the innovations that have occurred in the messaging space since the release of JMS 1.1 that this JSR could have been more ambitious and broader in scope. The LJC views the messaging space as one in which further standardisation is possible and desirable, and urges interested JCP members to explore possibilities in this space.
InfoQ contacted Ben Evans and Martijn Verburg to find out more. Evans told us
I had in mind things such as:
- peer-peer messaging topologies
- wire compatible messaging formats
- AMQP
- advances in ultra-low latency messaging
In addition, I felt that the EG was overly timid in its approach to updating the API - e.g. the lack of generification.
Verburg added
Something that's hugely emphasised in the industry today is the idea of communications protocols not locking you into one particular language or platform. This is especially important in the increasingly fragmented ecosystem of the programming world. In many cases a queue or message bus is designed to be an architectural separation of concerns, and by locking them into a Java specific approach you're giving people a very valid technical reason to avoid the technology entirely.
So items like AMQP interop is certainly one aspect we'd like to see improved on.
Also, there are a variety of other architectures for more lightweight messaging within the JVM space and it would be helpful to see a trimmed down version of JMS that doesn't come with all the existing trappings.
That said we think there are significant developer productivity improvements with JMS 2.0, and would urge JMS developers to migrate as quickly as possible.
We put this to Gaur who told us
JMS 2.0 has gone through a major facelift in Java EE7. We believe that there is always room for improvement and we'll continue to work towards evolving the JMS Spec. The issues that got deferred will be evaluated by the Expert Group for the next release. In addition, when the roadmap for Java EE 8 becomes a little more established, we'll be inviting members of the community to contribute their own proposals for the next version of JMS. I hope the London Java Community will be able to participate in this from early on.
Finally we asked Gaur about what he thought we were likely to see in Java EE 8, specifically suggesting NoSQL and an action-orientated web framework as ideas.
While cloud features were mostly deferred from Java EE 7 to later releases, there are some cloud features that did appear. For example, an application can now define the security permissions it requires in a permissions.xml file that is bundled with the application. If the Java EE runtime can't honor those permissions, the deployment will fail. This is a much better option than simply failing at runtime! Default resource definitions, which I covered earlier, also come in handy in a cloud environment, where the deployed application can simply rely on the default resource definitions defined by the PaaS provider, such as mapping to resources like a database that the provider makes available. JPA 2.1 added schema generation support, so deploying an application to a green field cloud environment can also generate the database schema and pre-populate a database. We'll continue looking into how to make applications that are deployed to Java EE in cloud environments more portable as we move forward to Java EE 8 and beyond.
For NoSQL, we want to avoid prematurely standardizing an area that is still undergoing a lot of innovation and change, so this is TBD. We will continue working on some JSRs that are already in progress, like JCache, State Management and JSON Binding. We are considering a Configuration Service that improves the DevOps experience over what Java EE already offers. At a high level, this is about separating configuration artifacts from development artifacts so, for example, a different configuration can be applied to development, test and production environments without impacting development artifacts. Cloud is definitely on our minds since we want Write Once Run Anywhere to apply equally to the cloud as it does already in the data center. I think the other area we do want to investigate, as you allude to, is improving the experience for web developers. We made significant progress in Java EE 7 and we know that there is more that can be done to improve the experience of developing end-to-end mobile/desktop applications that leverage services developed with Java EE.
You can find out more about Java EE in a webcast later today.