Forms to Java migration at ODTUG

Although the presentations at ODTUG this year cover the entire spectrum of Oracle-based application development, from Forms and PL/SQL to ADF, SOA Suite and APEX, the ODTUG crowd is still a relatively Forms-oriented bunch. It is therefore not surprising that this audience drew a number of vendors offering Forms to Java migration solutions to the conference. As JHeadstart also offers a possibility to migrate Forms (via the Designer repository) to a J2EE application, this is a subject close to my heart.

JHeadstart was never developed to be a migration tool but as a RAD tool for J2EE application development, but because it is meta-data oriented just like Oracle Designer, a meta-data conversion from Designer to JHeadstart was a logical step. So, if you start with a Form, retrofit it into Designer, transform the Designer meta-data to JHeadstart meta-data, and generate a J2EE application using the JHeadstart Application Generator, you have a (rather indirect but nevertheless) migration path from Forms to Java.

In the US, this particular JHeadstart feature has always raised a lot of attention. I have manned a JHeadstart booth at OpenWorld a few years ago where I have discussed Forms-to-Java migrations so much that that just the memory of it makes my throat hurt again. There are many aspects to the issue of Forms-to-Java migration, the main one being “why would you want that”, but on a technical level, there is mostly one hot topic: what about the PL/SQL logic. Migrating the declarative functionality of Forms to any other architecture is a no-brainer, but the Forms PL/SQL that was often abundantly written in triggers, program units and PLL libraries, using Forms-specific built-ins and concepts are much harder to translate to a new runtime architecture. The JHeadstart stance on this has always been clear: don’t even go there. It only migrates the declarative functionality, and ignores everything else. Because the target architecture is a solid MVC based architecture, there is no way to determine in which layer which Form logic should be implemented, and for many of the triggers and built-ins available in Forms there are no logical counterparts in the J2EE architecture. And if you can’t migrate _all_ the logic, what point is there to migrate only some lines of code and not others? How can you guarantee that the lines you did migrate still work correctly without the lines you didn’t?

At this OpenWorld conference a few years ago, I was having these types of discussions with customers that were initially impressed with the claims of certain Forms-to-Java companies that boasted to do 100% migration of Forms to Java. Regardless of whether they could make good on this claim or not, the only way they could even attempt this was because they totally recreated the Forms Runtime environment in Java. This way, for every trigger, property, built-in etc. in Forms, they would have a similar Java method or class, and this way they could parse every line of PL/SQL in the Form and translate it to Java. I remember one of them being very proud of the fact that they “generated over 10.000 lines of code for one single FMB file”. I guess the logic behind them being proud of this feat was that you would otherwise have had to write those 10.000 lines of code yourself, but if you know that JHeadstart has ALWAYS managed to generated powerful web applications using proven frameworks and architectures without generating a SINGLE line of Java code, you understand why that does not impress me. They are, on the contrary, 10.000 lines of Java code you would NEVER have written if you had built the application in Java from scratch, but that you will now have to maintain forever!

And this is, I think, the most crucial point of migrating to Java: you should only migrate if the end result is exactly the same as the result which you would have gotten if you had rewritten the application in Java manually, using the tools and frameworks and architectures of your choice. And I am glad to say that the vendors I met today at the ODTUG conference are working from the same principles! Both IMEX Systems, with their ORMIT tool, and VGO Software with their EVO tool migrate Forms to ADF-based Java applications, rather than to an obscure proprietary Forms-runtime-written-in-Java type architecture. You can understand how this tickled my curiosity, and both me and my dear former collegue and JHeadstart founder Steven Davelaar have talked extensively to the representatives of both companies. What follows are my personal impressions based on what I have seen and heard today.

IMEX has a long history with Oracle Forms. They didn’t start out as a tools vendor but as a services company that specialized in Forms to Forms migrations. They put their experience in a tool called ORMIT-Forms, which is a very powerful aid in automated migrations from one Forms version to another. Originally they created the tool just for their own benefit, to be more competitive in the services market, but when they realized the potential of this tool they started selling it as well. The last year, they have started to work on a new tool called ORMIT-Java/ADF, to (what’s in a name) migrate Forms to ADF applications. The tool is not currently in production, but will be around August this year. What is very impressive, is that they intend to offer support for EJB 3.0, Toplink and ADF-BC as the persistence layer for the generated application. That is so impressive, in fact, that it makes me a bit suspicious. JHeadstart only supports ADF-BC as persistence framework because the ADF Binding implementations for other persistence frameworks are currently not powerful enough to support everything that JHeadstart can generate (and therefore, imho, also not powerful enough to support anything that Forms can do). Further inspection of the EJB 3.0 code (the other flavours are not ready at this time) indicated how they got around this: they claim to generate ADF applications but they do not use the ADF Model bindings at all. Also, the ADF Faces pages they generate are a mix of HTML and JSF, to preserve as much of the Look and Feel of the original Form. But these are two significant “violations” of my personal rule “migrate only if you end up with the same kind of application you would have gotten if you had built it from scratch”. You can’t claim to generate ADF applications but not use the ADF Model bindings which are at the heart of the architecture. Other concerns I have: I think it is incredibly ambitious to provide three different persistence technologies in your 1.0 release, and I wonder why they chose to do that. Expecially since the kind of developers that you are dealing with here (Forms developers, new to Java) are definately not the EJB 3.0 or Toplink type developers. In their presentation they consistently mentioned that migrating skills is the biggest challenge of all (with which I wholeheartedly agree), and in that light ADF BC should definately be the persistence technology of choice.

VGO Software, by contrast, is not a Forms-oriented company, but has its roots lying in Java. Although Steven and me have not seen the generated code yet (we will get a full demo tomorrow), we were glad to hear that they do generate ADF Model bindings and seem to have a good feel for solid Java architectures. I’ll post an update on their EVO tool tomorrow after the demo.

In conclusion, I am glad to see that these (to me at least) new players on the Forms-to-Java market are not clinging to the 100% migration story as much any more, but put much more focus on the architecture of the application you end up with, using proven frameworks and techniques.