Automated Migration From Cobol To Java On Linux 195
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!"
Re:"Automated" (Score:1, Informative)
Troll more. [slashdot.org]
Re:"Automated" (Score:4, Informative)
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
OpenCOBOL on Linux (Score:1, Informative)
Cobol apps from mainframes easily runs on Linux when you just simply recompile using the free, open source, GPL'ed OpenCobol [opencobol.org] 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.
Re:mod parent up! (Score:4, Informative)
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:"Automated" (Score:3, Informative)
...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" (Score:2, Informative)
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:
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 [c2.com] 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:mod parent up! (Score:3, Informative)
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! (Score:3, Informative)
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.