Open Source

Apache pulls out of Java Community Process

Jack Wallen helps you to masticate on the situation that continues to brew within the bowels of Oracle. Will the most recent mis-step of Oracle lead to catastrophe? Read on fellow travelers...read on.

Oracle, oh Oracle...how you've already placed your kiss-of-death lips on so many good products and people. Just about every media type around the globe predicted how you would cause everything you touch to wither away and die. It looks like those predictions were all dead on.

First there was OpenOffice. Your poor handling of that flagship open source office suite caused the Document Foundation to be formed and LibreOffice to be created. Soon after that distributions started announcing that LibreOffice would take the place of OpenOffice as the default office suite. It will only be a matter of time before OpenOffice is just a milestone in a timeline with an all-too-obvious end point where continued growth and acceptance should have been.

And now you, oh great Oracle, have been pushing around the big boys. The first rumblings started back in November 2010 when a conflict of interest arose between the Apache Foundation and Oracle over the Apache Harmony Project. Harmony is an open source implementation of the Java runtime environment. Apache had been a part of the Java Community Process after Sun invited them to participate in 2007. At that time Sun agreed to allow Apache to license Harmony.

But there was little harmony with Sun, once they were purchased by Oracle. On November 9, 2010 the Apache Foundation released this statement:

"The ASF will terminate its relationship with the JCP if our rights as implementers of Java specifications are not upheld by the JCP Executive Committee to the limits of the EC's ability,"

And that, my friends, is exactly what has happened. On December 10, 2010 the Apache Foundation has removed itself from the JCP thanks, in full, to Oracle not upholding the agreement Apache had with Sun regarding Harmony. But what, exactly, does this mean? What will happen?

Ultimately - not much. I believe that the Apache Foundation will get around this and will be able to continue on with Harmony. But the truth of the matter is (and some will disagree with me here), Java needs to die. Java never lived up to it's promises nor has it ever worked very well. On Linux it's been nothing short of a horrendous challenge for most end users to even use.

Java was first released in 1995. After over fifteen years, you would have thought the technology to have evolved to meet the needs of the modern user. It never has. It's slow, buggy, not nearly as compatible as it promised, and now ruled by an overlord who seems to want to bite off the hand that would be feeding it.

But really what is the smoking gun here is that Oracle is proving that it only wants to take its toys from the playground and go home. Java was released under the GPL, yet Oracle is going to sue anyone who tries to re-implement. What is really ironic about this is that Oracle describes itself as the "steward of Java technology with a relentless commitment to fostering a community of participation and transparency".

Relentless commitment to fostering a community of participation and transparency? Really? I don't follow this, as Oracle has been the polar opposite of what it claims to be. Oracle is doing nothing but fostering enemies within the open source community which will eventually lead to its timely demise.

Oracle - if I could teach you one thing it would be this:

Open source, and the open source community, could have been your best friend. You could have fostered a relationship with an entire community by following through with that claim you made and being a true steward of community. You had the opportunity to really rise up and help the open source community continue to push forward, which in turn would have held tremendous gains for you. But you did none of this. You failed the open source community again and again.

This time you've pushed around the wrong community. Apache is, by far, one of the strongest of all the open source "sub-communities" and by pushing them around you may as well have signed your own death certificate. The biggest concern? Who will own all of the IP when Oracle folds? Let that sink in for a moment and see if your skin doesn't crawl.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

60 comments
oldbaritone
oldbaritone

Java's goal was to be platform-independent. Java apps were supposed to run on all brands, all processors, all architectures and all operating systems. Sure, it's debatable how well that goal was accomplished, but what brand-independent alternative is there for the client-side?

apotheon
apotheon

It occurs to me that it was not Apache that pulled out of the Java community. It was Oracle -- and, because Oracle "owns" the Java "ball", the game is over. The community's pretty much shot, at this point. Might as well just play taps and call it a night.

jkc7297
jkc7297

Time for Google to step up and develop a new language that can match up to Java. Java is good language but we can use some new free language with better new internal deisgn and RIA. With some many good/smart eningeers there, I bet you Goolge can do it in a day :)

mwclarke1
mwclarke1

I wish it were dead already. most java based apps are either slow, require a specific, newer, older java version, some will not work if a another version exists on the system, etc. Not sure if bad app coding and/or java itself but needs to go away.

kitico
kitico

Sometimes it helps to read your own writing as if you did not live in your own skin. That would have been a helpful trick to use with this offering. Consider your question : "Will this latest issue with Oracle prove to be fatal?" Do you mean to ask if conflict with Oracle will be fatal to Apache, Java, or Oracle? All three? What is your question, really? There are a few instances where your meaning is not clear, but most of the time you are just guilty of wordiness. Eliminate words for greater impact and clarity.

logicbit
logicbit

Oracle never planned to be a steward of the open source community. In fact neither did Sun at first. Sun has always seen its self as a hardware vendor not a hardware and software vendor. That is the only reason Java was available for free and adopted. Software was the red headed step child. Sun is gone now primarily because they didn't know how to grow their business around both the hardware and software they produced. Even though the corporate culture at Sun was similar to Apple, Sun's attitude towards Java wasn't what everyone outside of Sun thinks. Sun just had the wrong chiefs at the helm. Sun was no Apple. They lacked vision and clarity of purpose in my opinion. Sun is gone and now Oracle is holding the reins. The reality is Oracle isn't going anywhere. Oracle isn't going to fail because Apache is no longer a member and participant in the JCP. Only the JCP and Java community will suffer while Oracle continues to miss step. In my opinion Apache did the right thing. Frank Rivera CEO HoudiniESQ http://HoudiniESQ.com and former Sun SOftware Architect

codepoke
codepoke

Jack, your opinions are frequently beyond the pale, but this one is irreconcilable. Linux is a nice tool. We use it profitably and will increase our use, but your fanboy zeal for it takes you down some weird roads. Take away Java and how many of our Linux servers would go away? 100% Take away Java and we are a 100% Microsoft shop. And here I thought you were pro-Linux.

daboochmeister
daboochmeister

Jack, come ON, Java is a HUGE success on so many fronts. No, it didn't become the desktop thick-client application development language of choice ... but when you look at the amount of usage on servers, in the form of J2EE (sorry, JEE), and when you consider how important it is in the research community, etc. etc. ... I sincerely hope that when you say Java needs to die, you mean like a phoenix.

sabreeblackmon
sabreeblackmon

On the web side, there's Ruby and PHP. Ruby on Rails and Zend Framework for PHP work very well for enterprise sites. They are both stable and well tested and there are a great number of development tools available that support them. Since PHP and Ruby are both object oriented and have decent sized built in libraries, unit testing, etc, it can be a fairly simple transition. There's also the lack of licensing issues here. Java is still used for web applets that need to interact with the OS, but the use case for this is getting smaller. On the desktop side, I'd argue that a C++ application written with either Qt or wxWidgets libraries is more platform independent than a Java desktop application. Very little to no code changes are required to support multiple OS's with either library, and since the software can be distributed with the proper libraries, one doesn't need to worry about JVM versions or big downloads from the web. With simple recompiles, you can support most OS's in use. Of course there's also C# .NET applications for desktop, web and web/desktop integration (Silverlight). Mono has come quite the long way and a growing number of major companies like EA are using it in their server backends, so I can only see Mono maturing further from here. As far as the embedded world goes, most lower level development (firmware, drivers) still is done primarily in C and sometimes C++. Embedded applications though, with the increasing use of x86 and 32-bit processors in smaller devices, higher level OS's like Linux are on an increase and so are higher levels applications. This opens up the playing field to not only Java, but any other language the developers want to use (C++, Objective-C, etc), so I predict this field becoming even more competitive, not less.

apotheon
apotheon

There are other options that provide a similar technical basis for that kind of portability. For instance, Objective Caml can be compiled to bytecode and run on the OCaml VM, and actually outdoes Java in the portability department on the issue of licensing annoyances. Erlang's VM is rapidly approaching the same kind of suitability to writing software to be bytecode compiled and run anywhere the VM runs, too. Languages that target the .NET and Mono runtimes have the potential to achieve the same portability, and if you believe that the Microsoft origins of the CLR will not come back to bite Mono, it's effectively brand independent. Meanwhile, if all we're talking about is the *language*, and not the language's *implementation* per se, pretty much every single additional language that targets the JVM as its platform has the potential to replace Java itself, if we just ignore nontechnical issues and languages that just outright suck. JavaScript has the possibility to become a suitable replacement, in time. Its use is getting more prevalent for server-side code, and once that becomes widespread enough I think we'll start seeing it become more prevalent on for "thick client" applications (outside of the browser), too. These are all languages that run on at least one VM via bytecode compilation such that they provide essentially the same portability potential enjoyed by the JVM, in some respects even beats it because they offer fewer legal hurdles for wide deployment.

Brainstorms
Brainstorms

Tcl/Tk. Installed by default on virtually all Linux distros, available for Mac & Windows, good cross-platform compatibility, etc. Surf over to ActiveState for interpreters, IDEs, dev kits, et al...

Slayer_
Slayer_

Right now it seems every OO language designed to use as much memory with as little effort as possible. In 20 years, you will be able to code the logic for a chess game with just Play CHESS As the only line of code. And it will require 600TB of support files and 90ZB of RAM to run.

spearson@8herons.com
spearson@8herons.com

I think bad coding is the root of a lot of those problems. I remember one Java program some years back that checked for a specific version, and would not even work with a newer point release. Had to have 1.4.3, refused to run with 1.4.4 or higher or with anything lower. It popped up a box that said "wrong java version" and refused to run. I can understand reasons for not allowing a lower version, but why the developers thought it wouldn't run on 1.4.4 or better I don't know, unless they were exploiting a particular bug they knew would get fixed??? Which is bad coding, in my book.

tkeller
tkeller

Oracle bad. OpenOffice withering. Sad. LibreOffice ascending. Yay. Apache Foundation upset. Java disappointing. Need fix or die. Oracle? Get head out of ***, or get out of way. Bad Oracle! Bad Oracle! Intellectual property nightmare looms.

Sagax-
Sagax-

Ruby and Python (to name two possibles) have continued to mature. They do each have their own strengths and weaknesses, but still seem competent. Question - will this dust up over Java encourage more attention to other programming languages?

apotheon
apotheon

I have yet to deploy a Linux-based server that actually had Java installed on it, and I've deployed a fair number of servers. In fact, aside from "enterprisey" nonsense like WebSphere and J2EE, there's very little in the world of open source Unix-like server OSes that requires Java, and for most of that, there are quite suitable alternatives that do not use Java. Java on Linux-based servers is the exception, and not the rule.

Neon Samurai
Neon Samurai

What part of a Linux distro based servers requires Java? Is it Java written hosted apps or some such?

Justin James
Justin James

I could not agree more with the previous poster. Jack has really mangled the truth on Java. Everyone who knows me and my writing knows that I'm not a Java guy, and that I disagree with a lot of the decisions around it. But I can be honest about it and I am aware of the facts of it, which is more than I can say for Jack's depiction of it: "Java was first released in 1995. After over fifteen years, you would have thought the technology to have evolved to meet the needs of the modern user. It never has. It?s slow, buggy, not nearly as compatible as it promised, and now ruled by an overlord who seems to want to bite off the hand that would be feeding it." The only accurate statements are the first (when it was released) and the last (about being ruled by an overlord). Now, some of these statements have a basis in reality. For example, Java *was* slow, but it is not slow anymore (the same can be said for .NET, incidentally). As the previous poster has pointed out, Java is quite a success... just not in the capacity it was originally billed for (thick client development). Even the portability issues are sorted out for the most part. I can give credit where credit is due. More importantly, I am willing to re-examine my beliefs from time to time and revise them as the facts change. It's time that Jack does the same with regards to Java. Fact is, Java is so entrenched in enterprise development, I've heard a number of people describe it as "the modern COBOL". It isn't going anywhere. J.Ja

Justin James
Justin James

So in 20 years, OO languages will simply host Emacs? ;) J.Ja

Spitfire_Sysop
Spitfire_Sysop

Isn't that called Windows 95? Seriously, what you are talking about sounds more like a shortcut icon than a programming language. It wasn't quite 600TB but it could play a game of chess in one command.

Justin James
Justin James

What happens is that developers write the app using whatever JVM they are using, and they know it works. They don't test it on older JVMs for a variety of reasons (lack of time, lack of resources, no automated testing setup, laziness, incompetence, etc.), so they just state that the JVM they developed on is the minimum version. You see the same thing with installers that ask for a reboot, the person who wrote the installer wasn't sure if the things they did would require a reboot or not, so they flag it to ask for one anyways... even though its something trivial like a text editor. J.Ja

Kim SJ
Kim SJ

Yup, that pretty much summarises my views on the matter. :-)

Justin James
Justin James

This is another one of Jack's mistakes in this article: he assumes that everyone cares about open source as a cause as much as he does. Most Java development is happening in big, corporate shops. They could not care less about the politics of open source, so long as it doesn't interfere with their ability to get what they want and need. J.Ja

eclypse
eclypse

that if you don't have Java, there will be nothing for Linux servers to run. I would probably lose a few servers to M$ if it weren't for Java letting me run these apps on Linux or AIX where _I_ want them, not where someone else wants them. I'm not a huge fan of the memory requirements of Java and its applications (at least the ones we use), but it does allow me to put things where I want (AIX or Linux) instead of the only thing that would otherwise be available (Windows).

apotheon
apotheon

The line "write once, run nowhere" still has some traction when it comes to Java. All too often, I see people claiming Java portability when their experience with it is largely restricted to the most common uses on the most common platform. MS Windows binaries tend to be maintained and updated; hopefully the software you use with the JVM runs on the version of the JVM you have installed. Other platform binaries are not always so well maintained, unfortunately. Even when they are, they often suffer other problems such as licensing hurdles (try installing the official JVM on FreeBSD, for instance) and technical hurdles (including nonstandard path assumptions on Linux distributions for which distro-tailored installers are not available). The truth of the matter is that in some respects C is much more portable than Java; sure, a given binary may not be as portable as a given JAR, but the source might be more portable, and there is no problem with VM availability when you're just running a binary. Stepping just slightly outside the mainstream can have disastrous effects on the apparent portability of Java. Much of the hype is just hype.

edxxx
edxxx

Java is the new Cobol? Really? But, didn't COBOL pretty much die?

Brainstorms
Brainstorms

In some ways, it's the "best kept secret" in the software world, although it has quite an active community -- committees that guide its development, yearly conventions, papers published, on-going improvements such as object-oriented frameworks, tight integration with SQLite, multi-threading, co-routines, etc. I'm segueing from testing to now writing Tcl for my project. I'm still amazed at what this "interpreted language" can do, and not just performance-wise. I like its ability to hook into things at the 'system' level to control other code, and that you can easily call C code from Tcl or call Tcl from C code, whichever is more effective. It also has quite an array of system & process control features. One of the most intriguing aspects about it, for me, is the dynamic typing and the fact that it's interpreted. That lets you do interesting things like building scripts in real-time and have them execute. You can literally add mods to your code as its running...

apotheon
apotheon

Evidently, Tcl has come a little farther than I remembered.

Brainstorms
Brainstorms

Prior to v8.0, performance was an issue... Now it's optimized, it bytecode compiles, and there's good support for linking to C/C++ routines for performance-critical things. It's reasonably fast for most things, and does well in some unexpected areas, too. We use it to produce real-time military simulation systems for training & analysis purposes (not first-person shooters, though). Aside from good performance, there are many characteristics in terms of support, compatibility, tools, flexibility, etc. that recommend it. Take a look at http://www.tcl.tk/ and http://wiki.tcl.tk/ for more info...

apotheon
apotheon

I mistook your meaning at first. This is the edited version: It's not bad. I wouldn't put it up against C, though, and for long-running server processes an optimizing VM like Java's will often outperform it. I'm more concerned with its suitability for many types of projects, however. I think Objective Caml is a much better choice. We just need some enterprising individuals to implement a (copyfree licensed) bootstrapped (i.e. written in OCaml) implementation that at least reaches major feature parity with the current reference implementation.

daboochmeister
daboochmeister

Emacs will host all OO langs :-) ... because after all Lisp is the language God used to speak the world into existence ... In year 21, they'll add a COBOL module, and all the support issues will go away.

spearson@8herons.com
spearson@8herons.com

...it was a smaller outfit that wrote it and it was specialty software for a medical establishment. Cover themselves and also push the clinic to update to a newer version -- which the clinic wasn't going to do in this case due to funding issues.

apotheon
apotheon

From what I've seen, Java point releases can break things. They may be trying to cover their fourth points of contact by saying they don't certify their software for newer JVM versions. There's also the simple fact that a lot of distributors of Java-based software want to be able to coerce users into getting a newer version, so they make it necessary to get the newer version of the software in order to run it on a newer version of the JVM. I think there's a cultural issue here; I don't see the same kind of asinine behavior out of developers and distributors of software written in other languages.

spearson@8herons.com
spearson@8herons.com

I can understand having it check for older versions of a JVM, as there may be bugs or no support for in an older JVM for a particular method. What I found odd was that it would not allow a newer JVM, including the next point release. I was doing a rebuild of a client's PC, and it took me a little while to find that exact point release of the JVM, because it would not take the next point release, which would, under normal circumstances should work, and which you can't test for, anyway, because at the time of writing the software the next point release probably didn't exist. Point releases usually just fix bugs and don't introduce new features or major changes, so why write the program to not allow an update to the JVM?

Justin James
Justin James

I think the Mono project is a good one. I have a very favorable impression of Miguel de Icazca. But I have huge concerns around the project on the corporate level... Novell was running it, and I haven't figured out where they are going now. Novell has *never* impressed me as a tech steward. They bought WordPerfect for $1 billion and sold it a few years later for $100 million... they squandered a commandeering lead in the x86 server market... Novell has "Fido's Magic Touch"... everything they touch turns to... well... you know. :) J.Ja

apotheon
apotheon

This is the kind of reasoning that leads me to be leery of technologies like the JVM, Mono, and anything with GNU in the name.

Justin James
Justin James

I agree that Java devs need to pay a lot more attention to the open source issues around Java. Most of the big advances in Java that kept it from dying were open source things like Eclipse, Spring, etc. But that's what happens when you hitch your cart to a horse without asking who is feeding the horse or holding the whip. J.Ja

apotheon
apotheon

A lot of open source involvement does affect the lives of those enterprisey Java devs. Eclipse comes to mind. Linux-based servers are huge as a corporate enterprise platform on which to run Java software; the Linux community's support for Java helps ensure that things work smoothly and efficiently. The upshot is that while most Java developers do not care about open source software's relationship with Java, many of them should. While losing the support of the open source community will surely not kill Java outright, the language's niche may well dwindle a bit, and become narrower, even within a corporate enterprise context.

Sagax-
Sagax-

You presented a view that I had not given enough consideration.

apotheon
apotheon

It's true that Java is very heavily used in embedded devices. It wasn't chosen for any technical suitability to the usage, though. It was chosen for the same reason it gets chosen in so many other areas in corporate projects run by pointy haired bosses and staffed by daycoders who like Java as much as stableboys like horse feces. There are other technologies that would have been better there. Objective-C on embedded devices is one case where Apple did things better than its competitors.

charlvj
charlvj

I guess your experience depends a lot on your speciality and the places you most find yourself in. As for me, I have encountered Java everywhere I have gone. Even where I now work, which is rather strictly an MS environment, we use Java for our web frontend, search facilities, not even to mention in the warehouse! Our RF guns, for example, also run Java. (As an aside, I am surprised no-one has mentioned the embedded device use of Java. I believe Java is very popular in that field.)

apotheon
apotheon

You may find this surprising, but in my experience, the majority of Linux servers and workstations do not run any Java software, short of the largest corporations. Those corporations use Java for reasons entirely unrelated to OS choice; they use it because they "need" the enterprisey software they purchased, which happens to be Java software. They select Linux-based systems because of licensing and hardware costs. If Java went away, they would not then be limited to MS Windows; they would just have to find or build replacement software, which would in many cases likely be targeted specifically for open source platforms for the same reason those enterprises selected Linux-based systems in the first place. The rest of us in the open source world mostly don't use Java. Your use case is not my use case.

Neon Samurai
Neon Samurai

The only Java written apps I've got here are on the desktop side. Much of OWasp is Java. On the server side, Java isn't installed now so my specific case would remain unaffected other than replacing a fuzzer or two on my workstation. (and oh how I'd love to drop Java from the general staff workstations but it's not yet an option or related to the OS choice)

apotheon
apotheon

Many alternatives to Java application servers take much less time, effort, and money to maintain for performance, security, and reliability greater than Java application servers provide. The fact that a vertically integrated Microsoft stack is not one of those alternatives is not something that really factored into what I meant to say.

daboochmeister
daboochmeister

... does a Java app server take more time to maintain than alternatives, is the question I thought you were commenting about. For us, it was clearly not the case, maintaining our Java app servers was considerably less expensive than the MS stack, was my point (though you're right, I didn't tease out that portion of the equation cleanly).

apotheon
apotheon

I was talking about the Java components specifically. It's my experience that MS Windows is a lot more work to maintain than Unix-like OSes. I was the primary admin for a corporate network at one point that was about something like 15% MS Windows and the rest Linux-based systems, but I easily spent 65% of my time on the MS Windows systems. If you take your OS choice out of the picture, though, maintaining a server farm running Java-based software becomes a major time sink for admins a lot of the time. That was my point.

apotheon
apotheon

When you talk about portability, this should be included in the comparison. A binary compiled executable written in C effectively carries its runtime environment with it. The fact that Java pushes that off to a separate chunk of code should not give it a free pass to be effectively unusable on some systems and still be called "portable".

daboochmeister
daboochmeister

... but I have completely clear metrics to support. The last system I was responsible for had a large set of servers, 2/3 Linux (Red Hat) running Java app servers (WebLogic and Tomcat, fronted by Apache), 1/3 Windows running the MS app serving stack. Total labor costs for maintenance of the servers from our staff, soup to nuts, was TWICE as much for the Windows servers as the Linux servers - even though there were half as many. That's a 4x labor cost. That includes everything from initial procurement and license maintenance admin through and including software updates/deployments and operational system fixing. Total materials cost of software licensing, amortized out over 6 years (our server maintenance cycle), even including rather pricey WebLogic licensing on some of the Linux servers, was about even - again, even though there were 2x more Linux servers. And I can assure you this was a professionally run system, by people with the correct expertise and toolset to do it right. I never finished a full analysis of the Java vs. non-Java app server components of those cost differences, but we did enough to convince us to start moving to a mix of WebLogic and Tomcat Java app servers even on the Windows boxes (as well as moving to Red Hat for as many of the Windows boxes as feasible - not possible for all, as there was some Windows-only, non-portable software in the mix).

Justin James
Justin James

Oh, I know *exactly* what you mean. A while back I tried to run Typo3 on my FreeBSD server, and the Java install process (never mind getting Tomcat + Jakarta set up right) was such a pain that I felt like Typo3 needed to be a "sliced bread" application to get me to keep it (it wasn't). But you're looking at a different kind of portability... I'm talking about the code not needing changing from one OS platform to another, and for server side side, it's "good enough" (not the quotes). I've noticed that a lot of enterprise-y Java apps require a specific app server, which makes the point clear, though... the Java portability issues have shifted from the OS to the app server. J.Ja

apotheon
apotheon

Could you imagine having to deal with the license acceptance process -- which involves stuff like using a browser and so on -- for the ports system install of the JVM on FreeBSD on a server farm? Good grief, with the number of Java security updates that are released each year, managing the JVM installs on that farm would be a full-time job in itself. Yes, there are other ways to do it, but then of course you lose the benefits of the FreeBSD ports system. Sucky. The truth of the matter is that people think that Java is "good enough" on the server side in the enterprise because they tend to fall into one of two groups: 1. Stockholm Syndrome: they believe running servers just has to be a huge effing pain in the fourth point of contact, by nature. 2. Spendy: they pay through the nose to make it Someone Else's Problem. When making sure a piece of software can run on your server systems requires that much time and effort, or that much money, I don't really think of it as "portable". Throw enough money at a portability problem, and you can overcome the problem -- but that doesn't mean the problem is gone.

Justin James
Justin James

If you are doing desktop stuff, that's where Java seems to have issues with portability. On the server side, I think it's a lot better than people think it is. The VM matters more than the base machine, I'll put it that way... J.Ja

Justin James
Justin James

For what COBOL does, it is an excellent system. I would love to know why you think COBOL is so awful. And for what people are using Java for, while I dislike it, it is better than the alternatives. J.Ja

GentleMiant
GentleMiant

There may be someone somewhere still using mercury delay lines for memory... but they NEED to update/upgrade, don't they?

Justin James
Justin James

COBOL is so alive and kicking it isn't funny. In fact, there is an impending talent crunch since everyone thinks it is dead and doesn't learn it. Meanwhile, nearly every bank, airline, insurance company, and government agency is dependent upon COBOL applications. I believe the estimate is that you interact with COBOL apps 19 times a day. Billions of dollars go through COBOL apps daily. If COBOL were to suddenly disappear, the world a we know it would literally cease to function within 24 hours, and that is a gross understatement. J.Ja

mark_berger
mark_berger

COBOL dead? not by a long shot. There are still millions of lines of code in use out there. As many COBOL programmers retire there will be jobs out there for the guys & gals who can keep it going. Heck, we still use some Assembler although maintaining that code seems to be a nightmare for most object-oriented programmers.