Thursday Sep 26, 2013

Session Report: 50 New Features of Java EE 7 in 50 minutes

 by Timothy Beneke

On Tuesday afternoon, noted Java EE authors Arun Gupta and Antonio Goncalves offered a whirlwind tour of new features in “Java EE 7: Fifty New Features of Java EE 7 in 50 Minutes”. Gupta is legendary at Oracle for his hard work and astute grasp of the Java EE platform. His blog offers a wealth of insight into Java EE and other Java matters. He is the author, most recently, of Java EE 7 Essentials published by O’Reilly. Goncalves is one of the most highly regarded writers on EE anywhere and the author of Beginning Java EE 7, published by Apress.

Java EE 7’s new features enhance HTML5 support, increase developer productivity, and further improve how enterprise demands can be met. Developers will write significantly less boilerplate code, have better support for the latest Web applications, and gain access to enhanced scalability and richer, simpler functionality. The session did a stellar job of spelling out the details to a packed house.

With four new components (WebSocket, JSON-P, batch, and concurrency), and three old ones significantly updated (JAX-RS, JMS, and EL), along with other significant changes to the platform, a lot of new functionality has been added.

They divided the new Java EE 7 features into 19 categories and explained an average of two to three features in each category.  Here were the categories:

CDI 1.1 (JSR 346)
Bean Validation 1.1 (JSR 349)
Interceptors 1.2 (JSR 318)
Concurrency utilities 1.0 (JSR 236)
JPA 2.1 (JSR 338)
JTA 1.2 (JSR 907)
EJB 3.2 (JSR 345)
JMS 2.0 (JSR 343)
Servlet 3.1 (JSR 340)
Web Socket 1.0 (JSR 356)
Expression Language 3.0 (JSR 341)
JSF 2.2 (JSR 344)
JAX-RS 2.0 (JSR 339)
JSON-P 1.0 (JSR 353)
Batch 1.0 (JSR 352)
JavaMail 1.5 (JSR 919)
JCA 1.7 (JSR 322)
Java Connector Architecture
Default Resources

Here are just a few of the high points:

CDI 1.1 (JSR 346) enables finer scanning control and the ability to veto the processing of a class or package. Bean Validation 1.1 (JSR 349) allows for method validation and the ability to pre/post conditions on method and constructors. Interceptors 1.2 (JSR 318) focused on the ability to associate an Interceptor associated with a constructor and the ability to prioritize interceptor bindings.

For Concurrency utilities 1.0 (JSR 236), the emphasis was on ManagedExecutor with a focus on:
* User threads in Java EE applications
* The ability to support simple and advance concurrency design patterns
* And to extend Concurrency Utilities API from Java SE (JSR 166y)

Further emphasis in concurrency was on ManagedThreadFactory and DynamicProxy.

Dynamic Proxy:
* Creates dynamic proxy objects, and adds contextual information available for applications running in Java EE environment
* It supports Classloading, JNDI, Security, …

Also covered as part of concurrency: ManagedExecutor
* User threads in Java EE applications
* Support simple and advance concurrency design patterns
* Extend Concurrency Utilities API from Java SE (JSR 166y)
– java.util.concurrent package

In addition: ManagedScheduledExecutor
* Managed version of ScheduledExecutorService
* Submit delayed or periodic tasks

For JPA 2.1 (JSR 338), standardized database schema generation and the ability to define additional indexes in schema generation were emphasized. JTA 1.2 (JSR 907) was praised for its capacity for transaction management on Managed Beans as a CDI interceptor binding; in addition, it offers CDI scope whose lifecycle is scoped to the currently active JTA transaction.

They discussed WebSocket and annotated server endpoint which enables full-duplex bi-directional communication over a single TCP connection.

JSON Builder creates an object model (or an array) in memory by adding elements. JsonParser is an event-based parser that can read JSON data from a stream.

All in all, it was an impressive display of Java SE 7 expertise.

Java EE 7 Essentials by Arun Gupta

Beginning Java EE 7 by Antonio Goncalves

Be sure to check out Parleys.com in early October to listen to the entire session. It's well worth it.

Wednesday Sep 25, 2013

Session Report: Demystifying Java EE

Adam Bien, who is not only a Java Champion and JavaOne Rock Star, but was named in 2010 as Oracle Magazine’s Java Developer of the Year, spoke to an enthusiastic crowd where he addressed some core issues about Java EE. He encouraged questions – “The more heretical or offensive the better.” It was obvious that Bien loves to think about and code in Java. He remarked, “The more I code the happier I am”. Spoken like a hard-core Java developer!

First, he asked, “What is Java EE? Innovation vs. Standardization”?  For Bien, Java EE is nothing but a release of co-existing APIs. Before Java EE, there was a mess with lots of application servers, with absolutely no chance of finding two application servers with similar APIs. Java EE resulted in a huge simplification. Now with Java EE 7 a wealth of are applications available. Java EE, insisted Bien, was never about innovation because building a standard precludes innovation. “Java EE will always lag behind,” he observed. “For instance, Hibernate will always have more features than JPA. Spring will always have more features than CDI. Java EE is the 80% that makes products work. It was never about innovation.”

He boiled down the whole point of Java EE: “What matters are small WARs – the smaller the WAR, the faster the build and deployment. The faster the build and deployment, the more productive you become,” he insisted. He explained that Java EE enables you to not put everything into the WAR and place as much as possible on the application server and less on the WAR. He explained that most of his WARs in Java EE 6 or Java EE 7 projects are very small

Bien asked, “Are EJBs bloated?” He explained that the question implies some voodoo stuff behind the scenes making EJBs bloated. He offered a means to answer this question.

He went on to answer a wealth of questions in a way that was thoughtful, incisive, witty and, at times, a bit provocative.

Here's some of the topics/issues (pulled directly from his slides) that Adam touched on in this fast-paced session:

*Do we need transactions?
*Is Dependency Injection Black Magic, VooDoo, or both?
*Is EJB pooling needed? Are EJBs bloated? What happens, if you violate the EJB programming restrictions?
*Why AOP didn't take off in Java EE?
*Stateless vs. Stateful programming model?
*HA without a Cluster?
*Are there any POJOs out there? What happens during deployment?
*Is Java EE faster than J2EE? Does JMS 2.0 scale and perform well? Is Java EE only suitable for the "big" enterprise?
*Is JSF the silver bullet? What is the deal with CORBA and RMI?
*How to unit test Java EE applications? Why we don't build a best of breed server from scratch?

This was a lively, entertaining and information-packed session. Just what you would expect from a pro developer as Adam Bien. I highly recommend viewing this session.

Adam Bien’s Blog
Check out Parleys.com where you can listen to the session in early October.

Friday Jun 07, 2013

New Messaging Features in JMS 2.0

Part Two of Nigel Deakin’s series on JMS 2.0 (Java Message Service), titled “What's New in JMS 2.0, Part Two—New Messaging Features,” is now up on otn/java. While Part One looked at new ease-of-use features introduced in JMS 2.0, Part Two explores five important new messaging features.

First, a new kind of topic subscription called a shared subscription now allows for multiple consumers on the same topic subscription.

Second, developers can now specify a delivery delay on a message so that the JMS provider will not deliver the message until after the specified delivery delay has elapsed

Third, with JMS 2.0, users can send a message asynchronously. As Deakin explains, “This feature is available for applications running in Java SE or the Java EE application client container. It is not available to applications that run in the Java EE Web or EJB container.” According to Deakin, “When a message is sent asynchronously, the send method sends the message to the server and then returns control to the application without waiting for a reply from the server. Instead of being blocked unproductively while the JMS client waits for a reply, the application can do something useful, such as sending a further message or performing some processing.”

Deakin explains that there are two main ways in which you might use an asynchronous send in an application:

* To allow the application to do something else (such as update the display or write to a database) during the interval when it would otherwise be waiting for a reply from the server

* To allow a large number of messages to be sent in succession without waiting for a reply from the server after each message

Fourth, JMS 2.0 allows applications that receive a message to determine how many times the message has been redelivered.

And finally, a Java EE application that needs to receive messages asynchronously does so using an MDB, or message-driven bean, which is configured by specifying a number of configuration properties. Check out the article here.

Wednesday May 22, 2013

What's New in JMS 2.0: Ease of Use

A new article by Oracle’s Nigel Deakin, up on otn/java, titled “What's New in JMS 2.0, Part One: Ease of Use,” demonstrates ways in which JMS 2.0 enables developers to send and receive messages while writing less code. Some features of JMS 2.0, part of Java EE 7, and can be deployed in Java EE Web or EJB applications, while others can only be used standalone in a Java SE environment.

Deakin writes:

“The single biggest change in JMS 2.0 is the introduction of a new API for sending and receiving messages that reduces the amount of code a developer must write. For applications that run in a Java EE application server, the new API also supports resource injection. This allows the application server to take care of the creation and management of JMS objects, simplifying the application even further…”

The new API, known as the “simplified” API, is simpler and easier to use than the existing JMS 1.1 API, now known as the “classic” API.

Deakin describes the new API as follows:

“The simplified API consists of three new interfaces: JMSContext, JMSProducer, and JMSConsumer:

* JMSContext replaces the separate Connection and  Session objects in the classic API with a single object.

* JMSProducer is a lightweight replacement for the MessageProducer object in the classic API. It allows message delivery options, headers, and properties to be configured using method chaining (sometimes known as a builder pattern).

* JMSConsumer replaces the MessageConsumer object in the classic API and is used in a similar way.”

Developers can now choose between the two APIs and have access to both the classic and new features. Stay tuned for Part Two, in which Deakin will explore new messaging features in JMS 2.0.

Check out Part One here.

Wednesday Feb 15, 2012

GlassFish Adds Agility to Java EE Deployment

A new article by Julien Ponge on the front page of otn/java, titled “Adding Some Agility to Java EE Application Deployment with GlassFish,” reports on four noteworthy features in GlassFish that increase agility to Java EE application deployment.

* Session data preservation across redeployments

* Servlet fragments

* Application-scoped resources

* Application versioning

The article relies on a running example called TaskEE, a simple task list application that functions as a deployable application in which tasks are stored in a volatile Web session. Ponge shows how to morph TaskEE into TaskEEPA in order to store tasks in a relational database rather than a Web session.

Directly from the article:
“Deploying and managing Java Platform, Enterprise Edition (Java EE) applications seems like a fairly established activity. Applications can be deployed, undeployed, and upgraded through a combination of deployment and undeployment. Applications use various types of resources, such as JDBC connection pools or Java Message Service (JMS) destinations. Such resources need to be created, configured, and administered using an application server means, such as configuration files, command-line tools, and graphical interfaces. While the tasks do not vary much from one Java EE application server to another, each one is free to provide a broader set of features that make the developer’s and the infrastructure team’s jobs more enjoyable.”

Read the complete article here.

Monday Jan 09, 2012

Interfaces on Demand with CDI and EJB 3.1

A new article by Java Champion Adam Bien, up on otn/java, “Interfaces on Demand with CDI and EJB 3.1” explains that since Java EE 6, interfaces are no longer required by the container in order to realize common use cases, thus enabling developers to use them more consciously and strategically for the realization of business logic. Bien shows how interfaces can now be used as vehicles for encapsulation or abstraction, as they were originally intended.

From the article:

“There is nothing wrong with the abstraction of every implementation with an interface if such an approach can be clearly justified, but interfaces become dubious when you have to introduce artificial naming conventions to avoid name clashes…
Interfaces should be introduced only as a contract for already existing classes, for the realization of Strategy or Bridge patterns, or when you need to design an API, such as Java Database Connectivity (JDBC), Java Message Service (JMS), and so on. In typical business applications, this occurs in only a fraction of all cases.”
Read the complete article here.


About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
5
6
7
12
13
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today