Slashdot Mirror
4GL to J2EE Conversion Tools?
FunkyGibbin' asks: "I've just started with a new company that has outsourced a project to translate a 4GL language - some 1.5 million lines of it - into J2EE. It's way behind schedule, and keeps on tripping over itself at acceptance test points (one item is fixed, others are broken). The outsourcing company chose as their conversion tool IBM's Rexx. They don't parse the 4GL to a syntax tree and then generate from that. They 'match patterns' which then generates the output. In addition, they're not even using the object oriented features of Rexx; it's in procedural Rexx! They have no regression test suite that runs through the original system and the newly generated system to ensure that they produce the same result [this apparently was 'our job' to do it manually]. Frankly, I consider the outsourcing company to have adopted completely the wrong approach, but I'm happy to be proven wrong if compiler construction or language translation experts can tell me that Rexx was their best choice, or even a reasonable choice! Any and all information gratefully accepted - this project has so far cost many dollars, and the board is unsure what to do with it."
There is only one way to go about this that works and everyone will like:
Gather requirements. Get input from everyone. Give a small drinking budget to programers who know someone who left (someone who left the company won't officially do work for you, but for a friend and a drink might give some insiteful rants on what is wrong, and this is invaluable in a re-design). Figgure out what was right, and what was wrong. Document how it should be, based on expirence.
Get some sort of translation between the 4gl, and the J2EE. (ip sockets work), and re-impliment whatever needs to be done. Look at exteem programing, re-factor all the code, but make it work with the old stuff so you always have something working. Re-do the stuff that is buggy, slow, or has new requirements first. (Don't be surprized if some unchanging piece never gets re-factored)
I've never done 4gl or J2EE (much less coversions one to the other), but my expirence in language conversions is everyone wants to do them not because of the limitations of the current language (even though there often are serious limitations, you can code around them), but because there is a lot of baddly designed code in the old system, and the conversion to something else is an excuse to re-write the bad parts. So get your requirements right this time, and get the design right.
Take it from some folks who've been there and done that -- in a much smaller way and have nevertheless gone through a lot of pain.
For the transition from WebObjects 4.5 to WebObjects 5.0, the developers at Apple created a converter that transforms Objective-C source code to Java source code. This was done by parsing the Objective-C source, creating a parse tree, and then running scripts against the parse tree. Simple pattern matching was found to be inadequate.
This was a much smaller project than the one that you seem to be involved in. Why? First off, as computer languages go Objective-C and Java are very, very close in terms of structure and design. Second, even with the talent involved in this project -- whom I am completely in awe of -- they only created an 80% solution. The goal was to produce something that could get a developer well down the road on the way to a conversion, not do the entire conversion.
Then, the Apple engineers tested this tool in the harshest environment possible -- their own code. It was used to convert the entire WebObjects source code from Objective-C to Java; they made it work before releasing it to customers.
Management needs to take a step back and ask, "what the heck are we trying to do here, anyway?" Unfortunately, it sounds a lot like your management has their heads 'way up in the wrong place. A useful piece that I read recently is the Happy Valley Tax Authority case study. <HINT>Consider yourself lucky that your resume is relatively current.</HINT>
--Paul