Automated Migration From Cobol To Java On Linux

Didier DURAND writes "Just published an article about our 100% automated migration from IBM mainframe with Cobol to Linux Java: we could convert of our own application (4 million lines of code) through the tools that we developed. Those tools are open-sourced under GPL for other companies to benefit from them. We save 3 millions euros / year after this migration!"

Comments

"Automated"

[0100010001010011]

Sounds like it could turn out like WYSIWYG HTML Editor code. Where every word you bold has the bold tags, etc.

Dreamweaver, Word, etc all make some dang ugly HTML.

Re:"Automated"

[nicolas.kassis]

Converting something that was unmaintainable due to lack of proper skils to something totally unmaintainable due to lack of readability is not a good trade off.

Re:"Automated"

[ADRA]

The alternative is to maintain a pool of cobol developers to maintain the code instead of hiring (probably much cheaper) Java developers to improve any bad code.

WYSIWYG's are a bad analogy, because it abstracts the process of writing HTML to a tool with the intent of writing HTML. In both cases (by hand or by machine) the results are HTML. With a -converter- like this one, the results may still generate bad code.

Re:"Automated"

[plopez]

Cheaper Java programmers compared to what? People who know the code and business rules or people who will take years to learn the code and business rule, by which time they will be just as expensive. BTW, one of the stated goals was to migrate the people as well. That argument is a non-starter.

Re:"Automated"

[Anonymous Coward]

"Converting something that was unmaintainable due to lack of proper skils to something totally unmaintainable due to lack of readability is not a good trade off."

I agree, there are a lot of inefficiencies.

Considering the inefficiency of the conversion process coupled with the inefficiency of such old legacy code plus a few other inefficiencies, even for example like java itself, I wonder how many extra servers they need to buy to offset all the combined inefficiencies?

Surely the next time they need to buy more servers, its time to optimize the code to gain the extra performance, rather than the extra costs of more hardware. Maintaining this old code converted to java doesn't sound like fun or cheap development work.

Re:"Automated"

[Anonymous Coward]

Troll more.

Re:"Automated"

[farmkid]

My first thought, exactly. But it turns out that human-maintainable code was a high priority.

Re:"Automated"

[popo]

There's something tragically ironic about the spelling error: "skils"

Re:"Automated"

[hamburgler007]

The right tool for the right job. Java is a perfectly acceptable programming language in many circumstances. The key is understanding what it is capable of and what its limitations are.

Re:"Automated"

[stevied]

The company that's produced this sounds like they're very keen on XP-ish development. Having a "transcoded" version of the COBOL that can be run on commodity platforms, while certainly not ideal from the viewpoint of maintainability (by people with modern skillsets), is a good first step to gradually converting to / extending with "natively written" Java.

Doing things step-by-step like they have done (and, I imagine, intend to continue to do) is a good way of making sure that they're on the right track and producing stuff that works. Too many "big bang" IT projects turn out to be utter disasters that ultimately have to be canceled, or only succeed years late and many times over budget.

Re:"Automated"

[Anonymous Coward]

Who will be able to maintain this Java code?
It's still procedural (sorry, I read TFA), only with a Java syntax.
This makes it hard to maintain for both Cobol programmers AND Java programmers.

At the current state of the art, making it object-oriented in a reasonable way is not possible in a fully automated way. I think that's the only real explanation why they kept the generated Java code procedural.

Re:"Automated"

[Lonewolf666]

Assuming the transcoder kept things like variable names, I guess the Java code will be more or less as (un)readable as the original. Maybe a bit worse because of "objectification" overhead without real gain in structure.

So they saved a lot of grunt work (translating to Java without changing the functionality), but there is still a lot to do. As in, reworking the old code to take proper advantage of object orientation.

Re:"Automated"

[stevied]

I sympathize, but I suspect you're out of date. I remember doing some projects in Java in 1996/97. My conclusions at the time were that the language was pretty nice and clean, but lacked some of the stuff that seemed to me at the time to be important (type-safe generic programming capability), the runtime was too slow and too clumsy (shouldn't have felt like installing another OS on top of my OS), and the standard libraries were reasonable except for some stupid omissions (no interruptible I/O primitives .. from a Unix company??), and a horrible GUI (twice: AWT didn't expose the richness of the native GUI, Swing was slow as a dog for a long, long time.)

I felt it had its place but couldn't understand what all the hype was about, and went back to my C++. Now I gather most of my grievances are fixed .. but I still don't understand why it took so long, or why everyone got so excited by version 1.0. Looking back, I'd've been interested in, say, a version of C++ with the direct memory access removed, i.e. no pointers, and some decent cross-platform standard libraries. The VM didn't interest me, but could easily have been added as an option later, as has happened with languages (Perl, Python, ...)

Of course, "web hype" sells stuff in IT, just like sex does everywhere else. Witness the current Web 2.0 lunacy, where everyone's excited that we might just finally manage to produce web apps with usability that approaches that of the native applications we had 15 years ago. *sigh*

Re:"Automated"

[Anonymous Coward]

Not really,

      I am 50 years old. If you hired me to maintain code that was originally developed 20 years ago with severe hardware and software limitations possibly also odd regulatory rules the likelihood that I alone could learn them just because I know COBOL compared to a JAVA programmer is not a fair assumption.

If you have silly reasons for doing process 1, 3,4,2 it does not matter if I can write in COBOL or JAVA ... I - or Mr. Java himself - will still have to figure out why you skipped over #2 the first time around ...

    Hiring a new COBOL programmer will require training on the code. You can just as easily teach a Java guy why you do silly things. The difference ?
The java guy will laugh at you while you are standing there . The Cobol guy will laugh at you when you have left the cube farm.

Re:"Automated"

[Anonymous Coward]

IMHO, they would have been far better off converting the mainframe Cobol code to Cobol on Linux (e.g. MicroFocus Cobol) or another open platform.
That way, their current programming staff wouldn't need much retraining, the changes would be far simpler (=less migration and testing costs) and they would still have the same benefits from moving to a much cheaper platform.
.

Re:"Automated"

[stevied]

The problem is, the alternative with these big, old, crusty legacy systems is to convert them in a "big bang", and it is usually pretty bloody difficult to just to figure out what the existing system is doing and and why. For some reason businesses seem to be quite happy to effectively "encrypt" lots of knowledge about their processes and throw away the key .. doubtless the understanding of the system did at one time exist in the brains of some humans, but they've usually long since moved companies, retired, or even died.

In this situation, a line-by-line transcoding that might (with some in-depth study) be comprehensible by Java coders and yet (with some gnashing of teeth) still by comprehended by COBOL coders, and more importantly be reasonably likely to duplicate the logic of the old system, is probably not a bad stepping stone. Hopefully it's a base from which the system can be converted piecemeal into "proper" Java, and extended.

Re:"Automated"

[dzfoo]

Ha, ha! You misspelled skilz!

      -dZ.

Re:"Automated"

[Anonymous Coward]

Surely the next time they need to buy more servers, its time to optimize the code to gain the extra performance, rather than the extra costs of more hardware. Maintaining this old code converted to java doesn't sound like fun or cheap development work.

Surely you jest -- I can buy a 4 node VMWare cluster including HA storage, software licenses, 128GB total ram, and 32 total cores of CPU processing power for less than it would cost to hire one developer for a year (in the US).

It rarely pays to optimize code unless you're someone like Google who performs the same query billions of times.

Re:"Automated"

[MightyMartian]

1998 called and wants it Java complaints back. Seriously though, if I were looking to port over reams of decades-old legacy code, Java would probably be exactly where I'd want to go. Even the performance hit (and it ain't that much nowadays) would be acceptable simply because I'd be moving to portable platform that would allow me to run the software on everything from x86/x64-based supercomputers and clusters right on down to my own workstation. The whole point of such an exercise isn't just to move these apps over to the latest hardware and operating systems, but to move them in such a way as to permit easier porting in the future.

Re:"Automated"

[cyber-vandal]

If there's a lack of proper skills in COBOL then why is no-one advertising for COBOL programmers anymore? I left IT because I found it impossible to get a COBOL job after Y2K.

Re:"Automated"

[filesiteguy]

"sluggish java"??

I've heard this misfound rumor time and again.

Java - when properly written - has been proven to be as fast in file operations, memory access and sequential processing as true "compiled" applications.

The same goes for other JIT languages such as .NET.

Re:"Automated"

[Anonymous Coward]

When java calls native compiled code, it's as fast as native compiled code? Congratulations.

Re:"Automated"

[umghhh]

If you knew Cobol at this hilarious time then you do not have to work anymore unless of course you were silly enough to work as a salary man instead of consulting for good money.

Re:"Automated"

[Migala77]

Have you read the article? The reason they did this had nothing to do with lack of proper skills; it was to reduce licensing costs by moving to an open source stack. In fact, they deliberately chose to do a 1-to-1 conversion, instead of rebuilding the system:

  - to keep the cobol-developers on-board, who know not just how the software works, but also why it does what it does
  - to prevent the project from becoming a big-bang-lets-fix-everything-project, doomed to fail, and instead stay focused on the savings it should bring
  - to be able to fully automate it, including all tests

I was skeptic when I read the summary, but from the presentation it looks like they handled it very well, and are now in a very good position to continue the improvements they started.

Re:"Automated"

[Bill Dog]

"natively written" Java

Heh, given that the term "compiled" was mutated to be made applicable, I can see this next, natively-written (vs. auto-converted) interpreted code being referred to as "native code"!

Re:"Automated"

[dkh2]

... I left IT because I found it impossible to get a COBOL job after Y2K.

Never fear my friend. We'll need you COBOL geeks again on 19-Jan-2038 when the UNIX system clock rolls over. Hope you're still available then.

Re:"Automated"

[Anonymous Coward]

Thankyou for clarifying my point, I was waiting for someone to catch on :)

Re:"Automated"

[Nutria]

Surely you jest -- I can buy a 4 node VMWare cluster including HA storage, software licenses, 128GB total ram, and 32 total cores of CPU processing power

And run the COBOL code using the MicroFocus or AcuCOBOL compilers.

Re:"Automated"

[Nutria]

But it turns out that human-maintainable code was a high priority.

Then use a Linux COBOL compiler, and convert the code module-by-module to something decent like COBOL-85.

Re:"Automated"

[nurb432]

Took the words out of my mouth..

It makes no sense to me to convert from cobol to most anything, especially when cobol is still a viable product from several vendors. Just get your people some training and start digging thru what you have, and clean it up. Cobol isn't that bad/hard once you know how to code in it.

Re:"Automated"

[JamesP]

to something totally unmaintainable due to lack of readability is not a good trade off.

I'm not sure what you meant. But I second it.

(Automatically) converted code is usually _a_huge_mess_. You lose context, (may lose) variable names, general structure of code, the converter doesn't "think java", some things may be converted to overly complicated pieces, etc, etc Also, the original programmers are subject to restrictions that today we don't have.

Think: string operations, db operations, etc

Re:"Automated"

[BenoitRen]

He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.

Re:"Automated"

[ralphdaugherty]

...it is usually pretty bloody difficult to just to figure out what the existing system is doing and and why.

      You're about the umpteenth post to point to a code readability problem which no one said existed as a reason for conversion.

      They stated clearly they were doing this to get off a mainframe and run off of PC server farms to save millions of dollars.

  rd

Re:"Automated"

[ralphdaugherty]

"sluggish java"??

      yes, and they also stated clearly they got better performance after the conversion.

      They did some cache architecting, static structures, and the like to accomplish that which I would consider hard to do. Depends on the level of mainframe and load they had I guess.

  rd

Re:"Automated"

[spiffmastercow]

I love how the java lovers mod every negative thing said about java as "Flamebait".

Re:"Automated"

[BikeHelmet]

This was coded in the 80's or 90's, correct? By senior engineers, at that time?

I'm pretty sure the people that really knew what the code did have long-since retired. ;P

As Java, it's at least a tad more maintainable. They can hire new coders to map out the functionality, and then eventually create a new version from scratch.

And in the meantime, it'll run on and take advantage of new servers.

I don't advocate Java for a lot, but I must say it's one of the best options for webserver craps.

Re:"Automated"

[ratboy666]

Read the comment again.

1996. Sluggish Java.

In 1996 I had a Pentium Pro with 64MB. I also used a SPARC based Ultra 10 (or was it a 5? My memory is a bit flaky...). Yes, Java was sluggish. I would even call it glacial, when compared to C/C++... I don't think it had a JIT, either (Hotspot was released in 2000).

Re:"Automated"

[Anonymous Coward]

please. Java is just as shitty now as it's ever been, maybe ever more so due to hype. Makes me wish for the days when everyone though PL/1 or COBOL would take over the universe. At least portability wasn't lied about back then. It has set programming back 15 years at least.

Of course it's perfect for this project. Just as slow and unmaintainable, but now runs poorly on modern, inexpensive hardware instead of legacy crap that costs a fortune just in power alone, let alone cooling and maintenance $.

And honestly, who in universe would try and port java to anything? This is about $, not portability.

Re:"Automated"

[hotfireball]

He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.

Nah, not perfect though, but let's don't hyperbolize it either: it does not sucks really anymore. Personally I write a lot of Swing stuff and I would not say it that sucks as before Java 1.4 times. At least now 1.6 I'd say much better than even GTK or QT. Why?

Because:

• performance is same as QT or GTK. No, sorry. Performance sometimes better e.g. when you have a really huge amount of records and put it into table -- in that case I wish GTK performed better and GTK-based wxWindows did not crash.
• In Java Swing you can create any possible widget you want per a very reasonable time, having it relatively easy. Example: http://download.java.net/javadesktop/scenario/demos/repaint-NestedTest.jnlp
• While Swing looks like a cockpit of 747, yet it is over-flexible and thus very powerful. Yes, it is scary to new comers, but once you figured out, you have to say it is really cool, extendable and portable.
• To write these kind of GUIs, including Quake-2 port in QT or GTK would take much more time for you. Not saying it is impossible. I am saying about time/cost/quality/competence/final-result-asap things.
• I love JNLP concept and it works rock stable on controlled or semi-controlled networks, once done properly. JNLP (Java Web Start) is way better for internal software and enterprises than Ajax thing or equivalent GTK/QT stuff, since I've done all of this and can compare what was the best to achieve with average-skilled programmers, cheapest and fastest to develop-and-deploy. And you must know that either. :-)

Additionally, you can use your own look-and-feel (including GTK's) etc. Of course, it has its side effects: you have to emulate specific platform etc. SWT does it natively, but it suffers from portability a lot, plus some parts are written in plain Java. Since API of various platforms changes and sometimes very drastically (like Apple is gonna drop Carbon one day), SWT renders to be a fool trap that always trying to catch up current status, but actually performs great only on Windows.

Add to the story really great try of NetBeans team to bring you GUI visual editor and you have to agree that at least you can create GUI stuff literally in front of your boss's eyes. I agree, Swing not the best yet, but also not that horrible as before anymore either. That's why we can commit our patches to Java 7! :-)

Re:"Automated"

[dwye]

Java - when properly written - has been proven to be as fast in file operations, memory access and sequential processing as true "compiled" applications.

Will the conversion program "properly write" its Java code, though? Care to lay odds? Especially considering that most COBOL code still in use is the code that uses COBOL's documented features (what were bugs in IBM 360, until they were written down, used, and so had to be replicated in any "real" COBOL implementation) to ... an unfortunate extent?

The place that I worked at had a project to convert its legacy COBOL to C/C++, and it got to 90% easily, but the last 10% required manual conversion and/or rewriting the converter to handle the "missing" elements. I doubt that conversion to Java will be any more successful, at least on live, rather than sample, code.

Re:"Automated"

[Anonymous Coward]

"Looking back, I'd've been interested in, say, a version of C++ with the direct memory access removed, i.e. no pointers, and some decent cross-platform standard libraries"

Sounds to me like you want(ed) C#. Mono appears to be your answer (:

Re:"Automated"

[hairyfeet]

And it will cost Cobol jobs! What is a matter with them, don't they want to save their economy? They are putting old folks out of a job! For shame, for shame.

Re:"Automated"

[Glonoinha]

Don't worry RD - all those guys are full of shit.
I tell you what, let's show those guys just how awesome Java is ...

Let's start with the fundamental awesomeness of Java (over that weak ass C and C++) by listing all the operating systems written completely in Java.

No?

Ok, maybe all the boot loaders written completely in Java.

No?

Hmmm.

Ok, maybe all the space vehicles and satellites running completely on Java.

No?

Shit.

Ok, how about the end-all, be-all of language completeness : this will show them - WHAT LANGUAGE IS THE JAVA RUNTIME WRITTEN IN?

What's that? Not Java?

Well shit.

Fuck those haters. You watch, some day someone is going to invent a nice Java-like language (we can use pretty much the same syntax as Java) that is compiled instead of interpreted and will create native executables that run on the bare metal, something that can be used to write lightning fast applications, and even be used to write Unix and Windows type operating systems. It will be like 'Compiled Java', or maybe CJ for short. Maybe even shorten it a little more to just 'C'. And then people will write all kinds of fast, stable, OS quality binary code in this new version of Java, which we will call C. That will show them how awesome Java really is.

Re:"Automated"

[WNight]

When "everything" is, "It's slow!", yeah.

Yes, yawn, there are some things Java is slow for and that need speed. You shouldn't do those few things in Java. So what if it starts slow? Don't spawn new processes to handle incoming connections. For any given issue there are workarounds. If there are too many issues to justify it, use another tool.

But, please, SHUT THE FUCK UP ABOUT IT!

Seriously, just don't fucking use it. Just because you're too retarded to evaluate tools for the job at hand doesn't mean everyone else is.

Java's not my choice either, but I don't feel the need to find every Java coder I know and rub it in. They're too busy redundantly declaring types to stop to chat anyways...

Re:"Automated"

[WNight]

And yet you'd have to be blind to think there are as many Cobol programmers to read that source as Java programmers. So it couldn't not apply, even if they didn't spell it out.

Besides, you can sort of tell by the type of processes used. People doing these transitions (automated rewrite, emulation, etc) are usually doing it because they've lost the ability to work with the system.

Yes, they might be saving a ton of money on the hardware, but that's not the whole story. If they were comfortable with the system they'd have rewritten it piecemeal by now and it wouldn't be here to be transitioned in one big piece.

Re:"Automated"

[rve]

Dreamweaver, Word, etc all make some dang ugly HTML.

So what? HTML is not meant for pleasing the human eye anyway, it's for the browser's HTML rendering engine.

A modem makes some dang ugly white noise

Re:"Automated"

[spiffmastercow]

haha I know, and you're right. It's just hard to do when you see a "Java is actually faster than optimized assembly" thread (not that this is one, but you know what I'm talking about). To be honest I've been baiting the flames just so I can see a few of those. They make me smile :)

Re:"Automated"

[jonaskoelker]

lacked some of the stuff that seemed to me at the time to be important (type-safe generic programming capability)

Without it, you get all the brevity of manifest static typing, i.e. having to type a lot of type names, with all the run-time guarantees of dynamic typing, since you're putting in casts (adding even more typing) everywhere you take stuff out of collections.

Type inference with optional declarations and class-bounded polymorphism ftw: as little typing as you like, as much explicitness as you like, static guarantees, and you can have a List of Fruit which can contain both Apples and Oranges.

It's a real shame Java still forces everything to be a class, because sometimes it's just the wrong tool.

Re:"Automated"

[stevied]

Possibly. I've not kept up to date with all the new-fangled toys you kids have these days ;-) Does it support generic programming? Also, isn't it only cross-platform because of Miguel de Icaza?

There are lots more elegant, reasonably high-performing, cross-platform languages around now. It's probably a much more interesting time to be getting into IT - as long you as you can find a company that actually lets you use the cool new stuff ..

Re:"Automated"

[TheRaven64]

Let's start with the fundamental awesomeness of Java (over that weak ass C and C++) by listing all the operating systems written completely in Java.

What an incredibly stupid test. First, no operating system is written completely in C either. C is not expressive enough for the low-level initialisation code required by most CPUs, so every modern OS begins with some bootstrapping code written in assembler for the host platform. After the CPU is initialised, you can jump to something in a high-level (i.e. not processor dependent) language. For the record, I can name operating systems written in C, Java, C#, Algol*, Lisp*, Smalltalk, Ocaml, Pascal, and even one that has device drivers written in Python.

* For these languages I can name operating systems for specific platforms which didn't need any assembly code for bootstrapping, but that's slightly cheating because they

WHAT LANGUAGE IS THE JAVA RUNTIME WRITTEN IN?

Java mostly, although this depends on the JRE you use. The first JREs were written by Smalltalk and Self hackers. A lot of Smalltalk VMs were all written in Smalltalk, specifically a subset of Smalltalk that was statically compiled (by a compiler written in Smalltalk), which then ran the rest of the environment.

You watch, some day someone is going to invent a nice Java-like language (we can use pretty much the same syntax as Java) that is compiled instead of interpreted and will create native executables that run on the bare metal, something that can be used to write lightning fast applications, and even be used to write Unix and Windows type operating systems

Ah, I see. You're an idiot who confuses a language with an implementation of a language. There's nothing stopping Java from being compiled; gcj produces static binaries from Java code, for example. Objective-C has all of the dynamic features of Java and is statically compiled. I've written a Smalltalk compiler that contains both a JIT and a static compiler, and can produce native object code from Smalltalk. Common Lisp is also statically compiled, and something like the Steel-Bank Common Lisp compiler has similar performance to g++.

Similarly, it's possible to run C in a VM. Last year's LLVM developer meeting demoed a JIT compiler for C. If you do this then you can run all sorts of run-time profiling and dynamic optimisations (just as you typically do for Java).

Re:"Automated"

[binarylarry]

Wow, you sound like you know A LOT about computers.

ROFL

Re:"Automated"

[Dog-Cow]

I don't know about any particular Java JIT, but JIT -ed code can be faster than assembly, or even compiler-optimized C. This is because runtime compilation allows runtime optimization. HP has/d a product for PA-RISC that would run natively compiled code under a JIT in order to do runtime optimizations. Long running code could see a 10%+ speedup.

Re:"Automated"

[maraist]

C# might be better than java, but Java is an order of magnitude better than Cobol. And they weren't building an 'open-source' MS + C# stack. And Linux + mono stack is no where near the performance capability of MS C# or SUN/IBM Java. Consider that 90% of the java-byte-code is rewritten as highly optimized assembly in a server environment (often better than hand tuned C/C++). You're assessment of java is clearly wrong.

And as to the basic premise of this thread that java is a lesser programming environment - speaking from someone that favored C over C++ for 10 years, I loath going back to open-source C projects v.s. Java projects. A good editor makes reverse engineering Java-code take minutes instead of hours for C. The static-typing nature of a Java development environment means nearly 90% guarantees that code does what code means.. no side-effects, no package/name-space trickery. An editor can be nearly 90% correct in saying "here are all the code points that utilize this class/method/field". So I can reverse engineer how the code is used. I can walk through code, not worrying WHICH of 50 #ifdef's/alternate-.o files the compiled code is going to actually need - so 'drill-down-to-method' is concise. The remaining 10% is due to reflective/aspect-oriented code (sadly now taking over in the Java space). Thankfully much of the AOP is compartmentalized such that editors have a very good idea of where the use-points and jump-points should be.

If you don't believe me, TRY and read through all the lines of apache or mysql-INNODB, and compare that to running through the lines of java-tomcat or java-hsqldb. And tomcat is FASTER than core apache for static files (though of course there are plugins that do various things in a specialized way faster).

Reading code is VERY much a function of seeing both the bigger picture and the details from the same vantage point. The greater a developers perspective into code, the greater his ability to assess the correctness and more importantly the extensibility of code.

C-code, in general is not extensible. It's tool-box based. C++ is better, but most methods are not declared virtual, so they're essentially static c-functions for the purposes of a 3'rd party. Even only decent java code is fully extensible - especially when written with interfaces + injection-oriented design (the latter only being a recent trend). Thus even your toolboxes can be used in ways the originators never imagined possible. The reason one might not declare methods as virtual in C++ are performance, but thanks to Java JIT, all functions are treated as 'final' in the end product - all virtual methods are effectively inlined where practical. Thus there' no reason to artificially castrate your java code for the performance Gods.

And don't forget, nobody runs COBOL in as a web-plugin.

Re:"Automated"

[Anonymous Coward]

It's not a rumor.

Try to start a simple Java program and a simple C program. Can you guess the wall clock difference between the executions?

Now I get bashed from the Java community, cause Java needs to warm up first.. so this simple example isn't fair they say.

To resolve the startup issue, Java caches pre-jit version (so no code verification is needed) on disc and loads them right up.
Sadly just loading this cache takes as long time as executing a small C program.

The answer to this problem from the Java people are: Normal program execute longer time then a few seconds!

No most programs execute in less then a second, cause the most used commands available would be the shell commands. And they are small.

But Java are faster on bigger program, cause it can runtime optimize, and reoptimize during execution.

You know Java can do all that, that's true. It's also true that it wont compile a method until it has become a hotspot, depending on JVM properties, this can be as much as 10000 executions of that method. Until the JIT happens it's all running in Interpreted mode.
I remember a benchmark we did between JIT and non JITed java code. The execution speed difference was 22 times.

Java will compile everything eventually, and collect statistics and recompile again, using inlining and other optimization strategies like dead code removal, and will actually beat the average C programmer.

Yes true, if you do not use these things Java would be faster then C. Question: What happens when a C programmer do use these strategies? About average, what defines average, thinking about these things are part of being a Software Developer. It's part of your job description. You learn the language you use.

GC is faster then malloc/free on C

Have you tries to write code to kick malloc/free in speed? Really? have you? It's really really hard, I have tried. Yes the GC has a number of very interesting speed hacks.. That is the normally way how you beat the malloc implementation in C.

Before I leave this post, I just gotta give you one more thing to think of, cause you probably hate me already. Did you know that Java actually do not JIT methods that are bigger then 8000bytes of bytecode.. Those method are always executed in interpreted mode..

Think about it.

Re:"Automated"

[Glonoinha]

Excellent - I've been looking for an OS written completely in Java. Could you name that one for me? I've got a spare laptop laying around and I could install it to play with it. I'm getting bored with all those C based operating systems like Windows and all those variants of Linux.

As for the JRE, I was talking about the Sun JRE. Last I heard it was written in C. In sticking with a factual (rather than emotional) discussion you might have brought light to that fact. Let's not let the facts get in the way of a perfectly good reply, however.

Ah, I see. You're an idiot who confuses a language with an implementation of a language.

No, I believe the phrase you are looking for is 'retard'. As in 'Arguing on the Internet is a lot like competing in the Special Olympics, even if you win, you're still a retard.'

For future reference, when your discussion has merit it will succeed without name calling. It's possible that you have completely redeemed Java in all its glory in that paragraph, yet your delivery was abrasive and started with name calling - destroying any benefit your efforts might have had. It's counter productive.

If you want to espouse the merits of Java, do so on its strengths. Machine specific compiled code and operating systems as they are generally understood are not Java's strength, so don't try to force that issue. Instead, redefine operating system into what the bigger picture of an OS has become (much the way Microsoft has extended their OS to include interaction with the Internet resources - Internet Explorer.) When you consider the bigger picture of user interaction with a machine, Internet based productivity suites such as Google's suite of productivity tools as delivered through the browser - Java allows the developer to create applications that can be coded platform agnostic and run on any platform capable of hosting the runtime engine, allowing a distributed environment of clients and servers. When you redefine the computer from 'the bare metal' to 'the machine (including the core underlying OS and the browser capable of running web based applications) then Java is a damn fine language for implementing what is, in effect, the 'operating system' upon which distributed applications (web based applications) run. Java evolved over time parallel to the popularity growth of TCP/IP based communications and a computing environment that moved away from isolated machines towards a grid of networked resources, and adopted to the distributed applications model allowing for centrally stored code to be run on remote clients without concern for binary compatibility. The development of the J2EE model and extensions to the Java language allowed for developers to build stateful applications in a stateless environment, allowing for the distributed commerce model we all use today. And once we've redefined the computer to be the sandbox in which all of this runs (ie, the JRE running on 'the machine', client or server) then Java is not only a good choice for 'operating system' - it's the only choice for 'operating system'.

Re:"Automated"

[Anonymous Coward]

No one may speak of suffering until they have written a program in COBOL.

Re:"Automated"

[Hognoxious]

1998 called and wants it Java complaints back.

Now you know that's a lie. It's still waiting for Eclipse to open.

The veal is off, by the way.

Re:"Automated"

[ralphdaugherty]

Don't worry RD - all those guys are full of shit.

      whoa sparky, I wasn't comparing Java to C++, I stated that TFA said they got better performance with the converted Java than their prior mainframe COBOL environment which I said I would consider hard to do. They cached and static'd everything in Java and not sure what kind of mainframe environment they had that could be so bad.

      I also say the same things as you do to Java (and PHP and scripted languages) advocates, which are legion, about ERP systems. Just as you list things in OS capabilities that aren't done in Java for performance reasons, the same is true for ERP systems, although Oracle is trying real hard.

      Not that I'm a C++ fan. I'm a business systems developer, and RPG is a better business systems language than C++, although in our ILE environment on the AS/400 iseries we can develop and link in C and/or C++ modules with RPG modules if we so desired.

  rd

Re:"Automated"

[Entrinzikyl]

It's possible that you have completely redeemed Java in all its glory in that paragraph, yet your delivery was abrasive and started with name calling - destroying any benefit your efforts might have had. It's counter productive.

The sarcasm in your initial comment was equally as abrasive, which, I think, led to the abrasiveness of the reply. That said, like every argument ever about what languages are good, it really just comes to what you finally said, basically that Java is a damn fine language for implementing certain applications, and though it can be used in other contexts, there are sometimes better alternatives.

Re:"Automated"

[elnyka]

He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.

I'm looking forward to see you implementing large-scale enterprise integration solutions for heterogeneous environments in C or assembly, cuz, you know, the VM is still slow.

Reality check dude:

1. Speed comparisons in pet/schoolwork projects don't count.

2. Speed is context-sensitive. You don't compare speed of application programming languages versus speed of system programming languages.

3. Performance is a factor that needs to be weighted out against other concerns such as deployability, extensibility, interoperability, and even the business requirements that drive an implementation's effort.

4. Real-life applications that matter run for weeks, months, even years... so cares if the VM is still slow to start.

5. GUI libraries might suck, but they are certainly easier to use than *nix widgets or MSVC stuff. Use the right tool for the specific task at hand, and for some tasks (but not all) Java GUI libraries work just fine.

6. Who cares if Java GUI libraries suck. Most java apps are web-based or run on the back-end anyways.

Re:"Automated"

[Anonymous Coward]

Maybe you should RTFA.

Re:"Automated"

[stevied]

Exactly. The code degenerates into an unreadable mess and the type-safety goes out of the window. *sigh*

Re:"Automated"

[DragonWriter]

Converting something that was unmaintainable due to lack of proper skils to something totally unmaintainable due to lack of readability is not a good trade off.

Even if mostly unreadable (which I don't see evidence of, just an assumption), its probably easier to do piecemeal replacement with readable and relatively maintanable code if you are in Java rather than COBOL to start with.

Its not a good solution, but it may be the least-worst alternative for some existing systems.

Re:"Automated"

[sproketboy]

http://www.jnode.org/

Re:"Automated"

[SiggyTheViking]

You guys are funny.
Thanks for a good read.
Siggy

Re:"Automated"

[Anonymous Coward]

Bitch about the java language itself or the resulting code this tool produces all you want, but the fact that the tool (supposedly) produces a working application on a platform that doesn't require such monumental flows of money to support it (most of that merely 'in case' something goes wrong) is very likely the single largest incentive. If someone with both IT and accounting nouse saw the big picture I'm not surprised their gutsy call was to get the hell off the mainframe platform ASAP.

The resulting savings on platform costs will give them the freedom to take action in so many more ways than they could have previously. Including a rewrite in whatever language they choose.

Re:"Automated"

[Anonymous Coward]

For the record, I can name operating systems written in C, Java, C#, Algol*, Lisp*, Smalltalk, Ocaml, Pascal, and even one that has device drivers written in Python.

Good for you. Do you actually use any of them??? Can you name 1% of the OS market that does?

I'm not sure what your point is. Its well demonstrated that C (and not Java) is the language of choice for working close to the metal. That is indisputable. You can use other languages, but even Microsoft knows you'd be an idiot to do so.

Re:"Automated"

[Glonoinha]

Yea, evidently I get quite animated and am easily amused after a few drinks, and I was taking a new bottle of Scotch for a test drive. Glenfiddich 21 Year Old, in case anybody is curious, and it's pretty damn good. If you don't see the humor in my post, have a few glasses of this stuff and read it again.

At least I didn't email all my friends or start texting random people on my phone - they aren't nearly as open minded about language holy wars as your average /. reader.

As for the difference in performance between COBOL on a 'frame and Java on new servers - I'm guessing that their 'frame is a mainframe in name only, meaning it is probably a good 10+ years old but is still running CICS on Z, and all that jazz. In its day even a 9370 was a serious machine, but it would have trouble keeping up with a stack of Mac Mini's today.

Re:"Automated"

[TheRaven64]

Since you asked:

JNode is written in Java. Singularity is written in C#. The OS for Burroughs Large Systems mainframes starting with the B5000 is written in a dialect of Algol. House is written in Haskell. SqueakNOS is written in Smalltalk. The name of the OS written in Ocaml temporarily escapes me (look at Cambridge computing web site), but it has the distinction of being the only one to be formally verified. There is a Linux kernel module that allows device drivers in Python, as well as an experimental microkernel that does the same. OPENSTEP wrote device drivers in Objective-C, OS X writes them in Embedded C++, although the core kernel is written in C. MacOS classic was written in a mixture of Pascal and assembly. Symbian is written in C++. All of the Lisp Machines came with an OS and windowing system written entirely in Lisp.

C doesn't let you get close enough to the metal to write an OS. It doesn't include support for any of the privileged mode operations that an OS needs. When you use C in a kernel, you are only using it for the high-level parts. These can be done equally in any high-level language. C is prevalent today for exactly one reason. In the '80s, there were free C compilers that could get good performance on cheap computers. Other languages had expensive compilers, didn't target x86, or had poor performance.

I'm not a fan of the Java/C# approach to operating systems, which ignores all of the safety features in the hardware and tries to use (software-enforced) type safety instead, but Microsoft seems to be pouring a lot of money into it (see Singularity). None of this alters the fact that it is a stupid test. How many software projects are operating systems? When choosing a language, I'd prefer to pick the best tool for the job (this is rarely Java, but it's not very often C either), not the best tool for some completely unrelated job. You're like a carpenter complaining that someone chose to use a jigsaw for the edges of a table because you can't cut down a tree with a jigsaw.

Re:"Automated"

[inline_four]

Doesn't need to be this way. If the automated system works as advertised, then it can be thought of as a simple cross-compiler and the code base can continue to be maintained in COBOL. I can see how this would make sense if they wanted to save money on the hardware.

Re:"Automated"

[moon3]

has device drivers written in Python

I have to clean the coffee off my monitor now!!

From one dead language to another!

[sys.stdout.write]

Okay, Java isn't dead yet. But it should be.

I sense a modest disturbance in the job market...

[fuzzyfuzzyfungus]

As though a few hundred cobol coders cried out in terror, and were suddenly obsolete...

But can it...

[Anonymous Coward]

convert Java to COBOL?

Re:But can it...

[Qcaze]

Sure, you can use the magic invert flag "/usr/bin//cobol2java -i [...]".

Re:I sense a modest disturbance in the job market.

[Anonymous Coward]

A few hundred cobol coders???? I had no idea there were that many left!

Thank the Lords of Cobol

[popo]

BSG humor is mandatory whenever Cobol comes up...

Re:Thank the Lords of Cobol

[Icegryphon]

Lords of Cobol are false deities, there is only one Lord, Ritchie.

Re:I sense a modest disturbance in the job market.

[popo]

Actually that disturbance was all 9 of the world's still-living Cobol coders.

Well, convert it, first.

[Anonymous Coward]

"we could convert of our own application (4 million lines of code) through the tools that we developed"

Well, convert it, first.

Sign of the times

[Anonymous Coward]

Replace something that has a proven track record with something that is a fad.

Whoever the project lead is on this must have supreme bullshitting skills; to be able to convince an entity that has the cash for an IBM/compiled program route to switch to an OSS/interpreted program route.

I can't imagine Linux and Java lasting nearly as long as IBM and COBOL.

Re:Sign of the times

[umghhh]

If you are right there may be a cascade of converters to run and lucrative converters market full of consultants. If things go really ugly the more conversions are done more skills will be needed to find out why converted code malfunctions. These skills could possibly even include cobol just in case one has to look at original to find out ow did it work when it did:)

Re:Sign of the times

[iluvcapra]

An AC writing like an old codger. I think I bought my first Java book in 1995... By this standard of "fad," C was a fad when Windows NT came out.

Yes, but does it run MVS?

[davidwr]

Just asking.

COBOL II

[Anonymous Coward]

I didn't see any references to ALTER statements

I looks like this only supports more recent versions of COBOL II.

Re:I sense a modest disturbance in the job market.

[fermion]

I suspect that someone will still need to fine tune the Java, and that will require an understanding of the original Cobol. Given the undeserved disparaging comments I hear around here on Cobol, Fortran, even C, I suspect the average modern developers feels overwork if they have to deal with anything more complex than Python, not saying anything bad about Python, or, even worse, does not fit into their preferred IDE. I find that if you have a basis in the original computer coding methods, all the new stuff is just a simple walk in the park.

What do transcoders really buy you?

[davidwr]

I'll say what they don't buy you: The ability to throw away the old language.

If changes need to be made - and they will - you will want to change the original language not some intermediate that is stilted and hard to read at best and a candidate for an obscufated insert-language-here contest at worst.

What transcoders do buy you:

The ability to compile code on a platform that doesn't have a compiler for your flavor of your language.

Re:Cobol was crap and JAVA is crap; a marriage

[Anonymous Coward]

Jaava is a current dinosaur.

<Sarcasm>Yes, because Java is an unsupported language and hasn't made any improvements for performance.</Sarcasm> Java is a viable solution in many situations, but like any tool, it should be evaluated against others for a particular situation.

Mij

Per slide 25

[Seakip18]

All it appears to be doing is mapping COBOL line of code to Java Line of code, per Slide 25.

This is more about being able to find someone who can read and write java. The code remains procedural, the COBOL programmers do the same stuff, just in Java now.

Here's an example of the code that was spit out:

sql("SELECT * FROM RS0403 WHERE CDPROJ=#1").into(vrs0403a.dvrs0403a).param(1, tuazone.tua_I_Cdproj)

Not to dissuade, but in someways, they avoided doing a rewrite at all cost.

Great if you want to get off legacy systems, but it's not going to magically improve your code base. GIGO rules still apply.

Re:Per slide 25

[phantomfive]

That would probably be scary, except the original code was like (from slide 26):

MOVE FW-1ER-OCC-AFF TO J
INITIALIZE SW-SEL-SA02

Either way java seems like an improvement. I know in Cobol you can have expressive variables (readability was one of the original selling points of Cobol), so I'm going to guess that they have such weird looking variables on purpose. If you had decently named variables in the Cobol, it stands to reason that you would be able to have readable code as an output from their tools.

Re:Per slide 25

[Alpha830RulZ]

"MOVE FW-1ER-OCC-AFF TO J
INITIALIZE SW-SEL-SA02

Either way java seems like an improvement. "

Yeah,

j = FW-1ER-OCC-AFF;

and

SW-SEL-SA02 = null;

is so much easier to deal with.

COBOL and other old programming environments sucked because they had limited length variable names, and no IDEs to help you keep track of variable names. This forced you to use naming standards to keep track of yourself, of which these names are undoubtedly an example of.

Re:Per slide 25

[Anonymous Coward]

You cannot have decent named variables in Cobol. Not in a program much bigger than hello world.

Why? Because you only have global variables. So, rather than 100 functions each with 10 local variables, you have 1000 global variables. You try to come up with decent names for them. And keep them short, so we don't need to scroll horizontally to read the entire line. You see, the language itself takes a lot of room. Like:

ADD SALES-TAX TO PRICE GIVING RETAIL-PRICE

Usually, making the variables local from a programmer point of view (they are still global from the compiler point of view), is done by prefixing with the function they belong to. Often multiple prefixes, as the example given in the parent post.

Now, Cobol is used (only, basically) for business application. These are big programs, with a lot of checks and calculations (called "business logic"), so the 1000 global variables is probably a bit on the short side.

Maintenance Maintenance Maintenance

[Tablizer]

I generally agree. Perhaps the translated result will "run" at first, but the subject of maintenance cannot be ignored because it's usually the largest cost factor. The generated code is likely to be very verbose and filled with ugly translation artifacts. Machine translators are very literal in their technique to ensure compatibility.

A human translator may use knowledge of the domain or common sense to dump certain idioms or artifacts that are not likely to be necessary any more in the new language. They may take small but rational risks in order to toss some ugly nitty gritty code, for example. Machine translators are not smart enough to evaluate such risks, doing it the long way to "make sure".

One must find a way to read all that machine-generated fluff to make any changes or fixes. This makes maintenance costly and error-prone.

It would be more effective to gradually manually convert one program or module at a time.

Plus, as somebody else pointed out, Java may become a "dead" language also. I've seen about 4 language fad eras in my years in IT. The chance of Java surviving as a non-legacy language is not very big based on past patterns. Thus, one is mostly just converting one legacy language to another.

And Java has some really annoying features that I feel future languages will avoid, including putting type declarations on the left side of statements, keeping C's ugly switch/case syntax, lack of stand-alone functions, and others.
     

Re:Maintenance Maintenance Maintenance

[Maxo-Texas]

I agree with your objections and have seen these problems so many times over the last decade that it is getting hard to believe that someone can't write a decent translator.

Java is usually very easy to refactor (smart editors).

It seems like a two or even three stage pass would work.

Stage one, COBOL to raw java.
Stage two, raw java to better formatted java.
Stage three, better formatted java to even better formatted java.

I wrote an RPG3 to RPG4 converter back in 2000.
It used 5 passes-- each a small simple program.
The result was actually fairly close to procedural java-- if we had decided to go with java, I could have written a 6th program to do that conversion.

Re:Maintenance Maintenance Maintenance

[Tablizer]

I wrote an RPG3 to RPG4 converter back in 2000.

What, did IBM pull a VB6 and make RPG3 code non-migratable to 4?
       

Re:Maintenance Maintenance Maintenance

[Maxo-Texas]

Sort of.

There was a free converter that converted RPGIII to RPGIV if you wanted to have "Rpg3 in Rpg4 format".

But if you wanted improved error handling, files as objects, support for external calls to java, embedded SQL, better transaction control boundaries, you needed to do a more complete conversion.

Re:Maintenance Maintenance Maintenance

[VGPowerlord]

So, in other words... you leveled up your RPG using custom hacks?

I don't know why, but companies like Blizzard hate that!

Re:Maintenance Maintenance Maintenance

[ralphdaugherty]

What, did IBM pull a VB6 and make RPG3 code non-migratable to 4?

      No, they provide a free converter. It's mostly a format change in terms of RPG III code, in other words not rearchitecting to use RPG IV capabilities.

      Why the guy has a five pass converter to do the same thing? Don't know, but I presume to rearchitect to use RPG IV capabilities.

      Also, everything is totally backwards compatible. One program could contain RPG II, RPG III, RPG IV, and RPG /free syntax. It's a hell of a compiler that Toronto Labs keeps adding to without breaking anything.

      While I say this as an extreme example, I would also emphasize that ILE module and service program constructs, subprocedure functions, and /free syntax which resembles any other language is now what we do.

  rd

Re:Maintenance Maintenance Maintenance

[MightyMartian]

I think Java will probably be around for some time to come. It's becoming a pretty major force in embedded devices.

That being said, maybe converting to something like C might guarantee long-term viability.

The King is Dead! Long live the King!

[Anonymous Coward]

What? Someone had to say it.

Serious Question Here

[filesiteguy]

Though I could think of a ton of jokes - and have already seen a few - my first question is, "why."

I can see the possible benefits of no longer relying on aging cobol programmers. I am often dealing with just this issue as I migrate '70's and '80's era systems off off ADABAS and COBOL. However, why would one want to make a one for one class creation of existing mainframe applications. I honestly remember a few programmers I knew doing this right before they retired back in '05. They took a COBOL/IMS application running on an AS390 and turned it into a HTML/ASP.NET application written in C# with IMS and SQL Server on a z890 in virtual MVS and SLES environments. The screens - web based now - were one for one matching with the previous mainframe screens.

My question then too, was why bother?

I just finished a second project in taking a '80's era mainframe application - this one to track the purchase of vital (birth death marriage) records - from mainframe into an n-tier model. Instead of simply copying the mainframe screens we spent time deciding what worked on the mainframe and what didn't. Some of the mainframe concepts - particularly in the public lookup - were fine. They stayed and became web-based applications. Other items were thrown out the window and completely re-worked into a user-friendly and efficient system. (In this case, we used MS .NET 2005 and C#, but we could have just as easily used Java. I'm not trying to say anything about the choice of language or underlying platform.)

Having done a similar project for real property records in '07, we learned many lessons and were able to reuse assemblies in the new application. In fact, the entire UI, security, printing, data encapsulation, image import (there are over 160M TIFF files in our system), reporting and cashiering/finance/cash handling subsystems are identical and shared among both applications.

I can see possibly wanting to utilize some classes for back end work but wouldn't it be better to review these individually and decide what is best?

Oh, and we're saving roughly $3M/year in mainframe costs. :)

(Okay, post finished now to wait for someone to mod me as a troll...)

Re:Serious Question Here

[Seakip18]

I was wondering that too.

My guess is that the business rules behind the application were known by each of the COBOL programmers. They didn't want to ditch the COBOL guys, but could see the age creeping in. So they decided to switch to Java as a compromise between a expensive rewrite that would render the COBOL programmers mostly useless and business as usual. Hey, you get a modern, functional language that is popular and get transition your COBOL guys into the syntax.

I think it will come back to bite them in that they aren't going to magically be able to hire a Java programmer and have them ready to work within the same transition time as, say a truly OOP project would. The code is still the same, just with java syntax. Worse, a new programmer may start to write OOP code in a manner that the COBOL folks don't understand.

Re:Serious Question Here

[Anonymous Coward]

There I modded you troll you dumb bitch. Keep doing the karma martyrdom, and I will keep modding you down.

Re:Serious Question Here

[Anonymous Coward]

you have to lease the mainframe and pay a support contract whether there are problems or not. that's probably why.

in this way, windows is an antidote to mainframes. the "maintenance" costs are much, much cheaper with windows. that doesn't make one better than the other, but that's part of the thinking.

also, hardware failure on obsolete systems can mean a delay waiting to find a part or paying high repair costs if you aren't paying the high monthly support contract cost. again, pc repair has its own problems, but for recently manufactured servers, getting parts is pretty fast (if they aren't out of stock!). with older systems, the part you need may be _rare_ as in not even ebay has it for sale.

Inline documentation?

[Rix]

What happens to the commenting? Won't this turn into an unreadable turd?

Re:Inline documentation?

[rockNme2349]

The fools, if only they had figured out a way to translate the COBOL comments into Java comments. WHEN WILL THEY LEARN?

Re:Inline documentation?

[Anonymous Coward]

The fools, if only they had figured out a way to translate the COBOL comments into Java comments. WHEN WILL THEY LEARN?

I think the point is the positioning (location) and meaning (semantics) of the comments DON'T translate

Re:Inline documentation?

[mevets]

You obviously didn't read the article. They are turning it into java.

Re:Inline documentation?

[onefriedrice]

Why can't the comments just be converted along with the rest of the code?

What about the grey-beards?

[MBCook]

But now what will the poor grey-beards do for a living?

Wont' someone please think of the grey-beards?

Re:What about the grey-beards?

[ralphdaugherty]

But now what will the poor grey-beards do for a living?

      They stated clearly they were migrating the people along with it.

      For the post before yours, they stated clearly they were doing this for the money it saves them to move from a mainframe to PC server farms.

      It's not even really an article to read, just a few bullet points.

  rd

Re:What about the grey-beards?

[TheRaven64]

They're retire, then come back in a year as consultants (making more in a week than they currently do in a year) to help the new programmers make changes to Java code automatically generated from COBOL by a machine, which can only be understood by someone who knows Java, COBOL, and the underlying business logic.

Scary Thot

[Anonymous Coward]

Oh oh, I envision something like:

BEFORE
 
  ADD A TO B GIVING RESULT.
  PRINT RESULT.
 
AFTER
 
  ArithmeticManager am = new math.ArithmeticManager();
  opA = new math.Operand((float) a);
  opB = new math.Operand((float) b);
  am.addOperand(opA);
  am.addOperand(opB);
  am.operator = new math.operators.Addition();
  am.executeMathOperation();
  system.io.output.print(am.mathOperationResult());

Not sure that's a step up.

Re:Scary Thot

[larry bagina]

CobolEngine cobol = new CobolEngine();

cobol.AddLine("ADD A TO B GIVING RESULT");
cobol.AddLine("PRINT RESULT.");

cobol.Compile();
cobol.Execute();

Re:Scary Thot

[VGPowerlord]

I know you were joking, but have you used Java's decimal library before?

BigDecimal opA = new BigDecimal(a);
BigDecimal opB = new BigDecimal(b);
BigDecimal result = opA.add(opB);
System.out.println(result);

Not quite as bad as your fake code, but the difference is... BigDecimal is actually a real class that exists in the Java standard library.

The same code in C#:

decimal result = a + b;

(provided you don't overflow the decimal value)

Re:Scary Thot

[Anonymous Coward]

new math.operators.Addition()?

math.operators.Addition should be static.

Been there, done that.

[Anonymous Coward]

Back around 1997 I worked for a company that did much the same thing: used automated tools to convert gigantic COBOL programs into something that would run on distributed UNIX boxes. (We used ANSI-C as the target language. [Except that JCL was translated to Perl.]) We charged millions of dollars, but it was worth it to our customers. For example, one big utility company had merged with the utilities of a neighboring state, and their mainframe simply wasn't big enough to hold the combined customer data.

The final code was damn ugly, because it was a close translation of the original Cobol. And Cobol control flow has some concepts not easily reproduced in C, so some of the library functions we wrote to handle those were quite bizarre. You'd have a hell of a time adding new functionality in "clean" C, but programmers familiar with Cobol could maintain it.

It was never fully automated (we'd get the contract, then finish customizing the tools to work with whatever flavor of Cobol the particular customer had), but we'd finish a typical engagement in less than a year.

Re:I sense a modest disturbance in the job market.

[mikael_j]

Make that ten, although I've only coded COBOL at home for fun. Yeah, I'm probably some kind of masochist but I really wanted to give the language a spin and see if it was as horrible as people say it is.

/Mikael

First build the automated test suite....

[Big Smirk]

Then convert.

While you are at it, benchmark.

Hmmmm.

[Tablizer]

I hacked into their source code, and found something a little odd:

while (f = getFiles(srcDir)) {
  sendToBangalore(f);
  wait_a_little();
  result = getFromBangalore();
  save(result);
}

A strong evidence...

[dumon]

...that Java is the New COBOL.

Re:A strong evidence...

[Anonymous Coward]

...on Mainframes.

I don't recall seeing COBOL being used on cell phones, DVD players, game consoles, web servers, space shuttles, automobiles, and lots of other places.

Not so fast

[scorp1us]

This will just carry forward and old bugs and give them life a new in a new executing environment, where no one knows what will happen. Seems like makings for several DailyWTFs to me...

Re:I sense a modest disturbance in the job market.

[realeyes]

Actually, a few hundred cobol coders announced their retirement, and a few dozen PHBs cried out in terror.

My question is, "Do you also convert the CICS calls embedded in the code (and possibly 3270 terminal commands?!?) or is there a Java library to interface with CICS?" My experience with converters is that they follow the 90-10 rule, where they do great with 90% of the code, but that's the easiest, and could almost be done with global Find/Replace. The remaining 10% is why the conversion wasn't already done.

Later . . . Jim

No change in the job market

[VampireByte]

This looks like a cute toy that will auto-generate some bloated code. No way big iron financial systems are moving to Java, especially auto-generated Java that will perform like crap and be harder to maintain than the COBOL it replaced.

Re:No change in the job market

[Anonymous Coward]

No way big iron financial systems are moving to Java

Dude... Do you realize that in some countries most of the bank transfers are already done in Java?

Google for the use of Java by Voca in the UK to process 70m+ transactions per day.

They're all going to be consultants

[gr8_phk]

we believe that we succeeded in our project because we clearly demonstrated very early on to the people in place that they would find a new interesting job in the final constellation. That generated their full commitment to the project!

Every person involved can now go out and be a consultant to other companies that want to migrate off their old Cobol codebase.

Is it certified as a conforming COBOL compiler?

[Ungrounded Lightning]

I know there is a certification program to check that a commercial COBOL compiler processes the whole language and produces output code that performs correctly. (Can't recall the name at the moment though I think it was in the US government - perhaps in the DoD.) I'm wondering if this tool has been submitted to that and, if so, whether it passed.

I'd occasionally thought it would be a useful thing to do something similar to this (but with ANSI V2 C++, rather than JAVA, as the target language) - and then get the tool certified. With such a certified tool IT administrators could, with confidence, transcode a COBOL application base into a language with multiple commercial and open compilers a long expected support lifetime, generating native code for virtually all possible targets (from PC clusters to current and future mainframes). If the transcoded output doesn't become excessively opaque and class-dependent it could later be warped into a more native form, should that be desirable.

Perhaps this project will be able to actually do it.

The 1990s called...

[VampireByte]

The 1990s called... they want their "automated convert Xxxx to Java" idea back.

I have automatic translation to machine code

[obarel]

Now I just have to train my staff to read and write machine code, and it's bye bye COBOL forever!

Re:I have automatic translation to machine code

[belmolis]

Ha, you think you're joking, don't you? A friend of mine used to work for the Air Force in one of their less high-tech establishments, a place that did inventory. The software, all locally developed, was written in Fortran. However, changing the source and recompiling was extremely tedious since it meant punching new cards, running them through to compile, then running the result of the first run through to link, then running the linked code, then transferring the output to another machine that could print. So, instead of changing the source, they edited the machine code. (And you wonder why they lost the aliens at Area 51...)

Re:I have automatic translation to machine code

[Glonoinha]

You haven't truly lived until you have opened the binaries to your production application in a hex editor and tweaked them to do what you want.
It's better than sex. Well not better than sex with another person, but better than regular solo sex.

OpenCOBOL on Linux

[Anonymous Coward]

Cobol apps from mainframes easily runs on Linux when you just simply recompile using the free, open source, GPL'ed OpenCobol compiler. I've moved a bunch of old IBM mainframe cobol stuff to Linux with OpenCOBOL and so far, I've run into very few issues, none of which weren't solvable with a minimal amount of code changes.

OpenCOBOL also works great if you have any Oracle Cobol apps (that used the Oracle Pro*Cobol precompiler). I'm in the middle of moving a bunch of Cobol-on-Oracle stuff from an old RS/6000 AIX box to 64-bit Linux right now. I'm using Oracle's free "Oracle Enterprise Linux" which is basically a repackaged RHEL distro, and you can even buy formal support contract from Oracle for OEL. So far everything is working out great. The commodity hardware (HP Proliant DL580) server costs a mere fraction of what a new AIX box of comparable power would've cost, and I'm also benefiting from Oracle's free Virtual Server stuff (Xen-based) so I've got the functional equivalent of IBM's LPAR virtual machine technology going on commodity hardware with 10 times the speed, and 1/10th the hardware cost.

The greybeards will be...

[Anonymous Coward]

...conducting your next annual performance review, beyotch!

Money

[mac1235]

3 millions Euros a year can hire some good Java programmers. Hey Strawberryfrog, you doing anything right now?

COBOL Does Not Support F/OSS, Java Does

[Anonymous Coward]

There are no good open-source COBOL compilers. The GCC COBOL project is dead. TinyCOBOL is very incomplete. Then, the one I like, OpenCOBOL simply transcodes COBOL-85 to C and then compiles the C-code.

The COBOL, i.e. Business, community does not support F/OSS compilers. There is a great deal of money involved in hardware/COBOL systems still.

The main article describes a migration from an IBM/zOS mainframe running COBOL to Linux on Intel hardware. There is no professional-grade COBOL available for Linux so that they must convert to another language. They chose to transcode COBOL into Java.

I don't see anything bad about COBOL, or good about Java here. The issue is closed-standards, and the cost savings of cheaper hardware.

mod parent up!

[spiffmastercow]

This is the point java fanboys never seem to get! The library code is fast because its compiled. The JIT code is still damn slow, and the initial load times are horrendous.

Re:mod parent up!

[BikeHelmet]

The JIT code is actually pretty fast. (especially when Hotspot is running in -server mode, which does some impressive optimization)

It just consumes way too much memory, and starts damn slow. (though still faster than C#, in my experience)

A couple times now I've taken base classes and rewritten them in Java to speed them up. ArrayList? Much too slow for my needs, even with a wrapper class ensurance it allocates in large enough chunks. By rewriting it in Java using Object arrays, I saw 60-100% speedups in the get/add methods, translating into roughly a ~2-4% speedup. (mileage may vary depending on workload)

It was about 20000% faster than a default ArrayList - mind you, by default those things allocate in 6-index chunks, so every 6 objects you add it copies the whole ArrayList to a new one, with 6 more spots available. @_@

There's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good...

Re:mod parent up!

[BikeHelmet]

ensuring it allocates in large enough chunks.*

Yet again I have great desire for an edit button!

Re:mod parent up!

[Anonymous Coward]

ensuring it allocates in large enough chunks.*

Yet again I have great desire for an edit button!

If only you could find a desire for the Preview button and basic proofreading.

Re:mod parent up!

[BikeHelmet]

Why thank you for that insinuation that I'm perfect!

Implying that I would catch all spelling mistakes in the Preview (if I could just find it) is quite the compliment! I'm glad to be so far above all you mere mortals. :)

Re:mod parent up!

[Anonymous Coward]

Why thank you for that insinuation that I'm perfect!

Implying that I would catch all spelling mistakes in the Preview (if I could just find it) is quite the compliment! I'm glad to be so far above all you mere mortals. :)

What is the magical thing about transmitting your post to Slashdot that suddenly makes you more likely to notice errors?

Let's see. My way: Hit Preview. **Proofread**. Notice errors, fix. Submit post.

Now your way: Don't bother with Preview, just submit. Read again (**proofread equivalent**). Notice errors, lament that it's too late to fix. Submit second post to complain about lack of edit function.

Perfection at its finest?

Re:mod parent up!

[BikeHelmet]

At least I'm not a coward!

</petty_insult>

Hey, this guy needs an edit button too!

Re:mod parent up!

[jb_nizet]

mind you, by default those things allocate in 6-index chunks, so every 6 objects you add it copies the whole ArrayList to a new one, with 6 more spots available. @_@

There's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good...

Huh. You might well be the one who doesn't understand what goes on behind the scenes. Just read the source code:

        public void ensureCapacity(int minCapacity) { // ...
                int newCapacity = (oldCapacity * 3)/2 + 1; // ...
        }

It thus allocates half the current size of the list each time the capacity is reached, and not just 6 slots.

Re:mod parent up!

[maraist]

JIT code is slow? Or JITing the code is slow? When I run bench-marks, the average-benchark speed continually gets faster and faster as I increase the number of iterations. This is because the JIT continuously re-assesses basic-blocks to determine if coallesing is worth the expense. This means:
A) code is NOT JIT'd at first, even with -server.. ONLY after a min-number of passes (why JIT initializtion code that'll never run a second time?)
B) book-keeping to determine what to JIT and what not to JIT adds extra overhead for rarely used code
C) Even JIT'd code is continuously evaluated to determine if larger execution-flow-patterns are possible.. So the same code might be JIT'd 50 times, each time being aggregated into larger bundles of contiguous raw assembly

Thus, for short-lived applications, the JIT only provides marginal benefit if not a detriment (which is why the google android's JVM does ZERO JIT, and instead uses an alternate byte-code which is more efficient to cold-start).

But, for servers (web-servers and mainframe code which will batch process all night long), you're talking about relatively small chunks of code (out of the overall loaded library) that are highly reused. It's entirely possible that an entire web-page can be inlined into a single chunk of assembly (though it's a stretch). Not even PHP can do this (at present).

Basically typical code is complex because of optional flow-paths (if-statements, etc).. But in highly repetitive batch/server processing, there are a handful of paths which make up maybe 99% of execution, and thus can be rewritten in a way that in C would be horrendous (though certainly possible).

Doing code-analysis to prove that an array index will never be out of bounds is expensive.. But once done, you can remove a lot implicit assembly-code. So general-purpose 3'rd party code can be almost fully optimized away. You get the best of both worlds.. High-degree of defensive coding + optimized execution. The cost is the ramp-up-time (and an immodest but reasonable memory foot-print).

For single-app-servers, throwing 2 gig of RAM is NOTHING ($100 v.s. $5,000 ???), so I'm frustrated when I hear people bitch about memory consumption.. Memory use is bounded, if not, then you have a coded memory-leak and that's not the JVM's fault (usually due to misconfigured-as-unlimited in-mem caching - usually a disk-spill-over-caches that unknowingly (to the coder) retains headers in-mem).

Re:mod parent up!

[maraist]

"It just consumes way too much memory, and starts damn slow."

Sigh. I've said this 100 times.. server apps (as relevant to this COBOL discussion) don't have startup time. They are up for months at at time (years even). Please distinguish between client-side apps and server-side apps.. As java-programming only exists in client-side-apps these days as server-interfaces (for fast-to-build, yet bug-free coding of mission-critical-apps) and cell-phone-apps (for hardware-portability). For this class of client-side apps, yes you can bitch about memory usage and startup time. Though hopefully memory usage shouldn't exceed 150Meg (a typical firefox executable). Server-apps, on the other hand have completely different requirements.

A 'server' that runs java costs between $900 to $10,000. What is the cost of 2Gig of memory? $100? $200? Give me a break. Further, I usually recommend only using the 32bit JVM and thus <= 2Gig of JVM memory (typically caping out at 1Gig). Thus the worst stop-the-world GC-collection time is on the order of 1 second. This pause sacrifice gives you better overall throughput. There are server-app types that require 16, 32, 64 or 128Gig of RAM however, and thus you need the 64bit JVM (64bit pointers increase mem-overhead and cache-coherence) and can't risk the nearly-a-minute pause-times, so you need incremental collectors (with an additional 15% performance loss). But for this, I usually say that such large memory foot-prints are best handled by consolidated network-APIs. This allows you to cluster the apps on smaller, cheaper hardware, and then have a pair of larger-memory hardware on the back-end. But at this point, is the back-end really any different than a traditional large-mem database (such as mysql-INNODB or mysql-cluster/NDB or memcached)?

And as for:
  "here's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good..."

If you're writing server-code (for targeted $10k hardware clusters), I should hope you're not paying somebody straight out of high-school. Or at least have coding-standard and code-reviews with senior staff.

Otherwise, code to google-apps and run a castraded java-api that doesn't really let you waste resources and doesn't have startup-time issues. Actually, it's a pretty good segway for server-freshmen.

Re:I sense a modest disturbance in the job market.

[Anonymous Coward]

Always 2 there are. --Yoda

Re:I sense a modest disturbance in the job market.

[caluml]

And was it?
I don't even think I've seen any COBOL. Is it more obtuse than Erlang looks?

Re:I sense a modest disturbance in the job market.

[mikael_j]

I'd have to say that I've seen worse languages (x86 asm, I'm looking at you) but it sure wasn't pretty.

/Mikael

Re:I sense a modest disturbance in the job market.

[nurb432]

Nope, we do not fear the dark side for we have seen the light. ( of course that light came from a 3270 in a dark basement 20 years ago... )

Programmer's Cut

[Nom du Keyboard]

"We save 3 millions euros / year after this migration!"

And what cut of this savings have your given your programmers who have made it all possible?

Re:Programmer's Cut

[kenh]

Aside from their paychecks? Why should they get any more than that? Optimizing the environment at all scales $3M/year or $300/year is the job of a good employee. If the people that did this didn't draw a salary but instead asked for a cut of the year-over-year savings then fine, but I suspect they drew a salaey for the conversion.

Cheaper Programmers

[nurb432]

And they will get what they pay for..

I just hope its not my bank that tries to go that route.

We did this with a bunch of pascal code

[mzs]

We used p2c to migrate a bunch of pascal code to C many years ago. It was not perfect, but not that bad. You got pretty good at figuring-out the likely places that screwed-up. Also save for the with statements in pascal being translated to accesses to structures, it made relatively readable C.

Re:We did this with a bunch of pascal code

[MightyMartian]

Well, to be honest, Pascal and C are similar enough in key respects that translation isn't a big deal. Moving from a procedural language like Cobol to an OOP language like Java is a bit more daunting. Mind you, C++ started out simply as a translater to C with some optimizations, so maybe this problem has been dealt with before.

Re:We did this with a bunch of pascal code

[mzs]

Though it looks from the slides that they did in fact translate line by line and did not use any of the object oriented features of java. That would have been like the opposite of another project I was involved in. I wrote a bunch of python code. later it was deemed that perl was known by more of the devs so I would need to translate that to perl. The python code used classes so I translated that by hand into a subset of python that was very procedural. Then I wrote a python script that translated that into perl. And then I cleaned that perl up in places by hand to make it look like perl code a perl programmer would write. That was an annoying project.

java's performance depends heavilly on application

[petermgreen]

I would contend that well written java that has been jited is probablly a bit slower than well written code in a native compiled language but there isn't that much in it and it's hard to compare because the "best" coding methods in the languages are not the same.

However it does have high memory use because of the fact that jited code can't be shared between instances, the large bloat of the standard library, the limited availibility of efficiant data structures (all object types are object references) and the fact that the java garbage collectors don't realease memory back to the OS. This means that if a java app gets swapped out it takes a lot longer to swap back in. It also takes a while to start and get up to full performance, especially if it's the first time a java app has been run this OS session.

In summary on the desktop (where startup and swapin times matter) java is slow, on the server not so much.

AnonymousCoward

[Anonymous Coward]

I can't think of a way to automate a procedural thingie to a OO thing.

i work in a place where Cobol developers were sne t to a fast "java school", came 3 weeks after and were supposed to write java. Sure they did. It was procedural Java. And theri programs requested huge CPU load to work.
In the end, one year after, all the code the had written was erased, the app completely re-thought.

Same thing here : for a time it's good, the app is working.
But it will not only need a smart " multi-pass pretty-formatter". The app will require proper OO conception FIRST, and the sooner the cheaper.

The 3M$ are a short sighted benefit.
In the long run _provided the application si supposed to continue to live_ (to be exact : if the needs it covers still exists and cannot be done elsewhere), it will reveal more expensive.

Re:I sense a modest disturbance in the job market.

[plopez]

The reason you haven't seen COBOL is that most of it masquerades as JAVA or C# these days. Such are programmers skills (or 5kilz?) these days.

Re:I sense a modest disturbance in the job market.

[Anonymous Coward]

Silly rabbit. CICS are for kids.

COBOL is self-documenting.

[CouteauTM]

One of the design goals for COBOL was to make it possible for non-programmers such as supervisors, managers and users, to read and understand COBOL code. Wonder if the converted codes generate comments from the code ....

Three Million Euros!?

[kenh]

Holy cow, exactly what was the environment they had that cost $3M Euros/year more than the hand full of Linux boxes they replaced it with?

They could have had a collection of mainframes for $3M Euros, they were vastly under-used if they had that much in savings locked up in that environment.

Their code matches line for line, so they have the most basic of Java code in place of the COBOL code (it likely looks very similar to COBOL code) I guess.

As for the transcoding effort, they could also have fired up any one of several alternative environments that could support the COBOL natively without making some Frankenstein-like Java code...

Re:I sense a modest disturbance in the job market.

[Heir Of The Mess]

As though a few hundred cobol coders cried out in terror, and were suddenly obsolete

No its the other way round. Now we can get rid of all these useless Java programmer, use our Cobol programmers who know what they are doing, and then convert their code to Java so that the PHBs who've been sold on Java can be happy.

Re:java's performance depends heavilly on applicat

[cstdenis]

I've never understood why the bloated standard library needs to make Java so slow to load.

You need to import every class you use -- it should only be loading the classes (or packages depending on how you import) that you need.

while this is nice....

[sulfide]

what is their solution to a> making cobol programmers java developers or b> renting new java developers and having them understand the codebase quick enough to make emergency changes to the code when all is said and done. Either way migration is still a monumental task.

Someone wrote a COBOL to JAVA compiler

[kpoole55]

Now you have a situation where you need someone who not only understand COBOL but JAVA as well. Most of the code will likely translate pretty easily but there are going to be some things that won't work the way they figured. I remember a little bit of COBOL I was involved in while on a work term at university and someone had used an odd assignment to prune the first few characters from a long string. I warned them at the time that the assignment was iffy and a different compiler could produce a result they wouldn't expect but they dismissed it. Now, what will happen when these sorts of odd assignments are passed through a COBOL to Java translator? That's where you end up needing someone who can work with both languages.

That's terrible

[Max Littlemore]

I propose a fix:

while (f = getFiles(srcDir)) {
sendToBangalore(f);
wait_a_little();
try {
result = getFromBangalore();
} catch (BangalorePedantryOnSpecException ex) {
phoneBangalore();
} finally {
result = doLocally(f);
}
save(result);
}

Re:That's terrible

[Anonymous Coward]

Your C won't even compile.

Re:I sense a modest disturbance in the job market.

[drolli]

Hey, i based my future plans on learning Cobol and translating it to some of the more modern languges i know.

Re:I sense a modest disturbance in the job market.

[drolli]

Yes. Automated tools work iff

a) no external library dependences
b) programmers stuck to a good style.
c) the languages are well-suited to be translated into each other (otherwise the code may be unmaintainable)

and a rewrite of your program every 30 years may save even more future maintainance, because i do not believe that the software will takes the old code *and* split it into classes/sort it to patterns in the same way an (intelligent?) human programmer would. So what you may get is java Code, but very different from the normal java style. I cite from the linked article:

-------
strongly object-oriented architecture of resulting Java objects in order to maximize the effect of all controls done by compiler. As example, each old COBOL programs becomes a Java class whose existence is checked at compile-time by rather than at runtime. Very useful when your application is 4 millions lines of code like ours and when you want to track down every typing mistake in a continuous integration architecture like ours
------

A whole old program is converted into a class? Sounds directly like from a design pattern book.

-----
pre-allocation of all program variable structures (COMMAREA of COBOL) to further improve performances but also to minimize garbage collection that freezes the system while running.
-----

This sounds like a really funny way of saying: sorry guys, we *had* some performance problem, which we fixed by a workaround to get it working.... No, we dont have anny memory leaks/allocation times. We just allocate everything the program may ever need.

----
many levels of cache to maximize performances of the new Java version of the old application. Through them, our Java-transcoded transactions and batches have better performances than their Cobol ancestors used to have on mainframe.
----

Do they want so say, that the performance was inacceptable when turning caches off?

Re:java's performance depends heavilly on applicat

[en.ABCD]

Even better: that "import" statement just tells the compiler how to resolve names: All names in the output .class file are fully qualified, and only the classes actually referenced by the code need be loaded. If you have an import statement that isn't used, or that pulls too much; it becomes irrelevant at runtime. Also, you don't actually have to import any classes; you may refer to them by their fully qualified names, and the exact same .class file is output either way.

Re:I sense a modest disturbance in the job market.

[vbraga]

A snippet from Wikipedia COBOL article:

MULTIPLY B BY B GIVING B-SQUARED.
MULTIPLY 4 BY A GIVING FOUR-A.
MULTIPLY FOUR-A BY C GIVING FOUR-A-C.
SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1.
COMPUTE RESULT-2 = RESULT-1 ** .5.
SUBTRACT B FROM RESULT-2 GIVING NUMERATOR.
MULTIPLY 2 BY A GIVING DENOMINATOR.
DIVIDE NUMERATOR BY DENOMINATOR GIVING X.

Not pretty.

Re:I sense a modest disturbance in the job market.

[Alpha830RulZ]

Well, with all due respect to wikipedia, in your snippet much of the ugliness is due to (probably intentionally) stupidly named variables. No intelligent developer, of which there are still many in the world, would do anything like naming a variable FOUR-A-C.

In python: this_var = that_var * 5

in COBOL: COMPUTE THIS_VAR = THAT_VAR * 5.

It's verbose, but it's not hugely different, though less feature rich than any modern OOPy language with rich object libs. I work with a bunch of folks for whom COBOL is one of the languages we work with, which also include java, python, perl, C#, etc. When you're a pro, you work with what the environment calls for. If the environment is mainframe, COBOL is one of the tools you need to use. As is that other paradigm of programming excellence, JCL.

Re:I sense a modest disturbance in the job market.

[Anonymous Coward]

x86 asm ain't so bad, try reading about the formatting of the actual compiled machine code opcodes sometimes. That's painful! bits all over the place ...

Re:I sense a modest disturbance in the job market.

[Glonoinha]

It's also quite straightforward and simple. And it does pretty much exactly what it looks like it does.

And it doesn't suffer from rounding issues, dropping pennies from a twenty page business ledger due to the inherent issues in representing fractions in binary.

Disclaimer - I don't actually code in the language, and I will deny knowing about the language if anybody actually tries to force me to program in it.

Maintainable output

[Anonymous Coward]

This is utter baloney. The idea of creating 'maintainable' Java from COBOL is a Joke - right? How do you deal with GOTO statements and have them work in a non-obfuscated way?

There is a big market for moving from Cobol to something else, but pretending you end up with anything maintainable is marketing spin.

Cobol is a big, horrible language with many obscure constructs. It will always be translated into equivalently big, horrible, obscure code - in whatever language it goes to.

Cool

[guliverk]

Cool thing but I think the best language is that language which you known best

Java is for non-hackers

[jonaskoelker]

Java is a perfectly acceptable programming language in many circumstances.

Such as when your programmers aren't really great :p

From http://www.paulgraham.com/gh.html

Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero.

Re:Java is for non-hackers

[quanticle]

I guess it just goes to show that Paul Graham doesn't know very many great programmers. Either that, or his definition of 'great' is screwed up.

Great programmers use the right tool for the job. Whether that tool is Lisp, Python, Java, or even COBOL doesn't matter. The way I see it, Mr. Graham's constant advocacy of Lisp as the be-all and end-all of programming environments is no better than any other language zealotry. Yes, Lisp has its place. So does Java. A truly great programmer would have the task dictate the language, not the other way around.

Re:Java is for non-hackers

[Anonymous Coward]

Spoken like a true idiot who let's his task control him and not the other way around. No nothing kids...

Re:Java is for non-hackers

[kbrasee]

Spoken like a true idiot who let's his task control him and not the other way around.

I have a feeling that you don't work in the real world.

No nothing kids...

Priceless.

Re:Java is for non-hackers

[kumanopuusan]

I think the one great programmer he's talking about is Guy L Steele. (That was supposed to be obvious, though, right?) If your definition of "great programmer" doesn't describe Guy L Steele, maybe it isn't a good definition ;-)

If you'd read much of what Paul Graham has written, or much of the literature on Lisp, or even functional languages in general, you'd know that no-one is advocating using Lisp all the time. One of the almost-magical things about Lisp is how easy it is to make domain specific languages that truly are suited to the task at hand.

You are certainly correct that a great programmer uses the right tool for the job. This includes knowing when the right tool for the job doesn't exist yet, and judging the costs and benefits of writing a tool perfectly suited to the task at hand.

Why not just compile for .Net?

[Anonymous Coward]

Didn't Fujitsu make a .Net compiler for COBOL? Then it would run any where Mono runs...

Re:I sense a modest disturbance in the job market.

[ADT7]

Yes, but in that same article, just above that, it has the same code written as:

 

COMPUTE X1 = (-B + SQRT(B ** 2 - (4 * A * C))) / (2 * A)
COMPUTE X2 = (-B - SQRT(B ** 2 - (4 * A * C))) / (2 * A)

Not quite true...

[CrazyBusError]

"There is no professional-grade COBOL available for Linux so that they must convert to another language"

I think Microfocus might disagree with you there. It's not cheap, but it's definitely used at enterprise level.

Readability of generated Java code

[ciaran.mchale]

Some people have expressed scepticism about the readability and maintainability of the generated Java code. That's a simple concern to deal with. Just run the generated Java code though a Java-to-Perl translator. Then there won't be any question at all about its level of readability and maintainability.

Proving yet again...

[RedMage]

Proving yet again that you can write COBOL in any language.

Seriously tho, the resulting code can't be all that great for a true Java programmer to maintain after the conversion - at its heart it would still be organized in a non-OOP (procedural) manner, which would certainly require some cross-thinking.

Re:Proving yet again...

[Hognoxious]

I've only dabbled in Java a bit, but I'd imagine using an OO language in a procedural style would be the worst of both worlds.

Re:I sense a modest disturbance in the job market.

[Hognoxious]

No intelligent developer, of which there are still many in the world, would do anything like naming a variable FOUR-A-C.

COBOL shops tend to have odd coding conventions including, from what I've seen, no variable names less than 40 characters.

Re:I sense a modest disturbance in the job market.

[Alpha830RulZ]

Yeah, they do. It stems from the essentially primitive dev environments, where you don't have an IDE to help you figure out what's going on with variables. Most mature organizations created variable naming standards to help with maintainability.

I have to say, though, based on the Java and .NET shops I've worked with, lengthy variable names are hardly limited to COBOL. Eg.,

result += positivesAtCurrentScore * negativesBelowCurrentScore

from a code snippet at my current employer.

Programmers vs Typists

[Anonymous Coward]

Cobol programmers are few and far between, they are expensive, and can charge huge rates.

Java programmers are a dime a dozen. Many will work for free, just to get their name out there.

Cobol to java conversion is fine, but the program will need some re-factoring, basically cut-copy-paste, and maybe some manual typing, just the type of stuff java programmers are best suited for.