Last week we examined a COBOL to Java path for 3000 applications which are migrating to other platforms. The story called out two suppliers, Veryant and LegacyJ, who have promoted the Java path to 3000 customers. Those companies were reading that article and offer even more detail on getting to Java, the "write once, run anywhere" language that's still got fairy dust on its collar 12 years after it went global.
Alfredo Iglesias of Veryant tells us that " the majority of our customers find the idea of leveraging their COBOL and application expertise while deploying pure Java applications is very attractive." You can move away from COBOL completely, too.
If someone who knows the COBOL application takes the time to study the Java libraries that isCOBOL provides for the runtime environment, it is possible to take our generated Java code, clean it from the COBOL ‘accent’ and continue development in the Java programming language.
Then there's Daniel Meyers of LegacyJ, the company named after its mission of getting legacy applications into Java. He says the company "has had HP-compatible COBOL and COBOL II solutions -- among 16 others -- for years." I think we'd all like to know more about another COBOL that, like AcuCOBOL, has had COBOL II intrinsics designed into it. Excising 3000 intrinsics from COBOL II can be detailed work, although UNICON reports it's got an automation tool to do this to 3000 apps.
Meyers told us in a scrappy e-mail that not only does his company's solution offer the same kind of cross-language COBOL-to-Java utility, he asserts that Veryant copied some LegacyJ concepts. (It's nice to know that the COBOL to Java jump is so established that two products can make similar claims.) We'll leave the two vendors to slug that copy issue out, but Meyers said this about LegacyJ.
12 years ago we solved the COBOL transition problem by providing a cross-compiler / translator to allow re-hosting without re-engineering, moving your applications over to the Java Virtual Machine environment. If you’re on an HP 3000, you can modernize more rapidly than other approaches.
Our high-speed COBOL compiler is written in C and generates an intermediate Cobol/Java code that can be maintained in COBOL or Java, works in any Java Virtual Machine-compatible environment, and is primarily used in Windows and Linux server situations. We generate Java bytecode, which operates with a runtime module to facilitate the operation on the more modern, affordable platforms that lend themselves to further modernization steps.
Veryant’s approach is much like ours, having been copied without permission from our original, patented technology -- though they decided to write their compiler in Java, trading speed for some notion of portability.
Veryant stresses that portability in its offer. Its isCOBOL points the way out of rejuvenating COBOL leadership on a development team, even while giving COBOL experts a role to play in the transition. Iglesias likes to refer prospects to a case study of Donato's Pizza, which "is leaving COBOL behind and rewriting its core business applications in Java."
Although many of Veryant’s customers use isCOBOL as the perfect bridge to leave COBOL programming in favor of Java programming, the toolset is currently designed for those customers that would like to continue to develop, maintain, debug in the COBOL language and deploy in the Java Runtime Environment.
Veryant customers... do not have to learn the Java programming language, Java scripting, Ajax, Web programming, etc. They are able to play in the Java sandbox using the COBOL programming language (including Object-Oriented COBOL), a standards based-COBOL compiler, a graphical, portable debugger with remote debugging capabilities, and a COBOL-friendly IDE based on the Eclipse platform.
Iglesias goes into more detail in his comment underneath the original article. Of note: isCOBOL will need some cleaning of its COBOL "accent" to make the code genuine Java. The isCOBOL Java is suited for the Java Runtime Environment, something quite different from Java programming language itself.