(When) Should we embark on ADF JHeadstart?

Organizations currently using JHeadstart 9.0.4.x or 9.0.5.x (for JDeveloper 9i or JDeveloper 10g (9.0.5.x) may wonder whether and when they should pick up the soon to be released ADF JHeadstart release. Moving towards the latest technology has a certain appeal as well as a scare factor. I will try to list advantages of moving to ADF JHeadstart as well as points to consider.

Reasons for moving to ADF JHeadstart

• Richer generation capabilities – currently especially for UIX: Shuttle (Parent and Intersection), Tree and Tree-Form layout-style, Multi-level master-detail nesting (JSP too), automatic generation of Application Structure File (including base and detail groups and lov’s!) based on the ADF Business Components; quick search, advanced search and option to publish result in same page, all master-detail layout combinations. The generator’s functionality is expected to grow in the near future, not in the least because of the new, more open architecture of the generator.
• Chucked legacy– this new ADF JHeadstart release was built from the ground, based on years of JHeadstart experience but not the old code base; both generator and runtime library were completely overhauled; the runtime is largely replaced by ADF’s runtime libraries. The new JHeadstart runtime library contains fewer classes and probably no more than 5% of the code was reused from the current 9.0.5.x release of JHeadstart. The code has much improved because it was redesigned; many old constructions and solutions could be removed from the code; legacy built up in more than 4 years of development could be cleansed.
• Better in-line with Oracle product strategy – ADF is key to the strategy of Oracle JDeveloper as well as Oracle Applications. See for example the article Eating your own dogfood – use of Oracle Development tools within the Oracle Applications development group about use of technology and tools within the Oracle Apps development organization. Most of Oracle’s investment in JDeveloper will be around ADF (data binding and faces). To benefit from this strategic investment, JHeadstart needed to make this move to ADF. The result is integration in what Oracle positions as the long-term development platform and architecture
• Allows benefiting from latest JDeveloper functionality – JDeveloper 10.1.2 and ADF offer many interesting, cool features that enhance the productivity and working experience. Moving to ADF JHeadstart allows you to move to JDeveloper 10.1.2 and benefit from all the new features and developments.
• (Almost) No dependency on JHeadstart Runtime – ADF JHeadstart is mainy a Design Time productivity booster. In the past, people may have had misgivings about making their applications dependent on JHeadstart, even though they had all sources of run-time elements. With ADF JHeadstart, this dependency is made much smaller. Most of what used to be the JHeadstart Runtime library is now the Oracle ADF Runtime Library. Granted, there still is a dependency, but a dependency on a real Oracle product that is the cornerstone of the J2EE strategy of Oracle may be easier to accept. There is also a JHeadstart runtime library by the way, but much smaller than it used to be. And as before: all sources of runtime code are available.
• Step in the direction of ADF Faces/JSF (although not nearly there) – The most important trend in WebApplicatioin Development for this year is probably the pending breakthrough of Java Server Faces (JSF). Oracle has indicated years ago that it would embrace JSF and provide an advanced implementation through the successor of UIX. While ADF JHeadstart does not yet generate ADF Faces pages (as ADF Faces is not yet production in JDeveloper 10.1.2), we are getting very close to it and embarking on ADF JHeadstart and UIX brings you quite close to ADF Faces, especially since Oracle seems to promise us a tool to upgrade UIX to ADF Faces :
  

  We are working on a migration utility to move UIX pages to ADF Faces/JSP pages. This is in the works, although I cannot give you a date when this will be available. The current plan is to continue to support ADF UIX and provide the same level of developer experience in the 10.1.3 production release as we currently have in the 9.0.5/10.1.2 releases.

• Demonstration of (Best) practices for ADF ADF is still relatively new. To be frank – especially at first it is overwhelming. With ADF JHeadstart, we get many examples of how to solve certain problems in ADF. While not every solution picked by the JHeadstart team may be the best you can think of, they certainly spent a lot of time analyzing ADF, applying knowledge from previous experience with JHeadstart and discussing with the ADF development team about the best implementations for specific patterns in the ADF framework. I believe we can learn a lot about ADF by simply looking at the applications generated by ADF JHeadstart.
• That is where the JHeadstart team’s focus, effort, support etc. will be The JHeadstart team is not an infinitely large team. They have to set priorities and make decisions about where to focus. They have made it quite clear that their focus would be ADF JHeadstart. Most time, resources and field-work has been spent on ADF JHeadstart, ever since the release of JHeadstart 9.0.5.1, last June (2004). Do not expect serious new development for JHeadstart 9.0.5.x. While there may be some patches, there is no intention of serious new functionality; the closest we got to new functionality is through the AMIS JHeadstart Generator extensions that we releases several months ago. It is even questionable whether JHeadstart 9.0.5.x will be aligned with JDeveloper 10.1.2. That should make it clear that in order to benefit from continued support and new functionality from the JHeadstart team, moving to ADF JHeadstart is the smart move.

To consider

• Maturity of ADF – While Oracle is betting the bank on ADF and Oracle Apps seems on the verge of jumping right into it, ADF is relatively new. Better said: certain parts of ADF are new: ADF BC used to be called BC4J which has been around for many years (over five years I believe); ADF UIX, previously just UIX, has also been around for many years. ADF as a binding framework together with the design time tools in JDeveloper was first released in a Developer’s Preview of JDeveloper 9.0.5, Fall 2003. The first production release (9.0.5, ADF 1.0) appeared Spring 2004. JDeveloper 10.1.2 – december 2004- is the first serious release after that – this releases fixes many bugs but does not add new functionality. Experience with ADF on real life engagements seems to be somewhat limited. Many features that you would expect to be natively supported by the ADF Design Time – for example multi-record update/insert/delete – are currently only available through somewhat cumbersome How-To documents (see for example How To Create Multi Row Edit Forms in a JSP Page with Oracle JDeveloper 10g). I am convinced that Oracle is working very hard at improving and stabilizing ADF, if only to satisfy the requirements of the Oracle Apps development division who will become one of the main ADF customers in the near future. Before too long, ADF will have the maturity we require in the near future. Whether it is there already….
• ADF and UIX – on the one hand, UIX (and later on its successor ADF Faces) are very important for Oracle. ADF JHeadstart offers richer generation functionality for UIX. UIX very much seems the way to go. On the other hand: ADF and UIX do not seem to be optimally aligned. Sometimes UIX and ADF concepts even collide. It is also remarkable how most of the ADF How To and Sample documents, as well as Steve Muench’s ToyStore Demo are all in JSP. There are actually very few demonstrations of ADF and UIX. From Steve Muench’s weblogs on the ADF JHeadstart workshop he recently attended I even got the impression UIX was largely new to him! I wonder how mature and reliable the ADF-UIX combination currently is.
• Maturity of ADF JHeadstart – While it is considered a bonus that ADF JHeadstart was completely rearchitectured and redesigned, it also means that virtually none of the code that has been tested and proven over the last more than four years remains. The JHeadstart teams has learned a lot from the past four years – I rememeber Steven Davelaar and me doing our Project Atlantis presentation on the JHeadstart Designer Generator during ODTUG 2001 in San Diego; JHeadstart had been being developed for close to a year at that time! – and ADF JHeadstart is all the stronger because of that. But ADF JHeadstart’s code base only started life about a year ago. It has not yet reached the stability and maturity we have in JHeadstart 9.0.5.x. The production release of ADF JHeadstart 10.1.2 to some intents and purposes will be a 1.0 release. You may want to wait until the first support release, when the initials flaws are fixed and some experience and confidence has been built up. Having said all this, Oracle Consulting has been working with early builds of ADF JHeadstart since last Summer – most of it was built on-site from actual every day experience. So it is definitely not as untested and brand-new as I may have led you to believe.
• No migration path for previous JHeadstart applications (unless 100% generated). There is not well defined automated migration path for existing JHeadstart applications. In a previous post – Migration from JHeadstart 9.0.4.x or 9.0.5.x to ADF JHeadstart (beta) did I present experiences on migrating a completely generated JHeadstart application. Although not effortless, this is a rather smooth undertaking. However, applications that were customized after generation will prove very difficult to migrate. This holds true in particular for application with custom Struts Action Classes, modified DataObjectHandlerImpl classes and special navigation. Where customizations are only in the layout of individual pages, you will not encounter many difficulties.
• (less) Support for Toplink – JHeadstart 9.0.5.x provided support for Toplink as persistency implementation at the same level as BC4J/ADF BC. Through the DataObjectHandlerImpl classes that wrapped the persistency implementation, JHeadstart 9.0.5.x exposed the same data oriented business services to the application for both BC4J and Toplink. With ADF JHeadstart, the DataObjectHandlerImpl’s do no longer exist. ADF JHeadstart relies on the ADF runtime binding framework that provides adapater classes for different persistency implementation. However, this adapter is very rich for BC4J and rather poor for Toplink. As a result, because of the ADF runtime, an ADF JHeadstart application on top of Toplink is not as rich or resources conscious or performant as the same application on top of ADF BC. Hopefully the ADF team or the JHeadstart team will come up with a better Toplink adapter, on par with the ADF BC support and comparable with the JHeadstart 9.0.5.x runtime DataObjectHandlerImpl for Toplink.
• Acquire new ADF skills – you cannot develop serious ADF JHeadstart applications without proper skills in ADF. So if you decide to jump on the ADF JHeadstart train, you must expect to invest some time on building up ADF skills. Only if you will stick to 100% generation, you might get away without the ADF training.
• De-investment to some extent in JHeadstart skills. Although the generation process with ADF JHeadstart is very similar to the generation with the 9.0.5.x JHeadstart release, some smaller things have changed. More importantly, customizations on the generated applications are done rather differently. The struts-config.xml file looks very different with ADF. Custom Actions are developed in a rather different manner. The way the UIX pages and even more the JSPs are written and bind to the Model is different. A developer who is skilled at customizing a generated JHeadstart application will require some time and training to get to that same level of expertise with ADF JHeadstart.
• ADF means permanent dependency on JDeveloper as design time tool for development and maintenance(with current JHeadstart you can use JDeveloper only for generation and use any Java/J2EE IDE for further development and maintenance, as we did for example with Eclipse). This not so much a JHeadstart consideration but a ADF issue. ADF strictly speaking is a bunch of XML documents and Java sources, but it should be clear that JDeveloper as design time tool is mandatory. If you would try to maintain an ADF application outside of JDeveloper, productivity goes completely down the drain. Therefore, choosing ADF JHeadstart means choosing ADF means choosing JDeveloper. However, after having said all this, I found the following article on OTN: Using ADF without JDeveloper, Clemens Utschig-Utschig and Steve Anderson JDeveloper/ADF Development Team January 2005. They describe how you can build applications that benefit from the ADF runtime for DataBinding in a non-JDeveloper environment. However, while they demonstrate that using ADF without JDeveloper is possible, they do not convince me that it is viable.
• The production release of ADF JHeadstart is not yet available. It will be published somewhere in February 2005 is the current expectation. If you want to start development rightaway, ADF JHeadstart is simply not an option.
• (At least initially) fewer resources to support development, such as developer guides, tutorials, AMIS JHeadstart Cookbook etc. It will take some time for Oracle’s JHeadstart team, the AMIS JHeadstart team and others to produce the same set of resources that currently is available for JHeadstart developers.
• It seems like – although I am not sure about it – that ADF JHeadstart – or better said: ADF – will have somewhat less Toplink support; ADF is primarily geared towards ADF BC (previously BC4J); many of the features in ADF are automatically available for ADF BC, while they are not at all or only through manual steps accessible when using other Business Service technologies such as WebServices, Beans or EJBs.

Also see the FAQ on JHeadstart: . The following excerpt from this FAQ explains something about ADF and JHeadstart:

15. What is the relationship between JHeadstart and ADF?
ADF is Oracle’s overall J2EE Application Development Framework. For more information on ADF please refer to the JDeveloper Site on OTN. ADF is part of Oracle JDeveloper 9.0.5 and is a very productive J2EE Framework supported by excellent Design time tools. Our direction with JHeadstart is to fully align and integrate with ADF in the following areas:

* Use ADF data binding technology.
* Add ability to use JSTL and EL in generated JSP pages (in the current release, the Struts JSP tag library is used)
* Replace our custom BC4J generator with the Designer BC4j Generator within the JHeadstart Designer Generator (See 14.)
* Upgrade MVC Framework to ADF controller (ADFc) Note that ADFc is not yet available in JDeveloper 9.0.5.

The declarative ADF data binding technology will render some of the JHeadstart runtime components obsolete. The Application Generator, driven from the JHeadstart application structure file and ADF meta data, will remain a significant productivity booster, as well as some of the more sophisticated JHeadstart runtime components. Also, the JHeadstart Designer Generator adds significant value on top of the Designer BC4J generator: it allows you to migrate not only the Model, but a complete application including the View and Controller.
In summary, the generation capabilities of JHeadstart together with ADF will provide you with a very productive J2EE Development environment. You can generate “second cut” applications with JHeadstart and finish off the application using the ADF visual design time: pick up the generated struts-config with the ADF Struts page flow diagram and the generated UIX/JSP pages with the ADF design editor.

Conclusion/Summary

If you have decided as an organization to embrace Oracle’s Application Development Framework ADF, then ADF JHeadstart will be a real boon. It will enhance productivity enormously and it will provide you with a host of “best practices” that are even generated for you! It is my impression that ADF JHeadstart will need some time to get as stable and reliable as the 9.0.5.x release of JHeadstart currently is. For organizations with no immediate urgency to move to ADF, I would consider waiting a little for the dust to settle: for both ADF and ADF JHeadstart to go through one maintenance cycle. JHeadstart 9.0.5.x and hopefully a non-ADF JHeadstart 10.1.2 are less ‘proprietary’: once the application has been generated, you can maintain it with any J2EE IDE, such as Eclipse. The generated code as well as the runtime are more or less standard: Struts Action Classes and a Struts Config file, JSPs (or UIX pages), JavaScript etc. With ADF JHeadstart there is less JHeadstart runtime. But there is a inescapable dependency on JDeveloper and the ADF Design Time as well as Runtime. Either way, (ADF) JHeadstart boosts (intial) productivity enormously.