Feeds

back to article Java won't curl up and die like Cobol, insists Oracle

With Java 8 still on its way in mid-2013, Oracle is already prepping for Java 9 and 10, and protesting that reports of a Cobolesque slide into irrelevance are much exaggerated. Java 9 and 10 will tackle big data, multi-language interoperability, cloud and mobile and ship in 2015 and 2017 respectively, Oracle said Wednesday. …

COMMENTS

This topic is closed for new posts.

Page:

Pint

COBOL??!

Um, last I checked COBOL did not "curl up and die." It's still alive and shambling like Frankenstein's monster, outliving both it's creator and civilizations. In fact, I predict COBOL will outlive Oracle. Java should be so lucky to have the lifespan COBOL does.

29
1

Re: COBOL??!

Another interesting question: how much of Larry Ellison's money is run by COBOL code? I'd say 70%

5
0
Silver badge

Re: COBOL??!

I'd say _way_ more than that.

1
0
Silver badge

Re: COBOL??!

Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha

I would bet good money that, as of this very day, Cobol is driving more business-critical applications and serving more end-users than Java does - or indeed ever will.

Oracle can get back to us when the amount of Java business code in daily use gets past 300 billion lines.

4
0
Devil

Reports of [COBOL] death greatly exaggerated

Considering the BILLIONS of lines of COBOL running millions of business-critical applications hardly sounds like something that has "curled up and died." Maybe COBOL isn't busily implementing the latest fads in language design but it is unlikely to be supplanted by some other language for a couple more millenia.

It's still here because it still solves business problems in a stable, well-documented way. Can Java say that?

No, I'm not a COBOL weenie, never written a single line of COBOL code. I don't do Java, either.

20
0
Gold badge

Re: implementing the latest fads in language design

Java was consciously designed as "C++ with all the interesting fads taken out" so I don't think it has anything over COBOL in this department either.

4
3
Silver badge
FAIL

Re: implementing the latest fads in language design

>Java was consciously designed as "C++ with all the interesting fads taken out"

What like blazing performance and efficient use of memory? (granted in the hands of a competent developer) Managed environments are popular because they allow lowest bidder hacks to seem like they are professional developers.

6
0
Silver badge

Re: implementing the latest fads in language design

managed code environment that is.

0
0
Gold badge

Re: implementing the latest fads in language design

Yup. Those are two of them. Others would be cleanly distinguishing between interface and implementation and allowing the use of libraries written in other languages.

For the most part, I wouldn't call them "fads" either, but it seems highly unlikely that the language designer wasn't aware that his new language was excluding these features. Just about every general purpose other language devised at the time has them, so I have to assume it was a conscious omission. (With reference to the post I was replying to, that's rather the point. Sorry if you got the wrong end of the stick.)

Of course, it makes sense if your target platform is client-side web or rice cookers. Java has its place, after all. That place just isn't "on the back-end".

0
1
Silver badge

Re: Reports of [COBOL] death greatly exaggerated

> Maybe COBOL isn't busily implementing the latest fads in language design

Ah, but it is, if you want them. The '85 standard added structured-programming constructs and nested programs. OO COBOL has been around since the early '90s, and was standardized in 2002. There are multiple COBOL implementations that target the JVM and CLR, and are fully interoperable with other languages in those environments.

We don't have dynamic anonymous closures, first-class functions, and the like for COBOL yet, but they're probably not far away.

Of course, you can still just write monolithic COBOL programs in the classic style.

1
0
Silver badge

Re: implementing the latest fads in language design

> allowing the use of libraries written in other languages

Trivial for other languages that target the JVM, and not much harder for native libraries, using JNI. I've had to do more work marshaling data structures for calls between two native languages in many cases than I have for JNI interfaces.

0
0
Bronze badge
Mushroom

Great, Java, wonderful future in the enterprise. Fantastic.

Now get the fugg off my desktop with your intrusive updates coming too late to patch the gaping security holes. I don't want to know any more.

8
5
Gold badge

Re: Great, Java, wonderful future in the enterprise. Fantastic.

The irony is that Java's "verifiable byte-code" execution model only makes sense on the desktop. In the enterprise, the code is written by the person who owns the computer it runs on, so trust isn't an issue.

3
0
Silver badge
Meh

Hmmm, the first two commentards had *exactly* the same thought as I did. But those Oracle guys they're just so... so... help me out people. I can't think of the right word.

2
2
Silver badge

Seriously everyone expects Java to become the next Cobol

A dependable stable platform which will outlive us all. Unfortunately Java already has gotten to complex.

I don't know how complex your average Cobol environment is, but I'd say that's a tad easier to maintain than your average Java environment. That's what it eventually boils down for platforms, can you still maintain it when all foreign support stops?

4
1
Silver badge

Re: Seriously everyone expects Java to become the next Cobol

> I don't know how complex your average Cobol environment is...

Most COBOL applications run in a mainframe or minicomputer environment - like IBM's CICS and IMS, or System i (nee AS/400), or various Unisys systems, etc - or in emulators of those systems running on Unix or Windows machines. Those environments are hugely complicated. Even COBOL applications that were written as "bare" Unix/Windows apps often use a lot of the standard COBOL runtime services and vendor-proprietary extensions, which can be quite complex. And then there are the COBOL apps written to run under the CLR (which can use the entire .NET Framework and anything else that runs in the CLR) or the JVM (which are in precisely the same situation as Java apps).

So, no, COBOL doesn't really have an advantage in the "complex environment" area.

The main advantage of COBOL applications from a maintenance perspective is that most of them are mature. They're old code which has been extensively exercised in production. Most code paths either have been tested six ways from Sunday, or are very unlikely to ever be taken. So there aren't many surprises. That's what that recent (and somewhat controversial) "technical debt" survey found.

Most COBOL apps also avoid some of major areas where programmers make errors - parallelism and synchronization, for example, or buffer overflow vulnerabilities - but that's really just a matter of historical limitations (which no longer exist in many environments) and habit.

1
0
Silver badge

Why is Java in trouble?

I realise it's cool to rag on Java and the language certainly suffers deficiences that should be rectified. But it's still the most powerful and flexible development platforms bar none. And if you don't like Java the language, well there is an ever growing number of languages that run in the same JVM.

The danger is not the language but Oracle's attitude. We've already seen them suing Google and alienating the Apache Foundation (who probably deserve most credit for Java's success). I can well see people deserting Java simply because they don't like the direction it's being taken.

12
3
Megaphone

Re: the most powerful and flexible development platform

Java? No way. The most powerful development platform is UNIX. GNU UNIX. Wake up, people! It's RMS who gave you The Compiler, who freed the slaves etc and so on.

1
4

Re: the most powerful and flexible development platform

I see you are being sarcastic but if you notice, openjdk and Apache's implementation (which is android now) started with similar reasons (open, documented, corporate neutral) are saving Java's future both on userland and enterprise.

0
0
Silver badge

Re: the most powerful and flexible development platform

I don't believe enterprise cares about Apache Harmony or OpenJDK. When you have millions riding on uptime and reliability you're not going to be running your critical code from an open source JVM. More likely they're powered by Oracle's own JVM, Websphere or some other certified runtime.

Harmony and OpenJDK have more value for developers and stakeholders who see them as a parachute to bail if Oracle completely loses its mind and does something to alienate its developer base. We've already seen how Harmony allowed Google to escape from J2ME, and if Oracle decided to kill J2SE completely then I could see how some consortium could pick up the banner under OpenJDK to keep it going.

1
0
Anonymous Coward

Re: Why is Java in trouble?

"But it's still the most powerful and flexible development platforms bar none"

Muahahahaha.

0
0
FIA

Confused

"For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. "

Erm, how is Java not currently OO?

4
1
Silver badge
Holmes

Re: Confused

Nope.

int x = 12; x.toString()

Ouch time if you are not writing this in Groovy.

0
0
Flame

Re: Confused

I guess it is a case of Smalltalk Envy. You know, being able to call methods directly on integers, storing integers in arrays of Objects and so on.

Indeed more of a priority than getting a proper VM implementation done (one that doesn't crash upon parsing "hostile" PDFs with a pure-Java PDF parser) , if your are a fscktard.

1
0

Re: Confused

They're going to make the entire language OO, which means they are going to implement all the primitives and operators as objects as well. Just like they do in Scala.

0
0
FIA

Re: Confused

"Nope.

int x = 12; x.toString()

Ouch time if you are not writing this in Groovy."

That's just removing primitives though. It doesn't make the language more or less OO, it just makes it easier for people who don't understand the distinction between primitives and objects (and possibly some of the confusion around the auto boxing introduced in 6.)

Re Smalltalk: I wonder if they're going to change it to message passing like objective C too?? ;)

0
0
Boffin

You accidentally put "Java" and "powerful" in the same sentence.

11
3
Silver badge
Trollface

So .... what kind of "powerful" do you want exactly? Fast compilation? Lots of third-party libraries? Extreme loop optimization? Not being fired for choosing a language with which your average company programhamster can deal?

3
0
Gold badge
Boffin

So what are the universities and colleges teaching these days?

After all isn't that the mark of what's now?

Given COBOL has survived since the late 50's I'd say Java has about 30 off years to be relevant.

Like many areas it may not remain a *visible* language but *inside* large organizations who've invested in a large code base (possibly to avoid MS lock in for example) it may continue to rule.

The JVM has also been the base for a number of other languages as well.

I'll wait for the annual skills Vs pay surveys to see what happening.

0
0

Re: So what are the universities and colleges teaching these days?

"The JVM has also been the base for a number of other languages as well."

...including COBOL --> elasticcobol.com

3
0
Holmes

Re: So what are the universities and colleges teaching these days?

What universities and colleges teach is not necessarily relative.

What they teach is what they can get most cheaply, preferably for free. This is what made UNIX preferred in colleges and universities and many workplaces when the Bell System still existed, and pursuant to the US Telecommunications Act of 1934, Bell Telephone Laboratories had to give away - for free - all inventions (including software) which were not intended by the recipient to be used to compete with Western Electric or a Bell Operating Company.

Likewise - although not compelled by law - Sun gave away Java (and went broke in the process.) The only way Java will even -survive- is if Oracle realizes that other free or inexpensive languages will take Java's place in colleges and universities if Oracle starts charging hefty fees for Java.

0
0
Facepalm

Larry's Moore's

@FIA: not well-expressed, rather they meant "uniformly and completely object-oriented". Think of Ruby and that everything has methods - there are no primitives - as opposed to Javascript and others where primitives like integers are "auto-boxed" to permit using object methods like length().

I can immediately spot the Moore's law get-out-of-jail assumption here. By the time Omgacle implements these little changes to Java, the by then 'modern' CPUs will be able to run just about as fast as now. No primitives? Large address spaces? Surely by 2015 and 2017 they'll be able to say "without slowing down Java!"

0
0

Basic question

If I were them, I would ask myself a very simple question: "How could android succeed?"

Answer to that question minus corporate rdf could fix things. For example, never ever think developers and users like Google or trust them. They don't. I mean don't trick yourselves.

0
0
FAIL

A fate worse than COBOL

The attractiveness of the JVM as a platform for other language writers means that the Java stack risks a worse fate than COBOL: namely, becoming the faceless, disregarded bottom layer of the coding stack (providing the JVM and boring utility libraries), while the developer relationships - the truly valuable part - are increasingly captured by the teams behind Scala, Clojure, JRuby and Groovy...

0
2
Silver badge
Happy

Love / Hate relationship

Now; I'm not a professional developer but a sysadmin. However, within that context I sometimes need to be able and perform tasks which are sometimes easier written yourself. When I came into contact again with Solaris (when 10 came out) I also started to grow a more mature interest in Java (before that it was only as end-user, for example; I ran several Java programs on OS/2 Merlin without actually realizing the full extend of what Java really was). And it didn't take me long to adapt to NetBeans (started with version 4.1) and actually enjoying myself learning Java.

So that's basically where I am today. I have good insight knowledge on Java SE, have some basic experience with Java EE (and some stuff associated with it, such as EJB (Enterprise Java Beans)) and have some beginning experience with Java ME (mobile) although I don't plan on extending on it.

Now; ever since Sun got ran over (personal opinion) I started to move away from Oracle because I don't like their policies. However, I can't bring myself to move away from Java as well. The language is simply too extensive for that. How much languages are there which you can apply for development on both Windows and Linux for example? Where there are also options available for Apple and BSD platforms? And where the language itself isn't that hard to grasp and most importantly: well documented...

And that basically also forms my opinion on the matter; I don't think Java is going to die anytime soon, not even with Oracle trying (which they don't so it seems) because its simply too extensive and too easy to use. But most of all because of the massive amounts of fans it has. I mean; even though I personally don't really like projects such as Kaffe and "OpenJDK" you can't ignore the tremendous effort people put into that nor can you wave away the progress they made. Sure; their VM may not be a "real" Java in every detail, but it sure as heck provides a solid foundation to work on. Java programs which aren't too specific will run on those environments.

As long as you have devoted fans like that around then I don't see a language dropping "just because".

Heck; even my first love Borland Pascal is still around and kicking some ass, also on Linux!

...which reminds me to setup BP6 sometimes to see if I can use this on Win7 to play with some of my old programs.

7
0
Silver badge
Thumb Down

java mobile um ok

Too bad the only place Java is succeeding in the mobile space is exactly what Oracle is trying to stop or destroy (Dalvik). Even then for the most part sadly the ugliness that is Objective C is by far the biggest gateway to glory.

2
0
Bronze badge
FAIL

No primitives?

The advantage that Java has over scripting languages is exactly the primitives. It's missing C's unsigned math and bulk structure allocations, but data crunching generally compiles into something efficient. It can do multithreaded image rendering and compression, resample data, and it can pack binary data streams into dense indexed structures. You're free to ignore the decade of bloated libraries created by Apache, Sun, and Oracle when performance matters more than simplicity. Eliminate the primitives and one might as well go to PHP, Ruby, Python, etc. that sacrifice performance for superior simplicity.

2
0
Silver badge
Trollface

Hatin' on Java since 2001

Unrelated, but I still get chuckles out of this:

http://www.salon.com/2001/01/08/bad_java/

[Don't know why it's published by Salon, the webmag for reality-challenged People of the Left, but so be it]

0
0
Bronze badge
Unhappy

Cobol of the 21st century indeed

Not because it will off anytime soon, unfortunately. Ditto Cobol.

Like Cobol was, Java is now the language of choice for the corporate masses.

Like Cobol, it has tons of features intended to promote a certain, often verbose, approach to programming because the designers thought it was a good idea.

Like Cobol, the afficionadoes believe that the rest of the programming languages are for sissies. Heck, any self-respecting Java book has to teach us about classes and objects, all over again.

Like Cobol, this is where there is a lot of employment - and a lot of salary competition as well.

Unlike Cobol, books on the language and all of its pet frameworks and libraries of the month fill bookshelf after bookshelf with weighty tomes of drudgery.

Like Cobol, one must admit, from afar hopefully, that it is quite successful in its niche.

2
0
Flame

Java -- J2EE worse than Y2K!

The mess that is J2EE presents enterprises with a worse problem than Y2K.

All those applications written to JE 2 3 and 4 standards are incompatible with each other and the newer cleaner JE standard. Worse still because JSP was "bad" (its still here, still backward compatible, and while it is slightly c**p, its still better than any other attempt at a JE presentaiton layer) architects favored abominations like STRUTS and FACES plus several home grown solutions. All these applications are stuck in rut cannot be upgraded to the latest greatest JE standards and will require a complete re-writes sometime soon.

0
0

UNDEAD

IDENTIFICATION DIVISION.

PROGRAM-ID. STILLHERE.

AUTHOR. WEATHERWAX.

PROCEDURE DIVISION.

DISPLAY 'I AINT DEAD' UPON CONSOLE.

STOP RUN.

7
0

java and mobile devices

The problem java faces on mobile devices is that the device makers are moving away from supporting it. Blackberrys new OS qns base doesn't use java and neither does windows phone 7 or 8 ( whatever its called!) .

As to COBOL the truth is a good language will not die it does what is does reliably.

AD2apps.

0
0
Bronze badge

Just an aside for primitives vs objects

Why can't the compiler figure this out? If I use no methods on a datatype then compile it as a primitive, otherwise either autobox or change the type to the object representation of the datatype. I think having both primitives and datatypes is a good idea, but why do we need to see it?

0
0
Mushroom

Opinion of a Java developer

A good stab at trying to kill it, in my opinion, comes from the big companies where it is used.

It seems hard to see jobs listed which don't, or will, require Spring and Hibernate.

Luckily I only had to try to work with them for a year or so, but I never managed to figure out what can't be done without them. Apart from badly performing code without unexpected behaviour.

The last project in which they were used wasn't doing anything spectacular, just some clever business logic behind it, but nothing uncodable.

The project kept on missing every possible deadline mainly because of the two.

For example, a select statement using Hibernate which performs an update to return a resultset - http://ladobbins.wordpress.com/2011/11/02/i-hate-hibernate/

Or, again, one of the joys of using Hibernate: unpredictable number of queries for a select statement:

http://itroman.wordpress.com/2010/12/05/why-i-do-hate-hibernate/ ( Hibernate is not predictable )

Mapping tables for many to many relationships become a pain if an extra column must be added, or there's more than two tables involved.

Letting Hibernate take care of caching data makes it even worse. Is it just the table I am caching, or the entire objects whose IDs are in the mapping table?

There's versions of Spring which clash with Hibernate ( happened to me ) which created problems with transactions ( if I remember well ). 3 people searching forums for 3 days before realising it wasn't something wrong in the sea of XML needed to keep the stuff together.

All this for not using plain JDBC. Why is beyond me.

Also, in over a year, I haven't managed to understand what Spring does so specially that you can't just stick to sane Java.

Why do people use a tool which uses XML for coding ( not just passing values ), doesn't check for code consistency so all the compilation errors only appear at run time ( a bit like when I was learning Java and used to code on Notepad ), and leaves a cryptic 200 line stacktrace to let you there could be a typo in a variable name instead of a squiggly line which appears as you are typing it?

The same opinion was shared between pretty much everybody in the company, apart from a couple of people who first introduced it.

I am sure one day, when they are not fashionable anymore, a lot of people will wonder why they were even introduced. If that day doesn't come, I guess Java is pretty much fucked. My opinion.

And yes, I am still bitter, absolutely, when I think about those two pieces of shit brought to the project ( and my life as a consequence ). I am sure many people could say the same... At least judging from the people I used to work with then. Rant over

1
0
Anonymous Coward

Why would Java go entirely object oriented? If you want to use Integers instead of ints... knock yourself out. If you want to write an entirely primitive-less app, you can do that. But trying to excise primitives from the language just isn't going to happen. e.g.

List<Integer> numbers = new ArrayList<Integer>(Arrays.asList(1,2,3));

a) numbers.remove(1); // numbers now contains {1,3}

b) numbers.remove(Integer.valueOf(1)); // numbers now contains {2,3}

Imagine if primitives were removed from the language... which of a) or b) above would be the behaviour? And how much code would it break for everyone who was relying on the opposite behaviour? The answer is too much for them to ever do it. Hell, they've -still- not removed all the deprecated methods from Date, or moved what should obviously be unchecked exceptions (e.g. ClassNotFoundException) into the RuntimeException hierarchy...

0
0
Silver badge

Java=Dependancy Hell

Syntax is too complicated; libraries are out of control; too many versions too quickly.

I just can't be bothered with Java anymore. It's a full time job just maintaining even a pretty basic installation. I'd rather do some actual coding.

Nice idea, but in the end not well executed.

3
3
Anonymous Coward

My children love Java

When they reach 10 I'll teach them a proper language they can make a career out of

0
4

Re: My children love Java

I guess you ought to keep teaching them Java then as there are more Java jobs available than any other language.

4
0
Happy

Re: My children love Java

There are lots of jobs, there are few satisfying, well paid careers. Wrestling with the awfulness that is Java supplies very few (if any) of the latter, even though there may be lots of code monkey jobs around.

0
1

Alive and kicking - and for good reason

One thing is certain, COBOL is far from dead and remains highly relevant for today’s enterprise applications. COBOL runs over 70% of the world’s business, with more transactions processed daily by COBOL business applications than Google searches made. And with billions of lines of new code written each year, all evidence points to a continued reliance on core COBOL systems.

A recent IT study addressed code quality specifically between two application development languages – Java and COBOL. The study introduced the concept of technical debt to this discussion and its growing impact on today’s business. Addressing such technical debt, the average cost per line of code was projected to be £2.31. The cost to address Java quality issues, per line of code, was £3.47 compared to the cost of COBOL quality issues which was £0.80. With respect to cost and impact to business application quality, Java was well over 4 times more expensive than COBOL.

When tackling technical debt impact, the absence of sound technical architecture and planning is one reason for the increased number of code quality issues with Java. COBOL doesn’t suffer from this challenge as it has been vetted for over 30 years in enterprise organisations. Moreover, it possesses key attributes of portability, robustness, ease-of-use and “future-proofing” (thanks to vendor investments). In this regard, COBOL becomes a less risky option for business due to its prevalence within IT over the last half century, and can be the lowest-cost option to providing new business value. Importantly, COBOL continues to provide the horse-power processing needed by front-end applications built in Java, and modern tooling allows the COBOL and Java programmer to collaborate better than ever.

With more and more IT decisions being made for business reasons, COBOL’s place in the future looks as likely now as it ever did.

1
0

Page:

This topic is closed for new posts.