Slide 2
CoJaC – COBOL to Java Converter

CoJaC is our tool to convert histo­ri­cal COBOL appli­ca­ti­ons into modern Java soluti­ons. CoJaC genera­tes maintainable and high-perfor­­mance Java code which is seman­ti­cally equiva­lent to the COBOL code.
During conver­sion, the tool reaches a degree of automa­tion up to 95 %. CoJaC combi­nes scien­ti­fic know-how in compi­ler construc­tion with the core compe­tency resul­ting from success­ful migration projects.


For complex trans­la­tion proces­ses, the use of speci­fic conver­sion tools, so-called trans­la­tors, is necessary. Trans­la­tors work by analogy with a compi­ler which trans­la­tes source programs into execu­ta­ble target code via diffe­rent inter­me­diate stages.

CoJaC is a trans­la­tor to convert histo­ri­cal COBOL appli­ca­ti­ons into modern Java soluti­ons. For the requi­re­ments of language conver­sion, we have further develo­ped the general compi­ler model into a trans­la­tor model:

  • FRONT END: Reads the COBOL program, inclu­ding the corre­spon­ding copybooks, and genera­tes an inter­nal syntax tree which repres­ents the complete COBOL program.
  • TRANS­FOR­MER: Converts the COBOL syntax tree into an equiva­lent Java syntax tree. The real conver­sion is carried out on the basis of syntax trees and not on the basis of source code.
  • POSTPRO­CES­SOR: Splits the complex Java syntax tree into indivi­dual syntax trees which repre­sent the program struc­ture of the subse­quent Java program.
  • GENERATOR/FORMATTER: Genera­tes Java classes and packa­ges from indivi­dual Java syntax trees and automa­ti­cally format source code accord­ing to client speci­fi­ca­ti­ons.
  • RUNTIME SYSTEM: Allows the use of the COBOL data types and functio­n­a­li­ties of the migra­ted Java code which do not exist 1:1 in Java.


  • Integra­tion of the source code comments into the target code
  • Struc­tu­ring of the target code into Java classes and packa­ges by our tool JPackage accord­ing to custo­mer specification
  • User-speci­­fic format­ting of the genera­ted Java code
  • Support of diffe­rent COBOL dialects (IBM, HPE NonStop, BS2000)


The following table exempli­fies some migration paths of the basic compon­ents pointing to the corre­spon­ding migration target:


The process of migration goes far beyond the mere program trans­for­ma­tion and inclu­des an archi­tec­ture migration as well:

The graphic here is an indica­tive example of the archi­tec­ture of a typical COBOL appli­ca­tion and the Java target system resul­ting from it.

  • COBOL server programs are provi­ded in the Java target system as web services.
  • COBOL batch programs (server) are trans­for­med into autono­mous Java programs.

The runtime system provi­des classes for proces­sing the migra­ted programs in the Java target environ­ment. This inclu­des classes for the COBOL data types (numeric and alpha­nu­me­ric data) and basic classes for arrays and struc­tures. In addition, there are methods that imple­ment the functio­n­a­lity of COBOL instruc­tions without native state­ments in Java (e.g. STRING and INSPECT). Further compon­ents are static methods for depic­ting the intrinsic functions, methods for type conver­sion and classes that provide the functio­n­a­lity of inter­faces (files, SQL, middle­ware). The runtime system forms the basis for a compact maintainable Java code.

Examp­les of the appli­ca­tion of the CoJaC runtime system:

Example of the migration of CALL statements

Example of the migration of CALL statements

Example of the migration of COMPUTE and ADD statements

Example of the migration of COMPUTE and ADD statements

Example of the migration of 88 steps

Example of the migration of 88 steps

COBOL-servers control­led by middle­ware (a transac­tion proces­sing monitor) are trans­la­ted into Java web services by CoJaC and integra­ted into an appli­ca­tion server. In doing so, middle­ware-speci­fic data and state­ments are removed or repla­ced by a corre­spon­ding web service functio­n­a­lity. In the process, the inter­face does not change in content. The web services process the same messages as the COBOL server before. Necessary conver­si­ons are encap­su­la­ted by the runtime system which also takes over adminis­tra­tion of transac­tions. Our tool MidaS (Middle­ware as a Service) is a light­weight alter­na­tive compa­red to commer­cial systems. MidaS provi­des an inter­face that is tailor-made for the migra­ted online programs and is easy to integrate into a Java server environment.

Example of middle­ware migration:

Example of migration of a COBOL server using middleware into a web service

Example of migration of a COBOL server using middle­ware into a web service

The data files used in COBOL are trans­for­med into relatio­nal database tables during migration by our tool FiRe. In doing so, the diffe­rent forms of organi­sa­tion and access methods are taken into account. Database tables are acces­sed in the conver­ted Java programs by using methods, which are provi­ded by the runtime system. These runtime system methods emulate the origi­nal COBOL state­ments on file work (OPEN, READ, READ NEXT, CLOSE, …).

Examp­les of file migration:

Example of the migration of file definition and sentence structure

Example of the migration of file defini­tion and sentence structure

Example of the migration of file accesses

Example of the migration of file accesses

Static SQL state­ments embed­ded into the COBOL source code are conver­ted into dynamic SQL state­ments. Mapping the functio­n­a­lity existing in the basic system, methods for adminis­tra­ting the database connec­tion, for database access, reading and writing of data into host varia­bles and for error handling are integra­ted into the runtime system. Accord­ing to experi­ence, the transi­tion to dynamic SQL does not result in runtime disad­van­ta­ges. At the same time, it allows flexi­ble creation and modifi­ca­tion of SQL statements.

Examp­les of migration of embed­ded SQL:

Example of migration of a SELECT statement with input and output host variables

Example of migration of a SELECT state­ment with input and output host variables

Example of migration of an INSERT statement

Example of migration of an INSERT statement

Example of migration of curser handling statements

Example of migration of cursor handling statements

The migration of the ASCII masks to web inter­faces is carried out by our tool MaTriX. A so-called mask server as a compo­nent of MaTriX coordi­na­tes the infor­ma­tion exchange between inter­faces and web services via messages.


We have proved in several migration projects that this works (e.g. COBOL to Java at ITZBund and SüdLea­sing). For COBOL to Java, large parts of the COBOL code (approx. 90–95 %) can be conver­ted automa­ti­cally. The CoJaC tool genera­tes seman­ti­cally equiva­lent Java code. The remai­ning 5–10 % are clearly indica­ted, for example, by appro­priate comments facili­ta­ting the manual conversion.

The COBOL programs were imple­men­ted in a proce­du­ral language. A redis­tri­bu­tion of functio­n­a­lity into indivi­dual classes and methods in the sense of the object-orien­ted concept is not automa­ti­cally possi­ble. This is not necessa­rily desira­ble since the develo­pers must recognise the code. A future, object-orien­ted further develo­p­ment of the genera­ted Java appli­ca­ti­ons can, of course, be done.

Yes, defini­tely. The basic struc­ture of the genera­ted Java code is analo­gous to the COBOL code. This incre­a­ses the recogni­tion effect. In addition, comments are inser­ted at the right positi­ons of the target code. The develo­pers of the old system (Java knowledge being the prere­qui­site) will find their way quickly. There are enough reference projects for automa­tic language trans­for­ma­tion from COBOL to Java, which practi­cally prove that the genera­ted code is maintainable and perfor­mant. The avail­able, modern IDEs (e.g. Intel­liJ and Eclipse) then allow a comfor­ta­ble further development.

Concerns are often expres­sed by compe­ti­tors who market their own COBOL develo­p­ment environ­ments and are, there­fore, not interes­ted in migra­ting “away from COBOL”.

Those state­ments, for which Java does not provide the corre­spon­ding language resour­ces, are not comple­tely conver­ti­ble. This mainly concerns the so-called “compi­ler-direc­ting state­ments”. These are first imple­men­ted during the trans­la­tion of the COBOL program so to say in a prepro­ces­sor step. Java, however, does not provide a prepro­ces­sor. Thus, these state­ments cannot be conver­ted with the common mecha­nisms. CoJaC inclu­des a sophisti­ca­ted mecha­nism to convert copybooks into separate Java classes.

GO TO state­ments can be migra­ted comple­tely automa­ti­cally. First, an attempt is made to replace them by Java typical state­ments. Jumps to the end of a section, for example, are trans­la­ted into Java by a return instruc­tion. If this is not possi­ble, the CoJaC runtime system takes over the flow control. In the program, GO TO is then execu­ted by calling a skip() method.

The state­ments for model­ling COBOL constructs into Java constructs were deliber­ately chosen in such a way that the genera­ted code is typical for Java. For example, Java classes encap­su­la­ting all necessary infor­ma­tion, such as length etc., and offering methods to adminis­trate them are provi­ded for diffe­rent data types in a runtime system. Where possi­ble, the native Java state­ments are directly used for loops (while, for) or if statements.

The basic struc­ture of a program remains identi­cal. A program is conver­ted into a class, data struc­tures become the (private) data fields of this class and indivi­dual sections of the PROCEDURE DIVISION become class methods. In doing so, the order within the source code remains unchanged. 

Copybooks are conver­ted into separate classes. Even if these copybooks are used several times, only one class will be created. Clones are only created when using COPY with REPLACING clause or COPY in the PROCEDURE DIVISION. We have with JPackage a tool capable of reuni­t­ing the resul­tant clones.

In addition to the signi­fi­cantly higher costs, you should also consi­der the project duration in this decision. If more than 90 % of the Java code is genera­ted automa­ti­cally, the program is of course conver­ted more rapidly than manually. Code freezes and poten­tial blocking times during further development/program mainten­ance will thus be minimi­sed. Our experi­ence has shown that the software migration in relation to a new develo­p­ment lies at 1:8, which means that if you calcu­late 5 man-years for a migration project using trans­for­ma­tion tools, you will need 40 man-years for a redeve­lo­p­ment of the same program system.

There are two alter­na­tive approa­ches for a redeve­lo­p­ment: either you rewrite the origi­nal program 1:1 in Java, in which case the code will be similar to the automa­ti­cally migra­ted code, and you can also automa­ti­cally migrate; or you extract the business logic of the program, create a speci­fi­ca­tion and then develop the program anew. The extrac­tion of the business logic is however a very time-consuming and error-prone process.

Of course, yes. This is another advan­tage of software migration. The develo­pers maintai­ning the conver­ted programs in future do not have to know COBOL. They can familia­rise themsel­ves with the environ­ment solely on the basis of the Java code.

Well, they have to learn Java. There is no way around this. These programm­ers, however, have the advan­tage that they are already familiar with the techni­cal background of the programs, whereas newco­mers have, of course, to first acquire the skills.

This is also an argument frequently voiced by custo­mers but that has never been found to be true in earlier projects. Perfor­mance problems only occur limited to indivi­dual programs and could be elimi­na­ted by suita­ble optimi­sa­tion measu­res. Thanks to the advan­ced techno­logy of the “just-in-time-Compi­ler”, today’s JVM process Java programs only slightly slower than the proces­sor the compi­led COBOL programs.

Tools for software migration require exten­sive develo­p­ment effort. In addition, very speci­fic know-how in infor­ma­tics (compi­ler techno­logy) is necessary. We have over 25 years of experi­ence in the develo­p­ment of tools for software migration. The basis is in its years of research work in the field of compi­ler techno­logy at the Faculty for Infor­ma­tics at the TU Chemnitz. We still carry out research and develo­p­ment in coope­ra­tion with the univer­si­ties of Koblenz-Landau and Olden­burg. The results are directly reflec­ted in our techno­lo­gies and tools.

In the course of past years, diffe­rent types of parser, code genera­tors, format­ting and meta tools have been develo­ped which are all combi­ned in our pecBOX (pro et con – Toolbox for Software Migration) and used in our migration projects. No migration project is like the other. For new projects, necessary, new migration tools are compi­led from the pecBOX compon­ents thus reducing the develo­p­ment time. This generic approach makes migration projects less expen­sive and reduces the project duration. This has been affir­med by numerous reference custo­mers like Amadeus Germany GmbH, MAN Truck & Bus SE, ITZBund, SüdLea­sing GmbH, to name a few.


“Vom COBOL-Server zum Java-Webser­vice”
Abstract for 12th “Workshop Software-Reengi­nee­ring” 3–5 May 2010 in Bad Honnef, publis­hed in:
Software­tech­nik-Trends, volume 30, part 2, May 2010

“Ein Trans­la­tor für die COBOL-Java-Migration“
Abstract for 13th “Workshop Software-Reengi­nee­ring” 2–4 May 2011 in Bad Honnef, publis­hed in:
Software­tech­nik-Trends, volume 31, part 2, May 2011

Success Story: “Success­ful BS2000 Migration at ITZBund