JDeveloper 10.13 Early Access Edition… Mission impossible?
Posted by Lonneke Dikmans in the wee hours: January 10, 2006
A little while ago, we decided to take the new JDeveloper 10.1.3 Early Access edition for a spin. At Xebia we mostly use Eclipse with open source frameworks like Hibernate and Spring. We are very productive and successful, but something is missing from our toolset. Hand-coding the presentation layer and binding it to the services and domain classes is a tedious job, even with frameworks like Spring MVC and Tapestry. Oracle’s ADF Data binding framework provides a solution for this problem. It offers .NET-like capabilities, with all the advantages of Java and open standards. The second reason to try JDeveloper 10.1.3 EA is the emerging EJB 3.0 persistence standard. Both Oracle TopLink and Hibernate implement this standard. And last but not least, Oracle has made a contribution to the Spring framework by adding support for TopLink to the Spring DAO package.
Our assignment was to rebuild our timesheet application using JDeveloper 10.1.3 Early Access edition and Oracle ADF. My expectations were high, based on the skills of my colleagues and my experience with Oracle ADF in earlier versions of JDeveloper.
Getting started
After a brief introduction of Oracle ADF everybody started building the application. Right away we got lost: the workspace and project organization in JDeveloper 10.1.3 is very different from Eclipse. Unfortunately it has also changed compared to previous JDeveloper versions, so it took a while before we were on our way. Deleting files from both the project and the file system has always been very awkward and the embedded OC4J gave us a lot of headaches (out of memory exceptions and mySQL datasource trouble).
The domain classes and the services layer
Because we were rebuilding an existing application with a simple domain we generated the EJB entity beans from the database. This went smooth with both the Oracle RDBMS and MySQL. We did find a strange bug: when the access type is changed from property to field, JDeveloper still generates the annotations on the properties (“getXXX” methods). This results in an error when the entity beans are deployed to OC4J. We did not want to spend too much time on the business services, so we decided to generate an EJB Session Bean. Unfortunately, we happened to have an entity bean named “Resource”. The generated session bean did not compile because javax.ejb.Resource is imported when you have “@Resource” in your code. We had to either refactor this domain class or use a fully qualified name cast every time we used this class. We tried to refactor the bean but had no success: renaming a EJB 3.0 entity bean does not work in this version of the IDE.
We added some existing business methods of the original application to the session bean:
[java]
public void addProject(Project newProject) {
//do work
}
[/java]
Now it was time to start with the interesting part: exposing the services to the presentation layer.
Creating the Data Control
Apart from using a new tool that was an early access release, building our domain and service layer was not too difficult. We created a Data Control for our service bean. This created xml files for the entity beans as well. Our custom methods were present in the xml file as you can see in the xml code snippet:
[xml]
[/xml]
We did notice some strange behavior: JDeveloper generated two xml files (ReadOnlyCollection.xml and ReadOnlySingleValue.xml) in the source directory of the project that were not based any class in our source code. They seem to represent some data type, but there is no documentation about these files.
Building the Web Layer
Now that we exposed our business layer, we were ready to use it in the front end of the application. Most of us decided to use ADF Faces. It soon became clear that using ADF Faces with data bindings is very complex. JDeveloper generates faces-config.xml, backing beans, page definitions, a binding context, iterators etc. Most of us managed to create a page that displayed a read only table with data from a database table. Adding a form to insert a row using one of our custom services proved to be a bigger problem. There are a lot of widgets you can use and the difference between controls like ADF Input Form and ADF Parameter Form are not very intuitive. We also learned that in the Data Control Palette a domain class used as a parameter is not exposed the same way a domain class used as a return type is. We had to rewrite our service methods using the fields as parameters to be able to use the drag and drop functionality. At the end of the day, nobody had built a fully functional web application and most of us had become frustrated with JDeveloper and ADF.
Evaluation
I got some valuable feedback building this application with my colleagues:
- I underestimated the productivity loss people experience when they are forced to use another IDE. To complicate matters we used the early access edition and ran into a couple of bugs. These two factors were a big turn off for a lot of us.
- The current Data binding framework (JDeveloper 10.1.2) works great for ADF BC. For other frameworks like Oracle TopLink with EJB session beans or Spring it is not mature enough yet. Once domain classes can be exposed as parameters and all the Data Control implementations are finished, I expect it will be even better than the current version. Programmers are then no longer forced to use a proprietary framework like ADF BC to be productive.
- Not everybody likes JSF. We had a rather long discussion about ADF Faces and JSF. Some of us fear it will be a monster like the EJB specification (used to be). Others think it is a specification that will give Java developers .NET-like productivity but with the open standards and open source that Java offers.
- Because both the JSF and ADF Data bindings were new for most of us, the assignment became too complicated and we ended up being confused instead of productive.
Personally, I am still very enthusiastic about the latest developments in EJB 3.0 persistence,Oracle ADF Data bindings and even JDeveloper. I’ll try to convince my colleagues again as soon as Oracle finishes the enhancements of the Data binding framework. To keep things simple, I won’t use the ADF Faces right away, but save those until JDeveloper 10.1.3 has become the production version. As far as I am concerned the verdict isn’t out yet….
Filed under: Java
January 10th, 2006 at 1:47 am
You’ll be glad to know that things have improved for the better between the EA version and what will come out in production. Particularly in this area of how you bind to TopLink or EJB entities via a Session Facade we’ve been hitting on this combination a lot in the demos and so have gone through several iterations to try and improve the experience. This will all certainly benefit from a closer look when production hits the streets.
The most important thing you’ll find is the documentation in the new Developers guide which discusses the Session bean > ADF Binding > JSF stack in particular. This should help clear up a lot of mysteries.
The new demo we’ll be shipping with the product also comes in an incarnation that uses this stack so you’ll have something of substance to work off.
On the Project Structure issue - 10.1.3 now has “dynamic projects”. The project file no longer maps each and every file that makes up the project, instead it maps the root directory(ies) for say your source and only records exceptions to that. This means you can happily have multiple projects as “views” on the same directory structure. It’s also a good fit if you do you multiple IDEs or a mix of say Ant and JDev to manage your projects. You can make changes externally such as adding files and the IDE will know about them without you haveing to explicitly having to do an “Add” to get it visible to the project. The only difficultly of all this is appreciating the difference of deleting from the project (which effectively just excludes the file from your view) and erasing from disk (on the file menu or from) which physically blows the file away.