eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If there was a central theme to the 11th Annual JavaOne Conference, held last month in San Francisco, it was arguably the restoration of balance between capability and complexity in the Java enterprise platform.
Now called Java Enterprise Edition—rather than the former J2EE (Java 2 Platform, Enterprise Edition)—the newly updated Java enterprise model includes input from many companies other than Java creator and steward Sun Microsystems, with Oracle, of Redwood Shores, Calif., being one of the most prominent contributors. Java Enterprise Edition 5 became available during the conference.
Ted Farrell, Oracle vice president and chief architect for application development tools, spoke with eWeek Labs Peter Coffee about the challenge of elevating Java enterprise capabilities while lowering barriers to their use.
What were the key points that Oracle wanted to make at JavaOne this year?
On the first day of the show, May 16, we announced that wed be shipping our reference implementation of the Java persistence architecture API, JPA [Java Persistence API; more here.] This is now the Java standard for persisting Java objects to the database and retrieving them from the database.
The JPA is also the core API used by Enterprise JavaBeans 3.0 for its persistence. But the nice thing about it is that if you dont want to program using those EJB 3.0 containers, you can also call the JPA libraries directly and get a lightweight version of an object-relational solution for your program.
Before this, didnt Java object persistence involve low-level operations of serializing the object and then dealing with those bits?
Depending on where you were going to [store the object], there were a variety of ways. One was to serialize the object; a lot of people would hand-code JDBC [Java Database Connectivity] calls to the database and map the results back into Java objects.
Did that create developer idiosyncrasies in the details of how that was done?
Sure. Not only that, but inefficiencies as well. A framework like our TopLink Essentials—which is the reference implementation of the JPA—is something thats been built over 10 years. It really understands object-relational mapping and optimizes the calls for you, so each individual developer doesnt have to learn that.
Does this make it easier for developers to store objects for future use without writing their own code for low-level database interactions?
Exactly. They can focus on their Java objects and the code theyre writing. The JPA and EJB 3.0 specifications are big strides for usability for Java developers. The reference implementation is now out as a Version 1.0 that developers can jump on and start using immediately.
Enterprise JavaBeans, upon their introduction, might have been a contender for the biggest single leap in complexity that developers have ever been asked to make. Does EJB 3.0 improve the balance of power versus complexity?
The early versions—the whole container transaction management that EJB brought—were very powerful, but they were, and are, incredibly complex to manage and use. Thats why were so excited about EJB 3.0, whose approach is much lighter-weight than the earlier EJBs [and] much more in line with what weve been doing with TopLink. Weve been able to contribute code and ideas from that TopLink experience.
What do you believe will be the main improvements in ease of understanding and implementation for the developer?
The biggest thing is that EJB 3.0 really simplifies the number of [elements] that you have to deal with. Before, a single logical object—a single logical representation of a database table—might have resulted in three or more Java files and an XML file. EJB 3.0 lets you have a single class that represents that thing, so you dont have to go off and manage all those moving parts. Its really a one-to-one mapping: The engine takes care of getting the data into your Java object.
Does EJB 3.0 reflect the experience of watching developers use the earlier versions in their projects, instead of just letting the technology evolve along its original lines?
Exactly. When Java Specification Requests come out, and companies with different [ideas] start hyping them, you never know whats hype and whats not. When people really look at EJB 3.0 and what its doing, I think theyll find its a huge advancement. It really advances developer productivity in writing code in Java that persists objects to the database.
Does all of what weve discussed so far deal with only the first of Oracles JavaOne announcements?
Yes, the second was a contribution to open-source development efforts. As a little bit of background, earlier this year, Oracle submitted 100 of our JavaServer Faces components to the [Apache Software Foundations] Apache MyFaces project. We called them ADF Faces, [with] ADF being our application development framework.
Next Page: Working to simplify Web 2.0 and open AJAX.
Working to simplify Web
2.0 and open AJAX”>
Is that the framework used by components under Oracles JDeveloper 10g tool set?
Right, the ADF Faces are those components. If you look at the reference implementation of JavaServer Faces, it comes with a minimal set of components. Most customers really want much more data-aware, much [richer] components. Thats what we provided earlier this year. You have 100 components from complex tables and trees to streaming video and images. The response to that has been really positive.
Those were what we called standard HTML components—they used HTML and some JavaScript. What we announced at JavaOne was that we were going to contribute our AJAX [Asynchronous JavaScript and XML] JavaServer Faces components—which are new—to open source later this year. We have to get it approved by the project. The first set went through Apache MyFaces. Theres no reason why we wouldnt follow that trend.
The big difference is that a lot of vendors are saying “AJAX is great” [and that] its the basis of “Web 2.0.” All those solutions require you to train your developers in JavaScript and DHTML [Dynamic HTML], or some proprietary XML language, and theyll generate that for you. Thats a lot of overhead. Youre writing a lot of JavaScript code that you then have to manage. We didnt change the programming model.
In the same way you could have taken those original 100 JavaServer Faces components, you just program those using JSP and JavaServer Faces. The new components are no different. You program our AJAX components using JSP and JavaServer Faces, and the render kit of those components uses all the AJAX technology for you.
So does this stratify the complexity of AJAX so that the developer sees a familiar component model, while the user experience still has the benefits that people want AJAX to deliver?
Not only do you not have to learn JavaScript or DHTML, you dont have to learn SVG either, and you still get charting and graphs and things like that.
Are we getting closer to seeing real meaning in the expression, “standards-based browser,” rather than just “browser popular enough to be worth testing and accommodating”? Is Achilles catching up with the tortoise in that regard?
Early this year, we joined the OpenAJAX effort for that purpose. We like AJAX. Were all committing to AJAX. And its important for the community to make it work in all the browsers and on all the servers. I think thats important so that we do get convergence as time goes on.
Itll be interesting. We definitely stretch the capabilities of DHTML and SVG. Over the next few years, well see people being creative and see vendors making improvements. It wont stop. If we give developers what they want, theyll always want more.
I think peoples expectations for interaction will continue to rise, but you wont be retraining your developers. The same skill sets [that] developers have been using to build Web 1.0 applications will not only apply to Web 2.0 with AJAX but also to any other device you want to target.
So, will developers still need to tailor content presentation to different user environments but perhaps need fewer separate skill sets to do that?
Exactly. There are situations where you want a generic thing to try to display itself anywhere, and thats successful up to a certain point. But people have expectations about what theyre looking at and how theyll interact with it, and I do think youll need to target the device youre going for.
What do developers get from the tools approach that Oracle is taking that they wont get by relying on Eclipse plus its ecosystem of plug-ins?
Weve really tried to ensure consistency so that anything that plugs into JDeveloper, from an internal or from an external group, will follow the same behavior and use the same concepts such as services or components. Some of the stuff were doing relies on controlling the core of the integrated development environment. When people sit down and play with the tool, most people are incredibly impressed.