The Challenge of Converting Oracle Forms to ADF (or other J2EE)

“How do I convert my Oracle Forms applications to…?” I have been getting this kind of question ever since JDeveloper 3.0 was released. As soon as BC4J (now ADF BC) was created, we started seeing the handwriting on the wall. The era of Oracle Forms was coming to an end.

However, here we are ten years later and we still do not a have a capable converter from Forms to anything. Why not???

Converting from one platform to another is hard work.  Development architectures have different capabilities and very different ways of doing things.  Things that are dead simple in one environment may be nearly impossible to do in another. The user experience is influenced by what is easy to do in the environment. Oracle Forms had a lot of interesting features that are very hard to replicate in a web environment.

The following lists some of the interesting things about Forms that make converters challenging:

1. Forms uses PL/SQL for all scripting.  Java is about as far as you can get from PL/SQL.  PL/SQL is tightly coupled with the database. Java and JavaScript are explicitly database- agnostic.
2. In Forms, each user has his/her own Oracle schema. On the internet, we have single sign-on. Things like package variables and database objects can’t be expected to persist across UI events.
3. Forms has no real model layer.  Blocks are both UI grids as well as data sources. Migrating that into an MVC architecture is very difficult.
4. Forms has no notion of canvases nesting in other canvases (stacked canvases).  There is the base canvas and then you can place other canvases on top. Translating this into any kind of rational nested container system is going to be challenging.
5. Forms code is interpreted.  SHOW_ALERT actually pauses the code and waits for user input.  If the SHOW_ALERT command is hidden inside some kind of complex logic, conversion is going to be a nightmare.
6. Forms is client/server based, so quick round trips are simple.  You can easily write code to populate a city based on a zip code as soon as you lose focus. Doing that kind of thing in a web environment is usually not trivial.
7. Forms uses x/y layout. Many web environments do not even support pixel level x/y layout.

These challenges have not slowed down the converter companies.  For the last decade they have come and gone.  When they work at all they typically work as follows:

• The applications that the converter generates are totally different from any application you would have written if you had worked in the target environment from the start.
• The converters do not get you all the way there.  There is some amount of manual work required post-generation in order to get your system working.
• The user experience is about the same as what Forms provided. With modern web applications, no one is going to be very happy with a web application that looks exactly like an Oracle Forms application written ten years ago.

The Formspider™ architecture is closer to Oracle Forms than any product on the market for the following reasons:

1. FormsSpider supports x/y layout.
2. Because of the lightweight network round trips, it can support traditional client/server technology with little effort.
3. We use PL/SQL as the scripting language. All of the standard Forms APIs exist as APIs in our supplied packages.
4. We use a similar event model.  For example, you attach code to the “WhenButtonPressed” event on a button.

We acknowledge that it is possible to write a converter from Forms to Formspider.  We even spent some number of months trying to make it work.  But we eventually found that it is a Sisyphean problem (if you forgot your Greek mythology, Sisyphus was the guy cursed to keep rolling a boulder up an increasingly steep hill until it rolled back down and crushed him).  It is relatively easy to solve the problem badly (giving you just enough positive feedback to suck you in deeper) until you discover that there are about a million little things that you have to deal with.  Then you get a couple of clients to try it out and find that each client used a different subset of the Forms features.

If we could find a client with 800 or more forms willing to dump about $1,000,000 into solving the problem, we could write a really good converter… that would work for that one client. I am not so sure that it would work for anyone else very well.  It is just that big of a problem.

Trying to write a converter from Oracle Forms to ADF (or J2EE), Apex, .Net, PERL, Flash, Flex, Swing, or whatever… I wouldn’t even want to try.