Diferențe între Java și Cobol [închis] (Programare, Java, Cobol)

user246584 a intrebat.

Poate cineva să ajute la compararea și contrastul dintre Java și cobol în ceea ce privește diferențele tehnice, precum și stilurile de proiectare arhitecturală

Comentarii

  • Omule… de unde să încep! Această întrebare va avea un răspuns uriaș. –  > Por Kris Krause.
  • @dragthor: Ce ziceți de Divizia de Mediu? 🙂 –  > Por t0mm13b.
  • Posibil duplicat: stackoverflow.com/questions/2026857/porting-from-cobol-to-java –  > Por pavium.
  • +1 un potențial uriaș pentru lucruri amuzante –  > Por Itay Moav -Malimovka.
  • Întrebat mai devreme astăzi, aparent de aceeași persoană: stackoverflow.com/questions/2029397 (dar puțin mai bine formulat de data aceasta) –  > Por kdgregory.
6 răspunsuri
Larry Watanabe

Similitudini

  1. Cobol și Java urmau să schimbe lumea și să rezolve problema programării.

  2. Niciuna dintre ele nu s-a ridicat la înălțimea așteptărilor inițiale.

  3. Există acum programe Cobol și Java foarte mari și umflate care sunt folosite de bănci și care sunt „moștenite” … prea mari și critice pentru a fi rescrise sau aruncate.

  4. Cobol a introdus ideea de a avea nume lungi și lizibile în codul lor. Java recomandă nume lungi și ușor de citit.

Diferențe

  1. Cobol a fost inventat de o americancă, Grace Murray Hopper, care a primit cea mai înaltă distincție din partea Departamentului Apărării, Defense Distinguished Service Medal.

  2. Java a fost inventat de un canadian, James Gosling, care a primit cea mai înaltă distincție civilă din Canada, ofițer al Ordinului Canadei.

3 Convenția COBOL folosește un „-” pentru a separa cuvintele din nume, convenția Java folosește majuscule/ minuscule CamelCase.

t0mm13b

COBOL a fost popular pentru un motiv simplu, pentru a dezvolta aplicații de afaceri.

Deoarece sintaxa era atât de clară și asemănătoare cu cea umană, scrisă în stil procedural, din acest motiv, a făcut ca adaptarea la schimbările din mediul de afaceri să fie mult mai ușoară, de exemplu, pentru a atribui o valoare de pi la o variabilă și apoi a scădea zero din ea – un exemplu simplu pentru a arăta declarațiile/sincronizările COBOL actuale (sunt ani de când am programat ultima dată în Cobol)

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

Dacă îmi amintesc bine, propozițiile COBOL trebuie să fie la coloana 30…

Și este că, prin urmare, mai ușor de depanat, deoarece orice potențială eroare de logică de afaceri poate fi ușor de identificat ca urmare. Nu numai atât, deoarece COBOL a rulat pe sistemele mainframe, a fost pentru un motiv, transferul de date din fișiere a fost deplasat la o viteză care este cu ani lumină înaintea altor sisteme, cum ar fi PC-urile, și acesta este un alt motiv pentru care procesarea datelor în COBOL a fost orbitor de rapidă.

Am lucrat la chestiile Y2k pe mainframe (IBM MVS/360) și a fost incredibil la începutul secolului 21, rugându-mă ca soluțiile pe care le-am pus să nu îngenuncheze aplicațiile de afaceri… asta a fost o exagerare, în afară de asta… până în ziua de azi, este încă folosit datorită vitezei serioase de transfer a datelor care se amestecă în mainframe-uri și ușurinței de întreținere.

Știu, pentru început, că Java nu ar putea face doar asta, are Java un port disponibil pentru aceste mainframe-uri (IBM MVS/360, 390, AS400)?

În prezent, întreprinderile nu își pot permite să renunțe la COBOL, deoarece s-ar „sinucide”, deoarece aplicațiile lor de afaceri se află acolo, motiv pentru care actualizarea, migrarea, portarea către un alt limbaj este prea costisitoare și ar provoca mari dureri de cap în lumea întreprinderilor de astăzi…

Nu numai atât, imaginați-vă că trebuie să rescrieți codul procedural, care este un cod moștenit și care ar putea conține o logică de afaceri vitală, pentru a profita de stilul OOP al Java, rezultatul final ar fi „pierdut în traducere” și ar necesita multă răbdare, stres și presiune.

Imaginați-vă că un sistem de asistență medicală (am lucrat pentru unul, care funcționa pe sistemul menționat mai sus) ar trebui să renunțe la toate procesele de procesare a cererilor de rambursare, facturare etc. (scrise în COBOL) și să treacă la Java, împreună cu potențialul de erori și, ca să nu mai vorbim, cu sume importante de bani de investit care ar costa compania de asistență medicală însăși mult mai mult, rezultatul final ar fi haos și pierderi de bani, iar clienții (corporații care oferă beneficii angajaților) ar sfârși prin a renunța la companie pentru una mai bună.

Așadar, pentru a răspunde la întrebarea dumneavoastră, sper că am ilustrat diferențele – ca să rezumăm:

COBOL este:

  • Limbaj procedural
  • Sintaxă simplă, asemănătoare cu cea umană
  • foarte rapid pe sistemele mainframe
  • cod ușor de întreținut datorită sintaxei

În contrast,

Java este:

  • orientată pe obiecte
  • Sintaxa poate deveni complicată
  • Necesită o mașină virtuală Java pentru a rula și executa codul de octet compilat.

Sperăm că acest lucru vă ajută,

Comentarii

  • Există un proiect în desfășurare în acest moment la clientul meu în care o aplicație COBOL veche de zece ani care rulează pe un server central este retrasă și înlocuită cu o alternativă bazată pe Java, scrisă în aproximativ 6 luni, pur și simplu pentru că întreținerea serverului central se dovedește a fi mult prea costisitoare. La început, toată lumea a fost puțin îngrijorată (și probabil că încă mai este) de înlocuirea unui sistem care a „evoluat” de-a lungul multor ani într-o pată uriașă cu Dumnezeu știe ce logică și validări! Dar noul sistem pare să fie promițător. Dar aveți dreptate, nu am auzit niciodată de probleme de perfecționare cu mainframe-ul. –  > Por Raj.
  • @Ranju V: Wow! Succes cu strategia de migrare… Sper că totul va merge bine, trebuie să fi fost o decizie de afaceri foarte riscantă… vă încrucișez degetele… Mi-ar plăcea dacă ați putea posta aici cum decurge totul și ar fi de neprețuit pentru alții să citească… 🙂 –  > Por t0mm13b.
  • Toate ofertele IBM OS au de mult timp porturi Java disponibile pentru ele. Iar IBM Enterprise Cobol de la IBM Interoperă foarte bine cu Java prin moștenire încrucișată. Totuși, nu sunt de acord cu tine în ceea ce privește sintaxa – Cobol, cu cele 1.000 și ceva de cuvinte rezervate și cu o gramatică dependentă de context, are o sintaxă foarte întortocheată și greu de abordat, deși se întâmplă să fie una pe care majoritatea vorbitorilor de limba engleză o cam înțeleg. Java, pe de altă parte, cu doar o mână de cuvinte rezervate și o gramatică fără context, este extrem de concisă. –  > Por Joe Zitzelberger.
  • @Joe: Este evident că nu apreciați faptul că sintaxa COBOL este cea care stă la baza posibilității de a permite modificări ale logicii de afaceri într-un mod simplificat și mai ușor de înțeles… acesta este punctul pe care îl spuneam… încercați să explicați utilizarea iteratorilor și enumeratorilor Java, a genericilor, cuiva care trebuie să facă o modificare a logicii de afaceri existente – acesta este un alt motiv pentru care marile companii nu își pot permite să renunțe la ea, deoarece este este coloana vertebrală a activității lor! –  > Por t0mm13b.
Square Rig Master

Este mai ușor să subliniezi ceea ce au în comun decât să enumeri diferențele dintre ele.

Așa că iată lista:

  1. Le puteți folosi pe amândouă pentru a determina calculatorul să facă lucruri
  2. Ambele sunt compilate într-un limbaj diferit (cod mașină, byte-code).
  3. Asta este tot!

Comentarii

  • Ambele au bucle și condiții –  > Por Itay Moav -Malimovka.
dsimcha

Similitudini:

  1. Ambele sunt extrem de verbose și au fost create cu gândul la șefii cu părul ascuțit, nu la programatori.
  2. Ambele folosite în principal pentru software de afaceri plictisitor.
  3. Ambele au o moștenire uriașă și vor mai exista o vreme.

Comentarii

  • Program -> Service; JCL -> XML; Copybooks -> Beans; și așa mai departe. Mă întreb câte programe Java ajung să fie mai lungi decât programele (sistemele) COBOL echivalente? –  > Por Roboprog.
Joe Zitzelberger

Ambele limbaje vizează ideea „Scrie o dată, rulează oriunde”. Dacă se evită extensiile specifice furnizorului, Cobol este foarte portabil.

Cobol este în mare măsură un limbaj procedural, în timp ce Java este un limbaj orientat pe obiecte. Acestea fiind spuse, au existat extensii OO specifice furnizorului pentru Cobol timp de decenii, iar noua specificație conține o specificație formală. Este, de asemenea, posibil să se scrie cod procedural în Java, se poate realiza cu ușurință un program dintr-o singură metodă main().

Ambele sunt utilizate pe scară largă în informatica de întreprindere pentru ușurința lor relativă de utilizare. Ambele limbaje sunt oarecum greu de împușcat în picior, în comparație cu alte limbaje obișnuite precum C și C++.

Cea mai semnificativă diferență este că Cobol suportă aritmetica nativă în virgulă fixă. Acest lucru este foarte important atunci când se lucrează cu date financiare. Cele mai multe limbaje, inclusiv Java, suportă acest lucru doar prin intermediul bibliotecilor adiționale, astfel încât sunt cu multe ordine de mărime mai lente atunci când lucrează cu date în virgulă fixă și sunt predispuse la erori (potențial foarte costisitoare) în codul bibliotecii respective.

Itay Moav -Malimovka

Cobol este un limbaj pur procedural, nici măcar funcții în el (am folosit cobol în anii ’90, deci s-ar putea să se fi schimbat de atunci).
Java este OO (deși am auzit că există o versiune OO și pentru Cobol), Oh…Și sintaxa este diferită.


Excelent lista de asemănări și diferențe : http://www.jsrsys.com/jsrsys/s8383sra.htm

Este ceea ce facem noi!COBOL: Descrierea conceptului COBOLJava: Java/OO Concept similar++: Ce adaugă Java/OO la ConceptCând am început să lucrez cu Java, credeam că OO (Object Orientation) era „la fel ca” bunele practici de programare, doar că era mai formal, iar compilatorul impunea anumite restricții.

Nu mai gândesc în acest fel. Cu toate acestea, atunci când sunteți la început, cred că anumite exemple „este similar cu” vă vor ajuta să înțelegeți conceptele.

COBOL: Load Module/ProgramJava: Clasa

COBOL: PERFORMJava: method++: poate trece parametrii la metodă, mai mult ca FUNCTIONalte programe/clase pot apela metode din diferite clase dacă sunt declarate publice. public/private oferă proiectantului un mare control asupra a ceea ce alte clase pot vedea în interiorul unei clase.

COBOL: stocare de lucru, subprogram legat staticJava: variabile de instanță++: (a se vedea în continuare)

COBOL: Storge de lucru, subrutină încărcată dinamicJava: Variabile de clasă++: Java poate amesteca atât variabile de clasă (numite statice, exact invers față de exemplul nostru COBOL), cât și variabile de instanță (implicit).Variabilele de clasă (statice) apar o singură dată pentru fiecare clasă (în realitate, într-un singur mediu de execuție JVM).Variabilele de instanță sunt unice pentru fiecare instanță a unei clase.Iată un exemplu din clasa JsrSysout. Din trecutul meu COBOL, îmi place să-mi depanez codul prin afișarea datelor semnificative în setul de date SYSOUT. Există o metodă Java pentru acest lucru, System.out.prinln(…). Problema cu această metodă este că datele pe care le doriți pur și simplu se derulează pe consola Java, echivalentul lui SYSOUT sau poate DISPLAY UPON CONSOLE, dacă ați avea propria mașină autonomă. Aveam nevoie de o modalitate de a face cu ușurință afișări care să se oprească atunci când ecranul era plin. Deoarece există o singură consolă Java, numărul de linii pentru ecran trebuie să fie în mod clar o variabilă de clasă, astfel încât toate instanțele (fiecare program/clasă care se înregistrează aici are propria instanță de JsrSysout) să se oprească în partea de jos a ecranului.

Instanțe multiple ale aceleiași clase: O clasă (program de apelare) poate crea mai multe instanțe ale aceleiași clase. De ce ați dori să faceți acest lucru? Un bun exemplu COBOL este reprezentat de rutinele I/O. În COBOL ar trebui să codificați o rutină I/O pentru fiecare fișier pe care doriți să-l accesați. Dacă doriți să deschideți un anumit fișier de două ori într-un mediu de execuție, veți avea nevoie de o rutină I/O diferită cu un nume diferit, chiar dacă logica este identică.

Cu Java ați putea codifica o singură clasă pentru un anumit tip logic de fișier. Apoi, pentru fiecare fișier pe care doriți să îl citiți (sau să îl scrieți), trebuie doar să creați o altă instanță a acelei clase folosind operatorul new. Iată câteva fragmente de cod din programul IbfExtract care fac exact acest lucru. Acest program exploatează faptul că am scris o clasă pentru Line Input și o altă clasă pentru Line Output. Acestea se numesc JsrLineIn și JsrLineOut.

Acest lucru ilustrează o altă caracteristică dinamică a Java. Atunci când ieșirea este creată pentru prima dată, aceasta este o matrice de pointeri nuli, ocupă foarte puțin spațiu. Numai atunci când este creat un nou obiect și când pointerul la acesta este introdus implicit în matrice, se alocă spațiu de stocare pentru obiect. Acest obiect poate fi orice, de la un șir de caractere până la o clasă foarte complexă.

COBOL: PICTUREJava: Nu există un echivalent real.Prin urmare, am inventat o metodă pentru a micșora o mască ZZZ,ZZZ,… pentru o intrare de numere întregi. În general, mi-am grupat funcțiile utilitare în JsrUtil. Acestea sunt metode care nu au cu adevărat legătură cu niciun tip de obiect. Iată un exemplu de padLeft care implementează această logică. padLeft este, de asemenea, un bun exemplu de polimorfism. În COBOL, dacă aveți liste de parametri diferite, aveți nevoie de puncte de intrare diferite. În Java, tipurile de parametri fac parte din definiție. De exemplu:

COBOL: Aritmetică zecimalăJava: Nu în Java nativ, dar IBM a implementat câteva clase BigDecimal.Consider că acesta este principalul punct slab al Java pentru aplicațiile de tip contabilitate. Mi-ar fi plăcut să văd tipul de date zecimale împachetate ca parte a arhitecturii de octeți nativi JVM. Presupun că nu există pentru că nu este în C sau C++. Am citit doar despre clasele BigDecimal, așa că nu mă pot pronunța cu adevărat asupra eficienței lor.

COBOL: COPY sau INCLUDEJava: Inheritance++: Mult mai puternic!În COBOL, dacă modificați un membru COPY sau INCLUDE, trebuie să recompilați toate programele care îl utilizează. În Java, dacă programul B moștenește din programul A, o modificare în programul A este moștenită automat de programul B fără a fi necesară recompilarea! Da, acest lucru chiar funcționează și conferă o mare putere aplicațiilor Java. Am exploatat acest lucru pentru sistemul meu Read/Sort/Report. Clasa IbfReport conține toată logica de bază comună programelor de raportare. Ea are valori implicite corespunzătoare pentru toate metodele sale. Clasele IbfRP#### extind IbfReport și conțin doar acele metode unice pentru un anumit raport. Dacă se face o modificare în IbfReport, aceasta se reflectă în programele (clasele) IbfRP#### la următoarea execuție a acestora.

COBOL: ON EXCEPTIONJava: try/throw/catch++: poate limita domeniul de aplicare al detectării erorilor (a se vedea mai jos).

COBOL: OPENJava: Input Streams++: Detectarea automată a erorilor, atât o binecuvântare, cât și un blestem.

COBOL: WRITEJava: scrie (da, într-adevăr).

COBOL: CLOSEJava: metoda de închidere.

COBOL: READJava: citire…

Comentarii

  • Cobol are subprogramul imbricate, care funcționează exact ca o funcție C sau ca o funcție/procedură pascal. –  > Por Joe Zitzelberger.
  • @Joe Zitzelberger Au trecut mai bine de 10 ani de când am atins Cobol, dar nu sunt toate variabilele acolo în domeniul global? –  > Por Itay Moav -Malimovka.
  • Nu, deloc. Cobol 85 permite subprogramele imbricate care pot limita toată sfera de cuprindere la subprogramul care le înconjoară. Variabilele pot fi partajate cu toate subprogramele închise folosind cuvântul cheie GLOBAL, iar subprogramele pot fi partajate folosind cuvântul cheie COMMON. Subprogramele imbricate oferă o sferă de cuprindere mai bine limitată. Recunosc că există unii programatori Cobol care încă preferă să își scrie codul în stilul Cobol 74, cu totul global, dar nu există nimic în limbaj care să împiedice un programator conștiincios să scrie cod Cobol bine încapsulat. –  > Por Joe Zitzelberger.
  • În plus, cred că o mare parte din problemă constă în faptul că Cobol nu face o distincție între un „program” și o „funcție”, ci le numește pe amândouă „programe”. Deci, da, totul este global pentru un „program”, dar un „program” poate conține o cantitate infinită de „programe” care limitează domeniul de aplicare și sunt cunoscute doar de „programul” părinte – de exemplu, ceea ce alte limbaje numesc funcție sau procedură. –  > Por Joe Zitzelberger.
  • @Joe Zitzelberger – Mulțumesc pentru răspuns. –  > Por Itay Moav -Malimovka.

Tags:,