It's a fine idea, and Cognesis thought so too.  But they went bust trying.

There is also the problem that you would be using an OO paradigm to
implement procedural code, so you'd end up with a dead-end solution: your
Java code wouldn't really serve as the basis for future development.

Perhaps my colleague Wojtek Rappak will elaborate.  He has spent much more
time thinking about this than I have.  I am probably grossly simplifying his
views, but I think he feels it's a no-hoper.  All you can do is attempt to
manually extract the business logic from the ABF (usually a titanic struggle
all by itself), and then use that to design and implement an OO solution in
the traditional way.  The fundamental problem is that you can't write tools
that will intuit meaningful business objects from traditional "4GL" code.

A couple of years ago we tried to develop a server to run ABF by proxy: the
idea was to provide an interface to the ABF logic so that it could be
invoked from Java clients.  We sorta got it working, but ABF's limited and
patchy ability to "introspect" and fully expose its own meta-data made it
impossible to use except in special cases, so we abandoned it.  I suppose
that we could now fix ABF so that it could give us the meta-data we would
need, but I can think of about 20 other things I'd rather spend my energy on
now.  I still think this would be a better approach though, because you
would use good Java to run good ABF/4GL, instead of generating (necessarily)
crap Java to do things in an inescapably crap way.  And you could continue
to develop the 4GL code, so it wouldn't be a dead-end.

However, the ideal solution is much more radical than anything we've
mentioned above...but that's another thread for another time.

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"