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.
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.
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.
Java 是由加拿大人 James Gosling 发明的，他获得了加拿大最高平民荣誉——加拿大军官勋章。
Java 是由加拿大人 James
3 COBOL 约定使用“-”分隔名称中的单词，Java 约定使用大/小驼峰命名法。
Similarities
Cobol and Java were going to change the world and solve the problem of programming.
Neither lived up to the initial hype.
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.
Cobol introduce the idea of having long, readable names in their code. Java recommends long, readable names.
Differences
Cobol was invented by an American, Grace Murray Hopper, who received the highest award by the Department of Defense, the Defense Distinguished Service Medal.
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.
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.
发布评论
评论（6）
这两种语言都以“一次编写，随处运行”的理念为目标。如果避免供应商特定的扩展，Cobol 是非常可移植的。
Cobol 很大程度上是一种过程语言，而 Java 很大程度上是一种面向对象语言。也就是说，几十年来，Cobol 一直存在供应商特定的 OO 扩展，并且新规范包含正式规范。也可以用 Java 编写程序代码，您可以轻松地用单个 main() 方法编写程序。
两者因其相对易用性而广泛应用于企业计算。与 C 和 C++ 等其他常见语言相比，这两种语言都有点难以搬起石头砸自己的脚。
最显着的区别是 Cobol 支持本机定点运算。这在处理财务时非常重要。大多数语言（包括 Java）仅通过附加库来支持此功能，因此在处理定点数据时它们要慢很多数量级，并且在该库代码中容易出现（可能非常昂贵）错误。
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.
Cobol 是一种纯粹的过程语言，其中甚至没有函数（我在 90 年代使用过 cobol，所以从那以后它可能已经发生了变化）。
Java是OO的（虽然我听说Cobol也有OO版本），哦...而且语法不一样。
相似点和差异的优秀列表：http://www.jsrsys.com/jsrsys/s8383sra.htm
这就是我们所做的！
COBOL：COBOL概念描述
Java：Java/OO 类似概念
++：Java/OO 给 Concept 添加了什么
当我开始学习 Java 时，我曾经认为 OO（面向对象）“就像”良好的编程实践，只不过它更正式，并且编译器强制执行了某些限制。
我不再那样想了。但是，当您开始时，我认为某些“类似于”示例将帮助您掌握概念。
COBOL：加载模块/程序
Java：
COBOL 类：执行
Java：方法
++：可以向方法传递参数，更像FUNCTION
如果声明为公共，其他程序/类可以调用不同类中的方法。公共/私有使设计者能够更好地控制其他类在类中可以看到的内容。
COBOL：工作存储，静态链接子例程
Java：实例变量
++：（见下）
COBOL：工作存储，动态加载子例程
Java：类变量
++：Java 可以混合类变量（称为静态，与我们的 COBOL 示例相反）和实例变量（默认）。
类变量（静态）每个类仅出现一次（实际上在一个 JVM 运行时环境中）。
实例变量对于类的每个实例都是唯一的。
这是 JsrSysout 类的示例。从我的 COBOL 背景来看，我喜欢通过将重要数据显示到 SYSOUT 数据集来调试我的代码。有一个 Java 方法可以实现此目的，System.out.prinln(...)。这种方法的问题在于，您想要的数据只是从 Java 控制台滚动出来，相当于 SYSOUT，或者如果您有自己的独立计算机，则可能是 DISPLAY UPON CONSOLE。我需要一种方法来轻松地进行显示，当屏幕填满时，显示会停止。由于只有一个 Java 控制台，因此屏幕的行数显然需要是一个类变量，因此所有实例（此处记录的每个程序/类都有其自己的 JsrSysout 实例）都停止在屏幕底部。
同一类的多个实例：
一个（调用程序）类可以创建同一类的多个实例。你为什么要这样做？ I/O 例程是一个很好的 COBOL 示例。在 COBOL 中，您需要为您想要访问的每个文件编写一个 I/O 例程。如果您想在一个运行时环境中打开一个特定文件两次，您将需要一个具有不同名称的不同 I/O 例程，即使逻辑相同。
使用 Java，您可以为特定的逻辑文件类型只编写一个类。然后，对于您希望读取（或写入）的每个文件，您只需使用 new 运算符创建该类的另一个实例即可。以下是 IbfExtract 程序中的一些代码片段，它们正是执行此操作的。该程序利用了这样一个事实：我已经为行输入编写了一个类，为行输出编写了另一个类。它们称为 JsrLineIn 和 JsrLineOut。
这说明了Java的另一个动态特性。第一次创建输出时，它是一个空指针数组，占用的空间非常小。仅当创建新对象并将指向它的指针隐式放入数组时，才会为该对象分配存储空间。该对象可以是从字符串到非常复杂的类的任何对象。
科博尔：图片
Java：没有真正的等价物。
因此，我发明了一种方法来模拟 ZZZ,ZZZ,... 整数输入的掩码。我通常将实用程序函数分组到 JsrUtil 中。这些方法实际上与任何类型的对象都不相关。下面是实现此逻辑的 padLeft 示例。 padLeft 也是多态性的一个很好的例子。在 COBOL 中，如果您有不同的参数列表，则需要不同的入口点。在 Java 中，参数的类型是定义的一部分。例如：
COBOL：十进制算术
Java：不是在原生 Java 中，但 IBM 已经实现了一些 BigDecimal 类。
我认为这是 Java 对于会计类型应用程序的主要弱点。我希望看到打包十进制数据类型作为本机 JVM 字节架构的一部分。我猜它不存在，因为它不是用 C 或 C++ 编写的。我只读过 BigDecimal 类，所以我无法真正评论它们的有效性。
COBOL：复制或包含
Java：继承
++：更强大！
在 COBOL 中，如果更改 COPY 或 INCLUDE 成员，则必须重新编译所有使用它的程序。在Java中，如果程序B继承自程序A，则程序A中的更改将自动被程序B继承，而无需重新编译！是的，这确实有效，并且为 Java 应用程序提供了强大的功能。我将其用于我的读取/排序/报告系统。 IbfReport 类包含报表程序通用的所有基本逻辑。它的所有方法都有适当的默认值。类 IbfRP#### 扩展了 IbfReport，并且仅包含特定报告特有的方法。如果在 IbfReport 中进行更改，则会在下次运行 IbfRP#### 程序（类）时反映出来。
COBOL：例外
Java：尝试/抛出/捕获
++：可以限制错误检测的范围（见下文）
COBOL：OPEN
Java：输入流
++：自动错误检测，既是福也是祸。
COBOL：写
Java：写（是的，真的）。
COBOL：关闭
Java：关闭方法
COBOL：READ
Java：读...
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...
相似之处
Cobol 和 Java 将改变世界并解决编程问题。
两者都没有达到最初的炒作。
现在有非常大、臃肿的 Cobol 和 Java 程序，被银行使用，并且是“遗留”的......太大并且至关重要，无法重写或丢弃。
Cobol 引入了在代码中使用长且可读的名称的想法。 Java 建议使用长的、可读的名称。
差异
Cobol 是由美国人 Grace Murray Hopper 发明的，她获得了国防部的最高奖项——国防杰出服务奖章。
Java 是由加拿大人 James Gosling 发明的，他获得了加拿大最高平民荣誉——加拿大军官勋章。
Java 是由加拿大人 James
3 COBOL 约定使用“-”分隔名称中的单词，Java 约定使用大/小驼峰命名法。
Similarities
Cobol and Java were going to change the world and solve the problem of programming.
Neither lived up to the initial hype.
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.
Cobol introduce the idea of having long, readable names in their code. Java recommends long, readable names.
Differences
Cobol was invented by an American, Grace Murray Hopper, who received the highest award by the Department of Defense, the Defense Distinguished Service Medal.
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.
COBOL 流行的原因很简单：用于开发业务应用程序。
由于语法如此清晰和人性化，以过程化的方式编写，因此可以更容易地适应业务环境的变化，例如将 pi 的值赋给变量，然后从中减去零 - 显示实际 COBOL 语句/句子的简单示例（自从我上次用 Cobol 编程以来已有很多年了）
如果我记得的话，COBOL 句子必须位于第 30 列...
正是如此，因此更容易进行故障排除，因为任何潜在的业务逻辑错误都可以轻松查明。不仅如此，由于 COBOL 在大型机系统上运行，因此文件中的数据传输速度比 PC 等其他系统领先数光年，这也是 COBOL 中数据处理的另一个原因速度快得令人眼花缭乱。
我曾在大型机 (IBM MVS/360) 上从事 Y2k 相关工作，这在 21 世纪初真是令人难以置信，祈祷我所做的修复不会让业务应用程序瘫痪……那就是炒作，除此之外......直到今天，它仍然被使用，因为大型机内的数据传输速度很快并且易于维护。
我知道对于初学者来说，Java 不仅仅能够做到这一点，Java 是否有可用于这些大型机（IBM MVS/360、390、AS400）的端口？
现在，企业无法抛弃 COBOL，因为他们实际上会“自杀”，因为这是他们的业务应用程序所在的位置，这就是升级、迁移、移植到其他语言的成本太高并且会导致严重的问题的原因。当今商业世界中令人头疼的问题......
不仅如此，想象一下必须重写遗留代码并且可能包含重要业务逻辑的过程代码，以利用 Java 的 OOP 风格，最终结果将是“在翻译中丢失” ’并且需要很大的耐心、压力和压力。
想象一下，一个医疗保健系统（我曾工作过一个，它在我上面提到的系统上运行），将其所有索赔处理、计费等（用 COBOL 编写）都抛弃到 Java，以及潜在的故障，更不用说，大量的资金投入，这将使医疗保健公司本身花费更多，最终结果将是混乱和金钱损失，而客户（提供员工福利的公司）最终会抛弃该公司而选择更好的公司。
因此，为了回答您的问题，我希望我已经说明了差异 - 总结一下：
COBOL 是：
相比之下，
Java 是：
希望这有帮助，
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)
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:
In contrast,
Java is:
Hope this helps,
指出它们的共同点比列出它们的差异更容易。
所以这里是列表：
It is easier to point out what they have in common instead of listing their differences.
So here is the list:
相似之处：
Similarities: