Java and Cobol differences

Question

Can anyone help comparing and contrasting between Java and cobol in terms of technical differences as well as architectural design styles

Answer 1

Similarities

1. Cobol and Java were going to change the world and solve the problem of programming.

2. Neither lived up to the initial hype.

3. There are now very large, bloated Cobol and Java programs that are used by banks and are "legacy" ... too large and critical to rewrite or throw away.

4. Cobol introduce the idea of having long, readable names in their code. Java recommends long, readable names.

Differences

1. Cobol was invented by an American, Grace Murray Hopper, who received the highest award by the Department of Defense, the Defense Distinguished Service Medal.

2. Java was invented by a Canadian, James Gosling, who received Canada's highest civilian honor, an Officer of the Order of Canada.

3 COBOL convention uses a "-" to separate words in names, Java convention uses upper/lower CamelCase.

Answer 2

COBOL was popular for the simple reason, to develop business applications.

Since the syntax was so clear and human-like, written in procedural style, it was for that reason, that made adapting to the changes in the business environment much easier, for example, to assign a value of pi to a variable, and then subtract zero from it - simple example to show the actual COBOL statements/sentences (it is years since I last programmed in Cobol)

MOVE 3.14 INTO VARPI.
SUBTRACT ZERO FROM VARPI GIVING VARPIRESULT.
IF VARPIRESULT AND ZERO EQUALS VARPI THEN DISPLAY 'Ok'.

If I remember, the COBOL sentences have to be at column 30...

And it is that, hence easier to troubleshoot because any potential business logic error can be easily pin-pointed as a result. Not alone that, since COBOL ran on mainframe systems, it was for a reason, the data transfer from files were shifted at a speed that is light-years ahead of the other systems such as PC's and that is another reason why data processing in COBOL was blindingly fast.

I have worked on the Y2k stuff on the mainframe (IBM MVS/360) and it was incredible at the dawn of the 21st century, praying that the fixes I put in wouldn't bring the business applications to their knees...that was hype, aside from that..to this day, it is still used because of the serious transfer speed of data shuffling around within mainframes and ease of maintainability.

I know for starters, Java would not just be able to do that, has Java got a port available for these mainframes (IBM MVS/360, 390, AS400)?

Now, businesses cannot afford to dump COBOL as they would effectively be 'committing suicide' as that is where their business applications resides on, which is the reason why the upgrade, migration, porting to a different language is too expensive and would cause a serious headache in the world of businesses today...

Not alone that, imagine having to rewrite procedural code which are legacy code and could contain vital business logic, to take advantage of the OOP style of Java, the end result would be 'lost in translation' and requiring a lot of patience, stress and pressure.

Imagine, a healthcare system (I have worked for one, which ran on the system I mentioned above), was to ditch all their claims processing,billing etc (written in COBOL) to Java, along with the potential for glitches and not to mention, serious $$$ amount of money to invest which would cost the healthcare company itself far more, the end result would be chaos and loss of money, and customers (corporations that offer employee benefits) would end up dumping the company for a better one.

So to answer your question, I hope I have illustrated the differences - to summarize:

COBOL is:

• Procedural language
• Simple human like syntax
• very fast on mainframe systems
• Easy to maintain code due to syntax

In contrast,

Java is:

• Object Oriented
• Syntax can get complicated
• Requires a Java Virtual Machine to run and execute the compiled bytecode.

Hope this helps,

Answer 3

It is easier to point out what they have in common instead of listing their differences.

So here is the list:

1. You can use both to make the computer do things
2. They both get compiled to yet a different language (machine code, byte-code)
3. That is it!

Answer 4

Similarities:

1. Both extremely verbose and created with pointy-haired bosses, not programmers, in mind.
2. Both used primarily for boring business software.
3. Both have huge legacy and are going to be around a while.

Answer 5

Cobol is a pure procedural language, not even functions in it (I used cobol in the 90s, so it might have changed since).
Java is OO (Although I heared there is a OO version for Cobol too), Oh...And the syntax is different.

---

Excelent list of similarities and differences : http://www.jsrsys.com/jsrsys/s8383sra.htm

It'swhat we do! COBOL: COBOL Concept Description Java: Java/OO Similar Concept ++: What Java/OO adds to Concept When I began Java, I used to think the OO (Object Orientation) was "just like" good programming practices, except it was more formal, and the compiler enforced certain restrictions.

I no longer think that way. However, when you are beginning I think certain "is similar to" examples will help you grasp the concepts.

COBOL: Load Module/Program Java: Class

COBOL: PERFORM Java: method ++: can pass parameters to method, more like FUNCTION other programs/classes can call methods in different classes if declared public. public/private gives designer much control over what other classes can see inside a class.

COBOL: Working Storage, statically linked sub-routine Java: instance variables ++: (see next)

COBOL: Working Storge, dynamically loaded sub-routine Java: Class variables ++: Java can mix both Class variables (called static, just the reverse of our COBOL example, and instance variables (the default). Class variables (static) occur only once per Class (really in one JVM run-time environment). Instance variables are unique to each instance of a class. Here is an example from class JsrSysout. From my COBOL background I like to debug my code by DISPLAYing significant data to the SYSOUT data set. There is a Java method for this, System.out.prinln(...). The problem with this method is that the data you want just scrolls off the Java console, the equivalent of SYSOUT or perhaps DISPLAY UPON CONSOLE if you had your own stand-alone machine. I needed a way to easily do displays that would stop when the screen was full. Since there is only one Java console, the line-count for the screen clearly needs to be a class variable, so all instances (each program/class that logs here has its own instance of JsrSysout) stop at the bottom of the screen.

Multiple Instances of same class: One (calling program) class can create multiple instances of the same class. Why would you want to do this? One good COBOL example is I/O routines. In COBOL you would need to code one I/O routine for each file you wish to access. If you want to open a particular file twice in one run-time environment you would need a different I/O routine with a different name, even if the logic was identical.

With Java you could code just one class for a particular logical file type. Then for each file you wish to read (or write) you simply create another instance of that class using the new operator. Here are some snippets of code from program IbfExtract that do exactly that. This program exploits the fact that I have written a class for Line Input, and another class for Line Output. These are called JsrLineIn and JsrLineOut.

This illustrates another dynamic feature of Java. When output is first created, it is an array of null pointers, it takes very little space. Only when a new object is created, and the pointer to it implicitly put in the array does storage for the object get allocated. That object can be anything from a String to an very complex Class.

COBOL: PICTURE Java: No real equivalent. I therefore invented a method to mymic a ZZZ,ZZZ,... mask for integer input. I have generally grouped my utility functions in JsrUtil. These are methods that really don't related to any type of object. Here is an example of padLeft that implements this logic. padLeft is also a good example of polymorphism. In COBOL, if you have different parameter lists you need different entry points. In Java, the types of parameters are part of the definition. For example:

COBOL: Decimal arithmetic Java: Not in native Java, but IBM has implemented some BigDecimal classes. I consider this the major weakness of Java for accounting type applications. I would have liked to see the packed decimal data type as part of the native JVM byte architecture. I guess it is not there because it is not in C or C++. I have only read about the BigDecimal classes, so I can't realy comment on their effectiveness.

COBOL: COPY or INCLUDE Java: Inheritance ++: Much more powerfull! In COBOL, if you change a COPY or INCLUDE member, you must recompile all the programs that use it. In Java, if program B inherits from program A, a change in program A is automatically inherited by program B without recompiling! Yes, this really works, and lends great power to Java applications. I exploited this for my Read/Sort/Report system. Class IbfReport contains all the basic logic common to the report programs. It has appropriate defaults for all of its methods. Classes IbfRP#### extend IbfReport, and contain only those methods unique to a particular report. If a change is made in IbfReport, it is reflected in the IbfRP#### programs (classes) the next time they are run.

COBOL: ON EXCEPTION Java: try/throw/catch ++: can limit scope of error detection (see following)

COBOL: OPEN Java: Input Streams ++: Automatic error detection, both a blessing and a curse.

COBOL: WRITE Java: write (yes, really).

COBOL: CLOSE Java: close method

COBOL: READ Java: read...

Answer 6

Both languages target the "Write Once, Run Anywhere" idea. If vendor specific extensions are avoided, Cobol is very portable.

Cobol is very much a procedural language, while Java is very much an object oriented language. That said, there have been vendor specific OO extensions to Cobol for decades, and the new specification contains a formal specification. It is also possible to write procedural code in Java, you can easily make a program out of a single main() method.

Both are widely used in enterprise computing for their relative ease of use. Both languages are somewhat hard to shoot yourself in the foot with, compared with other common languages like C and C++.

The most significant difference is that Cobol supports native fixed point arithmetic. This is very important when dealing with financals. Most languages, Java included, only support this via add on libraries, thus they are many orders of magnitude slower when dealing with fixed point data and prone to (potentially very expensive) errors in that library code.