Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java's Backup Plan If Oracle Fumbles

timothy posted about 4 years ago | from the enough-java-should-keep-you-awake dept.

Java 276

GMGruman writes "In an InfoWorld blog, Paul Krill suggests that those concerned that Java might get lost in Oracle's tangle of acquired technologies should relax a little: Java's future isn't wholly in Oracle's hands, so if Oracle screws up or lets Java languish, the popular language has other forces to move it forward nonetheless."

cancel ×

276 comments

What could possibly go wrong ... (2, Informative)

Noam.of.Doom (934040) | about 4 years ago | (#32791380)

... when being owned by Oracle?

Re:What could possibly go wrong ... (1)

hotfireball (948064) | about 4 years ago | (#32791396)

Java is not owned by Oracle.

Re:What could possibly go wrong ... (1)

Noam.of.Doom (934040) | about 4 years ago | (#32791404)

That was supposed to be a sarcastic comment, but doesn't Oracle own any IP of some sort regarding Java? Patents? Trademarks?

Re:What could possibly go wrong ... (2, Informative)

kthreadd (1558445) | about 4 years ago | (#32791888)

It depends on what you mean when you say Java.

The Java(tm) name is owned by Sun/Oracle.

The Java Language Specification is owned by Sun/Oracle and is offered online for free, with a few restrictions however. As an example you are only allowed to print it once and not make any copies of it.

The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.

So the answer varies depending on what you mean with Java. While the phenomenon known as Java may in theory be owned by Oracle it is in practive decoupled enough to be independent.

Re:What could possibly go wrong ... (-1, Troll)

Zeinfeld (263942) | about 4 years ago | (#32791406)

No, Java is controlled 100% by Oracle. That was what the Microsoft lawsuit was all about - gaining absolute control of the future of the language. If Sun won that was the end of Java as an open language.

Sun won, we lost and everyone here cheered because you don't have a clue.

Microsoft was entirely within its rights to extend Java to provide native support for Windows O/S. The lawsuit was ridiculous and wrongly decided.

Re:What could possibly go wrong ... (5, Informative)

Big Jojo (50231) | about 4 years ago | (#32791488)

Go away troll....

Microsoft was entirely within its rights to extend Java to provide native support for Windows O/S. The lawsuit was ridiculous and wrongly decided.

The issue was violating the the compatibility constraints, so that code would no longer be portable to non-Windows O/S. This was precluded by the license which MSFT signed, so the lawsuit was reasonably decided.

Re:What could possibly go wrong ... (2, Informative)

Anonymous Coward | about 4 years ago | (#32791524)

But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment, and this only got worse as Sun kept cranking out a shitty new theme with each release of Java. Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

The situation was slightly better for server-side Java, but we still ran into the FS path problems, and early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

The only thing that ever worked perfectly for us was to develop on Solaris workstations, and to then deploy to our servers running Solaris. Developing on Windows and deploying to Solaris was almost always a recipe for trouble. Java has never really been a viable option on Mac OS X, and Mac OS before that.

Re:What could possibly go wrong ... (3, Insightful)

Anonymous Coward | about 4 years ago | (#32791590)

Java's cross-platform compatibility has always been a myth

Don't talk nonsense, man. Back that up with something.

If you write the code properly, and stick to Java (no JNI stuff), it's cross-platform. How is that a myth?

Re:What could possibly go wrong ... (1, Informative)

EsbenMoseHansen (731150) | about 4 years ago | (#32791832)

The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.

Re:What could possibly go wrong ... (2, Informative)

haydensdaddy (1719524) | about 4 years ago | (#32791738)

Java has never really been a viable option on Mac OS X, and Mac OS before that.

The reason for this was never Java itself, but Apples stranglehold on the implementation and their very public "fuck you" attitude toward developers wanting a release within 2 years of the releases on other platforms.

Java cross-platform DOES work (3, Informative)

Anonymous Coward | about 4 years ago | (#32791740)

We have java swing code that runs on window, linux, and os-x. We use a custom look-and-feel so things are consistent. Ok, the one-button mouse is a pain.

We java backend code that runs on intel (windows/linux), powerpc, and arm. I routinely deploy and test on linux-x86 and deploy to powerpc and arm targets with zero problems.

Re:What could possibly go wrong ... (5, Insightful)

Tim C (15259) | about 4 years ago | (#32791846)

Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

That's the fault of the programmer(s), not Java.

Besides, while you have valid points, they are irrelevant to the topic at hand; MS signed a licence saying that they could not introduce Windows-specific classes into the java.* package hierarchy, and yet they did so. No one would have cared if they'd put them in com.microsoft.*, but they chose not to do so.

Re:What could possibly go wrong ... (5, Informative)

KermitTheFragger (776174) | about 4 years ago | (#32791854)

But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment,

Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately ? Visual Studio looks different then the rest, Office looks different from the rest, Outlook looks different from the rest of Office, Media player looks different from the rest, Home Server UI looks different from the rest and I could go on and on.

and this only got worse as Sun kept cranking out a shitty new theme with each release of Java.

In the like 14 years of Swing existence there have only been 3 themes in the JRE: Metal, Ocean and Nimbus. And metal is selected by default. Java never sets one of the newer themes by itself. So basically the default theme hasn't changed.

Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

So there are people who make crappy programs in Java. How exactly is that different from other languages ?

early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

A few years before pure JDBC drivers were available ? That was when, 2000 or something ? Since that problem is long solved I don't really see how thats relevant today.

Java has never really been a viable option on Mac OS X, and Mac OS before that.

Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.

Re:What could possibly go wrong ... (0)

Anonymous Coward | about 4 years ago | (#32792070)

Java has never really been a viable option on Mac OS X, and Mac OS before that.

Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.

Sun did the Java implementation on the "classic" mac before Apple did. It was totally unusable, so much so that the "MRJ" runtime that Apple produced afterward was a huge improvement. And MRJ was really crappy; it never supported anything beyond Java 1.1. Still, that was worlds better than Sun's, ie. it actually worked some of the time.

Just look at how long it took Sun to do an OpenOffice port for OSX. Its attitude was, "Just install x11, n00bs."

Apple is better at doing Java than Sun is at doing MacOS.

Re:What could possibly go wrong ... (0)

Anonymous Coward | about 4 years ago | (#32792250)

Besides Apple no one cares about consistency on the Desktop anymore.

Who really actually cares Java on the desktop?

At most you may have an applet to configure a Brocade switch, but personally I've only really run across it in a J2EE fashion (or perhaps embedded in Blu-Ray). It generally died in a pure-desktop fashion long ago.

As server-side environment, I think it's very cross-platform.

Re:What could possibly go wrong ... (1)

jbengt (874751) | about 4 years ago | (#32792222)

My son has a job developing for a major financial company. They do development on MS Windows desktops and deploy on Linux servers. It works just fine for them: (Admittedly, there's not much of a user interface requirement for those apps)

Re:What could possibly go wrong ... (0)

Anonymous Coward | about 4 years ago | (#32791520)

Microsoft did not extend java. They removed features (RMI, JNI) and provided windows only replacements instead of providing the windows libraries as addition to a full java implementation, they also modified several classes to work better with a windows environment.

I see the embrace and extinguish parts but there is no extends here.

Re:What could possibly go wrong ... (2, Interesting)

Sycraft-fu (314770) | about 4 years ago | (#32791544)

Also a side effect of it was the web getting stuck on Java 1.1.6 for so long. Basically it got stipulated that MS had to ship that version, unmodified, in IE. That's what happens when you let lawyers after tech issues. Sun wanted MS to not make special mods to their version of Java but basically it can down to having to have that version. So the MS Java in IE languished at 1.1.6 and people kept using that because they wanted to be compatible. Finally MS was able to just remove Java and say "download it yourself" and it could be current.

At any rate you have an extremely good point. People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it. Open languages have that advantage and disadvantage. Anyone can implement them in any way they see fit, but the standards are guidelines, not rules set in stone. Someone can very well build a C++ IDE and compiler that is based on C++, but modified and not compatible. That would be ok. In some ways, this is already done with things like Visual Studio that offer more capabilities and as such can generate code that is not compatible with all compilers.

A locked down, single company controlled language has the advantage of having only one way of it being implemented. You know any implementation is the same because they can force that. However the big disadvantage is if said company decides to not care or stop handing it out or whatever, you are screwed.

Frankly I'd be happy to see Java die. Maybe if it did, something better would replace it. My objection isn't so much with the structure of the language, more the implementation, the JVM. It's a crap way of doing things. I think it could be done better, and would be, in the event that Java died off and people had to come up with something to replace it.

Re:What could possibly go wrong ... (1)

arjan_t (1655161) | about 4 years ago | (#32791644)

People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it.

Right, and so many companies actually did with Java. Only with one 'minor' difference: they didn't call it "Java SE".

The problem with MS was not that it was extending Java, but that it was luring programmers into thinking they were coding for the Java SE standard. If you were at a MS platform and only checked your code with Visual Studio, then you as a programmer wouldn't know. Until your users tried to run your Java app on their Linux or Solaris boxes, and found out it didn't work at all.

A very simple solution for MS would have been to provide flags in their environment for "standard compliance Java development" and "non-standard compliance Java development". If my memory serves me well, they had such flags for C++ in their compiler.

Re:What could possibly go wrong ... (2, Insightful)

roman_mir (125474) | about 4 years ago | (#32791554)

You are wrong.

Microsoft wanted to provide their own extensions and JVM that was not compliant with Sun Java while still calling the environment Java and using Sun Java trademarks and logos. The entire lawsuit was about the Java trademark. Eventually MS released their own language that is partially compatible with Java, you should know about it, it became what's known as J++ and later J#.

MS was forbidden from using the Java Compatibility trademark - the steaming coffee cup logo.

restraint of trade (2, Informative)

SgtChaireBourne (457691) | about 4 years ago | (#32791630)

Go away, lying revisionist troll.

The lawsuit in 1997 against Bill's Microsoft by Sun was about contract violation. Microsoft had a contract to distribute java, not their own proprietary version of java, but bona fide java true to the published specifications. The allegations, proven in court, were that Microsoft aimed to harm to Java platform, violated the Sherman Act by illegally monopolizing and illegally maintaining aon the Intel-compatible PC OS market and the web browser market and the office productivity suite market. Microsoft was also illegal tying products, and illegally entering into exclusive dealing and exclusionary agreements (violation of Sec 1 of Sherman Act), and engaging in copyright infringement, and restraint of trade and unfair competition. It was also attempting to illegally start a monopoly in the server operating system market.

Not only do you Microsoft toads ruin the economy, you make the net more expensive and create security problems. It'd be just fine if DHS started checking hard drives during entry or exit at the US borders and nuked any and all NTFS partitions they find. HFS, FFS, UFS, or EXT would be put on instead. Give a few months warning first and hand out Fedora CDs to those getting a warning. Then after the deadline, bam.

Re:restraint of trade (2, Interesting)

Digital Pizza (855175) | about 4 years ago | (#32792154)

While the Right Thing resulted from the lawsuit, it's funny how it hurt Sun and Java more than it hurt Microsoft, which was Microsoft's real goal anyway.

The thing is, I remember around that time that Sun's CEO Scott McNealy was constantly ranting and raving about how the goal of Java was to take over the desktop and specifically "Kill Microsoft". Launching a frontal assault against Microsoft (especially at that time) was foolish, and look at what happened. If the good folks at Sun had kept their mouths shut, maybe they would have actually succeeded.

You can applaud the result of the lawsuit, but so many comments on this article reflect a resulting public perception that is not exactly favorable to Sun and Java.

Re:What could possibly go wrong ... (2, Informative)

toriver (11308) | about 4 years ago | (#32792120)

No, it was a breach of contract suit; Sun and Microsoft agreed to a (publically available) contract about Microsoft making the reference implementation of Java on Windows, but then Microsoft broke the terms by doing stupid things like adding keywords (delegate, multicast [sun.com] ) to the language and methods and fields/constants to the standard classes.

I mean, this is public knowledge - why do you choose to lie? Yes, Sun was late in specifying JNI, and hence both Microsoft and Netscape came up with their own implementations of "native", but that was just one aspect of it and far from the most significant.

In summary: You are the one without a clue.

Java is already dead for new development. (-1, Troll)

Anonymous Coward | about 4 years ago | (#32791402)

I don't think that Paul Krill has realized yet that Java is absolutely dead for new development. Sure, there'll be Java-based software around for decades. Just because people aren't using it for new development doesn't mean the billions of lines of existing Java code will go away.

However, we're seeing absolutely no innovation coming out of the Java community. Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl. The JVM is an absolute mess compared to .NET, of all things.

Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development. Clojure is just a reimplementation of one of the oldest programming languages around, Lisp. Scala has interesting ideas, but they're thrown together with a gawdawful syntax that makes maintainability a nightmare.

These days, we're using languages like Python, Haskell, and Erlang to get real work done. Java just doesn't cut it any more.

Re:Java is already dead for new development. (3, Insightful)

roman_mir (125474) | about 4 years ago | (#32791568)

You are insane.

Not only there is constantly new Java code written for the back end, not only there are millions if not billions lines of code that are running existing services on the back end, but people are writing front end code in Java, at least for corporate environments.

How do I know? I am writing some of it.

Re:Java is already dead for new development. (-1, Flamebait)

Anonymous Coward | about 4 years ago | (#32791584)

Just because you're doing it doesn't mean it's any good. People are generally stupid and make bad decisions all the time, even in groups and for long periods of time.

Re:Java is already dead for new development. (1)

roman_mir (125474) | about 4 years ago | (#32791612)

Whatever AC.

Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data. HTML + browser is one of the slowest ways of doing it, Java beats that by orders of magnitude.

I know, because I measured it. An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.

Even that makes a huge difference, forget about the entire desktop like feel for the app, which is hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT, it takes much less code to get the same functionality as well.

Re:Java is already dead for new development. (2, Insightful)

EsbenMoseHansen (731150) | about 4 years ago | (#32791864)

By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.

Re:Java is already dead for new development. (1)

SanityInAnarchy (655584) | about 4 years ago | (#32792014)

Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.

So what?

An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.

And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.

Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once.

hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT

And did you try anything other than GWT? Certainly, if you're going to claim this:

it takes much less code to get the same functionality as well.

Java, as a language, is verbose as hell, so I would guess that a Java library that outputs HTML is worse than a Java library that talks directly to a graphics system. But those aren't your only choices -- JavaScript is decent, and has its own libraries.

You're also assuming that the functionality you get from Java is worth the functionality you lose. You're now requiring people to download a plugin -- no, not everyone has Java already, certainly not a recent version -- and your app is now rendered as an opaque blob, which means users can't script it with greasemonkey, it doesn't work with back/forward or bookmarking, it can't easily interact with other things on the page that want to behave like a webpage... Believe it or not, there are places where the Web beats a desktop app.

You may be able to replicate that native web feel, but that's going to take a hell of a lot more code than it'll take me to develop a decent native web-based app.

I'm not saying I agree with AC, but I really don't see much of a reason for doing browser-based Java -- though I do use it on the server side for other things.

Re:Java is already dead for new development. (1)

SanityInAnarchy (655584) | about 4 years ago | (#32792028)

If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.

Re:Java is already dead for new development. (0)

Anonymous Coward | about 4 years ago | (#32792216)

no, you are stupid!

Re:Java is already dead for new development. (3, Insightful)

mswhippingboy (754599) | about 4 years ago | (#32792066)

I have to agree with you here. I develop (for corporate environments) in a fairly large range of languages depending customer desires. The trend has been (for several years now) that more and more development is being done in Java, whether rewriting legacy systems or completely new development.
The benefits that Java offers are more compelling than just about any alternatives. The arguments against its ability to "run anywhere" are old and most (if not all) are largely inconsequential to todays environments.
A majority of development today is web-centric (intranet or internet) so issues with AWT or pathname incompatibility across systems are rarely encountered, and when they are, there are plenty of best-practices for dealing with them.
The old line about Java performance being inferior is also largely a dead issue as it's be shown time and time again that the newer JIT enabled VMs allow byte code to perform on par with native C/C++.
As far as being a dead language, I certainly don't see that happening any time soon. The language is under constant development and significant new features are being added with each major release, both to the platform (performance, concurrency, garbage collection, etc) as well as the language itself (modularization, closures,annotations, etc). The language is constantly evolving, but still, as much as possible, retaining backward compatibility.
Even if the language itself is not able to keep up with advances in modern language design, there are spin-offs like Scala that can co-exist in the same JVM and are able to take advantage of the large java eco-system while providing a different programming paradigm.

I gave up being an fan-boy for technologies many years ago when I got burned with OS/2, and have since decided to embrace whatever languages and technologies are in demand, be it MS tools (VB and C#), Apple (Objective-c) or non-proprietary (Perl, PHP, Java, etc.).
Folks that are quick to declare Java dead are obviously naive and don't have a clue about the way the IT world works. They can line up with the folks that declared mainframes and COBOL dead twenty years ago, while (according to a recent Computerworld article) more than 200 million lines of COBOL are still in use and a COBOL gig is still considered the safest gig in IT today.

Re:Java is already dead for new development. (1)

haydensdaddy (1719524) | about 4 years ago | (#32791830)

I don't think that Paul Krill has realized yet that Java is absolutely dead for new development.

...for you. While I have moved on to other languages as well for personal and outsourced projects for many of the same reasons you state, I'll have to tell the Fortune 100 company I work for that the millions of dollars per year they pour into new Java based projects doesn't actually exist...

Re:Java is already dead for new development. (1)

SanityInAnarchy (655584) | about 4 years ago | (#32792124)

Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.

Be specific. How are they impractical? In particular:

Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.

And what's impractical about Lisp, particularly a Lisp with STM?

It's also funny that you mention this:

Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.

Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equivalents, but the Java versions are the only ones still maintained -- for example, DataMapper supports Oracle just fine, but the only current low-level Oracle adapter that's supported is the JDBC one.

Then there are the crazier things, like running Rails on Google App Engine. I don't necessarily like the JVM, but it does mean I can run any language I like so long as it fits into that Java container.

I'm not sure how close Jython is to that kind of status, but I've been forced to develop stuff which runs on Oracle's WebLogic, and, surprisingly, the WebLogic Scripting Tool is written in Python, and runs on Jython.

It's also funny you mention Perl. What's the #1 reason for using Perl? CPAN. There's tons of Java libraries out there, though not as nicely organized as CPAN last I checked. If I were to take one such library -- say, a nice, well-behaved, self-contained jar -- I could use it trivially from my Ruby app. The Perl concept of grabbing existing CPAN libraries, maybe some only thin wrappers around C libraries, and binding them together with a thin bit of scripting glue to make something cool, is definitely alive and well here -- except you don't have to write any glue, it's trivial to just use the Java APIs.

So, I hate Java as a language. There are languages I merely dislike, or prefer not to use, like Python or Erlang, but I actually hate Java. But the JVM looks like it's turning into something cool.

The JVM is an absolute mess compared to .NET, of all things.

Except that .NET really isn't even to the point the JVM is for "write once, run anywhere." The main implementation is Microsoft's, and Mono is always two or three steps behind. You can either write stuff using Microsoft's APIs and hope Mono keeps up -- which would be like declaring your Windows app is "cross-platform" because it runs under Wine -- or you can stick to purely Mono stuff, which means you'll have to distribute native libraries (like GTK) with your app.

I think I've given up looking for the perfect VM. I'm sure the JVM isn't it yet, and I would guess that some other VM will take over. After all, the JVM physically can't (and may never be able to, may never want to) do some of the tricks the Erlang VM does.

But you're writing Scala and Clojure off as "shitty" without giving a real reason why, and you're either claiming people aren't using Java (or the JVM) for new development, or saying they're stupid for doing so. Where you're not factually wrong, you're just spouting opinions without backing them up.

Re:Java is already dead for new development. (1)

zzyzyx (1382375) | about 4 years ago | (#32792326)

Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.

Ever heard of Twitter? Their back-end is written in Scala. How's that for a large-scale real-world application?

Yess! (-1, Offtopic)

drewhk (1744562) | about 4 years ago | (#32791408)

This article will be the perfect one to start my little Flame War and abuse my precious, well-undeserved mod points to distort the conversation, downmod logical arguments to HELL and give rise to the brainless mob, thus poisoning the global Karma and drive the masses towards the unavoidable conclusion of my ultimate plan, and finally achieve TOTAL WORLD DOMINATION!!

Oh, wait...

Oracle actually uses Java (3, Interesting)

bdsesq (515351) | about 4 years ago | (#32791410)

Oracle uses Java for supporting it's bread and butter database.
The Universal Installer is written in Java as are a number of other tools.
It would cost Oracle millions of dollars to rewrite these tools if they killed Java.
They could still kill Java but it it would not be an easy decision for them to make.

Re:Oracle actually uses Java (1, Insightful)

Anonymous Coward | about 4 years ago | (#32791452)

The tools you're referring certainly didn't have production costs of millions of dollars. They're not very complex and a bit crappy. I do assume they have complex in-house JEE systems which might well be worth that amount though.

But Oracle cannot _kill_ Java, Java is open source. I'm pretty sure Google or IBM would gladly take over as the Java figurehead.

Re:Oracle actually uses Java (1)

M. Baranczak (726671) | about 4 years ago | (#32791922)

The tools you're referring certainly didn't have production costs of millions of dollars. They're not very complex and a bit crappy.

Well, this is Oracle we're talking about.

Re:Oracle actually uses Java (1)

Bangalorean (1846492) | about 4 years ago | (#32791472)

The 'Universal Installer' and other Java based tools can easily be rewritten - no big deal. More important than those tools, IMHO, is the fact that Oracle has been providing support for in-database Java Stored Procedures. That, I'd say, is a bigger reason for Oracle not to kill Java!

Re:Oracle actually uses Java (2, Insightful)

red_dragon (1761) | about 4 years ago | (#32791836)

It isn't just the Universal Installer that's written in Java; for some things there are shell scripts that bypass it. A much bigger and profitable product for them is the E-Business Suite, which is mostly Java with a few native code components. Letting Java languish would mean losing billions of dollars in support and maintenance fees as customers abandon EBS (and the Oracle database by extension) for more up-to-date enterprise software.

What about Google? (1, Insightful)

Anonymous Coward | about 4 years ago | (#32791422)

The article fails to mention Google, certainly one of the big players and evidently a big supporter of Java. There's GWT, there's Android, they really push hot stuff onto the dusted platform.

IBM was also not mentioned, another huge company that really pushes Java forward - although in a direction I personally don't like.

Only Morbidly Obese Aspies use Java (0, Troll)

Anonymous Coward | about 4 years ago | (#32791428)

If you weigh more than 400lbs and have Aspergers and you can't get laid and the only job you can get is cleaning out Supermarket trash then you are a java programmer. Meanwhile winners use C#.net Professional.

Doing all my programming in C# (1, Troll)

anss123 (985305) | about 4 years ago | (#32791440)

Which is pretty much Visual Basic with Java syntax. I find Java source code a tad easier to read and Javadoc make C#'s cumbersome "compiled comments" look silly. Does Java still have checked exceptions in common use? In that case I envy you guys. Scratching my head over which exceptions can spew out of a library is annoying, even if checked exceptions can be annoying at times too.

Re:Doing all my programming in C# (2, Insightful)

drewhk (1744562) | about 4 years ago | (#32791454)

I think checked exceptions are largely misunderstood. When people complain about them, they unknowingly, but almost always complain about the try..catch construct -- it is very wordy, annoying, inflexible and is almost impossible to factor out common idioms.

Re:Doing all my programming in C# (1)

anss123 (985305) | about 4 years ago | (#32791714)

Hey, just have the IDEs add "throws exception" to all the methods by default and those folks will be happy. We can then add longjmp() to temp to C holdouts to the embrace of Java, not like the IDE guys would figure out and abuse that call right?, and then finally multiple inheritance to bring in large swaths of old murky C++ code.

Re:Doing all my programming in C# (1, Interesting)

Anonymous Coward | about 4 years ago | (#32791462)

You're supposed to assume that all exceptions can be thrown from all code. That's the only safe way to develop reliable Java or C# code.

Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance. I had to work with one Indian team who claimed that using checked exceptions everywhere would prevent uncaught exceptions from ever being thrown. Then they decided to use a library that used a library that dynamically loaded some JDBC drivers that threw unchecked exceptions in some cases. Of course, their software broke, and I got stuck fixing it. But it was extremely annoying have to deal with them, having them tell me that the situation we were witnessing could never occur because they used checked exceptions in their code.

Re:Doing all my programming in C# (1)

drewhk (1744562) | about 4 years ago | (#32791492)

"Then they decided to use a library that used a library that dynamically loaded some JDBC drivers that threw unchecked exceptions in some cases. "

In other words, checked exceptions can only help when they are used.

Re:Doing all my programming in C# (1)

anss123 (985305) | about 4 years ago | (#32791562)

You're supposed to assume that all exceptions can be thrown from all code.

I disagree. I catch the general execeptions up in the code tree from where I will abort the whole opperation when they occur, putting my main focus on exceptions that are likely to be thrown - primarly on how they affect the user. Rare exceptions, even if an exception handeler can make a clean fix, are sent to the error box.

Checked exceptions also give you insight into the function that documentation often lacks. For instance I'm working on an app that connects to a database, the app have to work even when the database is down so it's nice to know which library method will cast database exceptions. It is not always obvious, had a recent bug where a method worked most of the time when the DB was down except for in certain circumstances stemming from an event handeler. In this case I wrote the library myself so I'm the one to blame, but oh well.

Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.

I did not know that.

Re:Doing all my programming in C# (3, Informative)

drewhk (1744562) | about 4 years ago | (#32791664)

"Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance."

The same is true for invoking methods through reflection. Or transforming bytecode through custom classloaders, etc.

But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.

Re:Doing all my programming in C# (1)

arjan_t (1655161) | about 4 years ago | (#32791670)

Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.

That's only partially true. If the language would only have checked exceptions and you would be coding against interfaces (often still the case with dynamically-loaded code), then checked exceptions would still work, whether the code implementing said interfaces was dynamically loaded or not.

Now the problem here is that there are also unchecked exceptions which the code might throw, but this is really unrelated to the dynamic loading. One thing that could break things though, is if you not only dynamically load the code, but also execute said code via reflection. Then indeed checked exceptions might not do anything...

Re:Doing all my programming in C# (1)

sourcerror (1718066) | about 4 years ago | (#32791484)

The thing is, that in a lot of cases you actually should use Runtime Exception instead of static ones. Actually, as far as I know Java is the only language that has static exceptions. (C++ has only runitme exceptions, scripting languages too; I don't know about C#)
The worst thing you can do is catch all exceptions silently in the outmost method.

Re:Doing all my programming in C# (1)

drewhk (1744562) | about 4 years ago | (#32791552)

"The worst thing you can do is catch all exceptions silently in the outmost method."

No, it is actually worse to have only RuntimeExceptions and handle none. In the static version, at least a code reviewer will immediately see the empty catch blocks, while in the dynamic case the problems will remain hidden.

In the checked case, when I ignore exceptions (catch, and do nothing) at least I document it explicitly in the code by writing the empty catch block. This is not true for unchecked ones.

Re:Doing all my programming in C# (1)

arjan_t (1655161) | about 4 years ago | (#32791718)

No, it is actually worse to have only RuntimeExceptions and handle none..

Checked vs unchecked is and endless debate in Java, but to add my 2 cents:

If you only have RunTimeExceptions, then at run time the error actually will surface if you don't explicitly handle them. This means your unit tests and integration tests (you do have those, don't you?) will most likely catch them.

Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't. If there's a SQLException being thrown, seriously, what can your code do about it? In practice what we see is that either exceptions get wrapped and wrapped and wrapped... up till 10 levels or more deep. Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business.

Re:Doing all my programming in C# (4, Insightful)

Eskarel (565631) | about 4 years ago | (#32791518)

C# is really more sort of the averaging of Java and C++ than anything else, and VB is now C# with a slightly different syntax(sort of wish Microsoft had the balls to just end it rather than farting around with putting god awful VB syntax onto a language which is nothing like it.

I do agree that Microsoft needs to do something about the exceptions though, not necessarily checked exceptions cause those are a pain, but some easy way in Visual Studio to get a list of exceptions that can be thrown by a call so you know what you could check for. You're also right about javadoc.

That said, LINQ is just incredible, and IIS with .NET is a hell of a lot easier to configure and tune than Tomcat, it's really 6 of one and a half dozen of the other with Java and .NET at the moment, which is why what Oracle does is so important.

Re:Doing all my programming in C# (1)

anss123 (985305) | about 4 years ago | (#32791610)

IIS with .NET is a hell of a lot easier to configure and tune than Tomcat

I find LAMP easier still, also the main webapp I run at work can't run on ISS7 so I know it's not all green hils over there. Of course I've never written anything big enough to spend any significant time on tuning. Don't make too many DB queries is my general rule.

That said, LINQ is just incredible

I've been looking for some excuse to use LINQ in my code, but the closest I've come is lambda expressions. Do see the value though.

Re:Doing all my programming in C# (2, Interesting)

Krahar (1655029) | about 4 years ago | (#32791880)

C# is really more sort of the averaging of Java and C++ than anything else,

C# is just like Java except without some of the problems and with some good things added. E.g. Java generics aren't really worthy of the name, while C# generics are pretty spiffy.

Re:Doing all my programming in C# (0)

Anonymous Coward | about 4 years ago | (#32792234)

As someone who used Java generics extensively and is now working with C#, I miss covariance and contravariance.

Re:Doing all my programming in C# (1)

firewrought (36952) | about 4 years ago | (#32792332)

get a list of exceptions that can be thrown by a call so you know what you could check for

.NET will generally document expected exceptions, but in general, you should not assume to know all the reasons that a method can fail. Even if you think you know all the reasons a method might fail today, tomorrow that call might be modified to hit a database or do something completely different and whole new failure categories open up.

If you don't know what to do with an exception (and you usually don't), clean up your resources and throw it up the call chain until you do know what to do with it (log it, tell the user, ignore it and try a fallback strategy, attempt to fix it, wait a few second and try it again, etc., etc.). Distinguishing the type of the exception only matters in special cases where it impacts your response strategy.

Re:Doing all my programming in C# (2, Insightful)

arjan_t (1655161) | about 4 years ago | (#32791566)

>Does Java still have checked exceptions in common use?

No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:

public interface EntityManager {
    /**
     * Make an entity instance managed and persistent.
     *
     * @param entity
     * @throws EntityExistsException        if the entity already exists.
     *                                      (The EntityExistsException may be thrown when the persist
     *                                      operation is invoked, or the EntityExistsException or
     *                                      another PersistenceException may be thrown at commit
     *                                      time.)
     * @throws IllegalStateException if this EntityManager has been closed.
     * @throws IllegalArgumentException     if not an entity
     * @throws TransactionRequiredException if invoked on a
     *                                      container-managed entity manager of type
     *                                      PersistenceContextType.TRANSACTION and there is
     *                                      no transaction.
     */
    public void persist(Object entity);

Re:Doing all my programming in C# (1)

anss123 (985305) | about 4 years ago | (#32791620)

That's really too bad. I got the feeling that most coders think "get it done now" rather than "get it done right". It is probably the correct attitude to take, not like you get paid extra for clean code, but still....

Re:Doing all my programming in C# (1)

M. Baranczak (726671) | about 4 years ago | (#32792002)

I disagree. A checked exception in this case would do you absolutely no good; if your application encounters an error during a DB operation, then there's usually nothing you can do to recover, so it doesn't matter if you catch the exception yourself or let the container handle it.

Letting Java languish is not the problem. (4, Insightful)

Eskarel (565631) | about 4 years ago | (#32791478)

Oracle will not let Java languish, they need Java to exist because it's part of their ecosystem now whether they wanted it or not. It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.

The issues for Java are either Oracle getting into a fight with IBM and resulting in a fork of Java or distrust of Oracle pushing a critical mass of developers away from Java and onto .NET. As to the first, Oracle has to suppress their natural desire to charge like wounded bulls for everything they own, and try not to interfere with the JCP much at all, which is a big ask really. For the second, it's already starting to happen in certain areas. There are shops out there who have spent an awful lot of time and money getting Oracle out of their DC and they don't want it back again.

Re:Letting Java languish is not the problem. (1, Interesting)

Anonymous Coward | about 4 years ago | (#32791504)

You're saying there are people who don't want any Oracle products (including Java) for religious reasons? I can assure you that there are lots of MS-haters too, but I don't believe either are a real factor.

Re:Letting Java languish is not the problem. (1)

Threni (635302) | about 4 years ago | (#32791694)

> It's a lot easier to connect to an Oracle database using Java than it is with .NET

It's hardly difficult to connect to Oracle using .net. In fact, it's identical to how you'd connect to SQL Server using .NET. Hell, I'm still supporting VB6 apps which connect to Oracle and that's also a piece of piss.

What complexity are you talking about? Installing the drivers, establishing the connection, or executing arbitrary SQL statements and stored procedures?

Re:Letting Java languish is not the problem. (1)

ultranova (717540) | about 4 years ago | (#32791814)

It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.

So... should we expect to see using non-Oracle databases from Java becoming harder?

Java isn't really built for the future is it? (1, Troll)

erroneus (253617) | about 4 years ago | (#32791486)

There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor. Multi-core and multi-processor methods are expected to transition to multiple cores. At the moment, we have the core OS managing processor time on multiple processors but that's not the efficiency that has been imagined even it if it helpful and yields good results. So what about Java? The language itself is of the classical variety. The "interpreter/VM" of Java is what runs the code, but I haven't seen or heard anything in the way of it advancing to take advantage of multi-processor platforms.

Is Java doomed to get stuck behind in the single processor world or will it actually pave the way forward by running its VM across multiple cores?

Re:Java isn't really built for the future is it? (1)

betterunixthanunix (980855) | about 4 years ago | (#32791570)

There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor.

The 1970s, 1980s, and 1990s called, and they want their predictions back. People have been saying that single core architectures have reached their limit for a long time now, so what makes you think it is definitely true now as opposed to a decade ago?

Re:Java isn't really built for the future is it? (0)

Anonymous Coward | about 4 years ago | (#32791810)

Well it's quite simple for most programmers to reach that conclusion. All you need do is ignore every piece of technical information available and pay close attention to vague controversial bullshit parroted by ignorant morons.

Re:Java isn't really built for the future is it? (1)

ultranova (717540) | about 4 years ago | (#32791842)

People have been saying that single core architectures have reached their limit for a long time now, so what makes you think it is definitely true now as opposed to a decade ago?

The fact that CPU makers have stopped boasting about their chips megahertz rating and instead switched to boasting about how many cores they have comes to mind. Also, graphics cards are massively parallel (1600 cores in Radeon 5870), and there seems to be a push to get them to work on general computing.

Re:Java isn't really built for the future is it? (1)

betterunixthanunix (980855) | about 4 years ago | (#32791940)

So you are basing your argument on marketing? The parallel processing on graphics cards is only suitable for a few problems; general purpose programs do not gain much from the level of parallelism that graphics cards offer, and the style programming that is being pushed by Nvidia (CUDA) is not at all suitable for most computing tasks. Shared memory architectures have been tried many times in history, and hit very serious walls when issues like hot spots and coherency come about; creating a 64 core shared memory machine is right around the upper limit of usefulness even for tasks that lend themselves to parallel programming, and that has been the case for a long time now (it was the case long before the current physical problems with semiconductor clock speeds). The reason that boasting about megahertz rates has ended is mainly that the chip makers do not know how to increase clock speeds any further on silicon without creating problems with power density and cooling; other semiconductor materials which can overcome these problems are known but are not yet practical or economical.

People talk about parallel programming like it is some kind of silver bullet that is going to make everything happen faster, when the reality is that we really have no idea how to improve most programs by executing code in parallel. Even if we ignore the huge amount of IO-bound code out there and focus only on those programs that are CPU-intensive, there are plenty of tasks that have too many data dependencies or that wind up create hotspots, which kill performance in parallel programs.

Worse still is the fact that single core architectures are not even being used to their full potential. x86 has tons of instructions that are unused by most programs, even programs that could take advantage of those instructions, because compilers have a hard time figuring out how those instructions can be used. There are plenty of programs that could use the SSE instructions, even in cases where there is no vector math in the code, but compilers are generally unable to take advantage of the majority of instructions out there. Claiming that we have hit the limit of single core architectures, when we are not even using them to their full potential, is not very accurate.

Re:Java isn't really built for the future is it? (0)

Anonymous Coward | about 4 years ago | (#32791884)

Mostly because the companies that actually make CPUs have given up on single-core performance, and are focusing primarily on multi-core CPUs.

Not long ago, a new generation of CPUs would have much higher clock speeds than the previous generation, in addition to being more efficient. You could pretty much count on single-core performance doubling every couple of years or so.

That's no longer the case. Now, new generations of CPUs have comparable clock speeds to the previous generation (usually between 2GHz and 3GHz), usually increasing only a little as fabrication processes improve. They're still more efficient, although less so. Performance improvements are actually coming from putting more cores onto a single die.

Intel have gone from a dual-core CPU to a six-core CPU in around five years.

Re:Java isn't really built for the future is it? (1)

roman_mir (125474) | about 4 years ago | (#32791594)

Just what are you talking about? Blaming a language for something that is an architectural decision?

I've been using multiple cores in a 2-quad core processor environment for over a year now, of-course my design allows me to do so and has nothing to do with the language itself.

Under GNU/Linux use taskset to attach a process by Id to a specific core (or to a number of cores) and start more than one JVM and have your application's architecture use that cluster correctly.

Re:Java isn't really built for the future is it? (4, Insightful)

Eudial (590661) | about 4 years ago | (#32791600)

You have an aptly chosen user name. Not only is multi-threaded programming in Java quite easy to use, Java hasn't been interpreted in quite a long time.

Re:Java isn't really built for the future is it? (4, Insightful)

arjan_t (1655161) | about 4 years ago | (#32791606)

Is Java doomed to get stuck behind in the single processor world

Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.

Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.

Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.

This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/ [baptiste-wicht.com]

Re:Java isn't really built for the future is it? (3, Insightful)

careysub (976506) | about 4 years ago | (#32791904)

... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...

Elegance? Closures? Now you have me scared. Really scared.

The most serious problem with Java today is the whole complexity of the generics feature added in Java 5. Typing container classes was fine (and the only thing any working programmer I have talked to actually uses), but as soon as you venture beyond that it descends into a nearly incomprehensible API, all in pursuit of the elusive and trivial pursuit of absolute type safety (at which it fails anyway). Angelika Langer's FAQ about Java generics is 512 pages long. One of the world's leading Java experts, Ken Arnold, cannot explain the meaning of the Enum generic class's definition, I could go on and on.

As a whole the generics is a useless and dangerous disaster. If you mastered Langer's FAQ and could actually write code using generic wildcards no other programmer could understand and maintain your code. And I am doubtful that you could yourself, 6 months later. Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field).

And the root cause of this disaster, as opposed to a useful tweak (typing containers and letting it go at that) is the search for "elegance" in a formal Comp Sci PhD dissertation type way.

What we need right now is for whoever is guiding Java development to find away to back out of the generics disaster to simplify the language and leaving only features people can actually use. This will clear the field for actual useful innovations.

Re:Java isn't really built for the future is it? (1)

arjan_t (1655161) | about 4 years ago | (#32792158)

... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...

Elegance? Closures? Now you have me scared. Really scared.

Don't be afraid for the unknown my brother. For these kinds of libraries closures actually are very elegant. Apple added a similar thing to C for their GCD library.

And about generics, they are definitely not a useless and dangerous disaster. Yes, you can go overboard with them, but when used in moderation (i.e. 'typing containers'), they work perfectly fine. Much better than having to downcast Object all the time to some type I think might be inserted into the collection.

Re:Java isn't really built for the future is it? (5, Insightful)

etymxris (121288) | about 4 years ago | (#32792204)

Generics seem pretty straightforward to me, even the "? extends Whatever" syntax. Maybe you could give some concrete examples as to the problems with generics. The only problem right now is that type erasure makes arrays of generics impossible. Hopefully they'll fix that with the next revision.

Re:Java isn't really built for the future is it? (2, Insightful)

M. Baranczak (726671) | about 4 years ago | (#32792260)

I don't think generics are a 'disaster'. More like 'potential disaster if you don't watch your ass'. And to date, I still haven't seen a better way to do it. (Your suggestion, "typing containers and letting it go at that", makes no sense; there was no way to do that without adding generics to the language, or something that works like generics.)

Anyway, it doesn't matter. There's no way in hell that they'll be removing a widely-used feature from future versions of the language. As long as we're coding in Java, we're stuck with generics.

Re:Java isn't really built for the future is it? (3, Insightful)

dominious (1077089) | about 4 years ago | (#32792324)

As a whole the generics is a useless and dangerous disaster

You keep repeating that. Citation needed.

Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

Re:Java isn't really built for the future is it? (1)

TheGratefulNet (143330) | about 4 years ago | (#32791944)

have you heard of this start-up that is 'big' in the java space?

azulsystems.com

I'm not a java expert (by any means) but I'd be curious if this is at all significant for java folks or not.

(ob disc: I worked at sun for 5 yrs and never once touched java. go figure.)

The next Cobol? (0, Flamebait)

richman555 (675100) | about 4 years ago | (#32791510)

Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

Java coders should be so lucky. (4, Insightful)

AnonymousClown (1788472) | about 4 years ago | (#32791618)

Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

Don't knock COBOL.

I know a couple of folks who are making a nice living as a COBOL programmer. And they're not that old. AND, when the majority of the IT market craps out, they always seem to have or can get a job. That's something not many programmers can claim.

Re:Java coders should be so lucky. (1)

cfc-12 (1195347) | about 4 years ago | (#32792244)

I know a couple of folks who are making a nice living as a COBOL programmer.

Glad to know pair programming works with COBOL as well.

Re:The next Cobol? (1)

arjan_t (1655161) | about 4 years ago | (#32791624)

Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

The only thing that has remained the same in about 7 years are the posts about "Java is dead", meanwhile Java is still the most widely used language and in those 7 years additions have been made to the language (generics, annotations, type safe enums, etc) and soon we'll have some extra goodies like closures and automatic resource management. Maybe those are not revolutionary, but enough IMHO to keep the language with the times.

Meanwhile, there is a lot of innovation going on in the platform, especially with Java EE and how it uses annotations for things other languages might use keywords for (e.g. annotations to make methods transactional).

Missing the point... (2, Insightful)

haydensdaddy (1719524) | about 4 years ago | (#32791548)

In a rare fit, I actually read the TFA (I know, I don't know what I was thinking), and it leaves with the feeling that Paul is concentrating on the wrong argument...

He appears to be arguing that third-party vendors control Java through the development of their frameworks and tools. While most modern-day development is relegated to gluing together frameworks instead of actual programming, I think this misses the point in the same vein as when people talk about JEE being Java.

Java is a language upon which these frameworks and tools are built. For all of the good things Sun did for Java, they had a tendency to take the path of least resistance when it came to fixing existing features and adding new features to the language. If Oracle continues the trend, or does a worse job of it as many are predicting, third-party vendors will lost interest in developing these wonderful toys and will move on to other languages that are better supported.

I for one, abhor the ownership of Java by Oracle. Sun had a tenuous grasp on it through its design-by-committee approach, and I have no reason to believe that Oracle will improve on that approach given its history. Java had some wonderful ideas behind it, but I for one have been transitioning my investments over to alternate languages that have caught up and, for the most part, surpassed Java in functionality.

Well, that's my two cents and my cat agrees with me. So there.

Hear, hear. (1)

Cyberax (705495) | about 4 years ago | (#32791886)

Yes, Java core language is stagnating. Even JDK7 has not much new features.

Java does have a nice ecosystem of libraries, but by now we've explored about 100% of what can be done in libraries without changing the core language. But there are limits, and a lot of things are just not possible to do in libraries.

For example, java.util.concurrent library is quite nice. But it's rather clumsy even with the planned closures support, any parallel algorithm is quickly drowned in the clutter of anonymous classes. In comparison, Parallel LINQ in .NET is much easier to use.

Or take QueryDSL as another example - it allows to build nice typesafe queries, but it's not really feasible to use it to query simple collections because of huge runtime overhead. While LINQ works just fine.

Reified generics in C# also make a lot of things MUCH nicer.

Re:Hear, hear. (1)

mswhippingboy (754599) | about 4 years ago | (#32792342)

Yes, Java core language is stagnating. Even JDK7 has not much new features.

I disagree. Java is evolving at a reasonably steady pace and while each subsequent release is not as radically different as its previous as in some newer languages, this is to be expected since the language is already fairly mature. Its usage however, is ever expanding.

http://langpop.com/ [langpop.com]

If you check out the link above, you can see that C# is considerably behind Java in popularity (its even behind old standbys like C, C++, PHP and Perl) which makes me wonder where the "java is dead" crowd are getting their information. Technologies like LINQ/PLINQ are great, but very proprietary in a world that doesn't have to be tied to a specific platform. Why tie yourself down to proprietary extensions when perfectly viable alternatives exist? If MS were to open-source .Net and/or LINQ, then maybe they would stand a chance of being generally accepted, and maybe even incorporated into later versions of open source language environments, but corporate IT departments more and more are beginning to realize they don't have to be held hostage to proprietary technologies (it's taken a long time, but I see it happening every day and I for one, welcome it).
Almost every third party corporate application that I've seen implemented over the last 3-4 years has been based on Java, and most of them contain open-source libraries at their core. The richness of the available java libraries and open-source components makes developing applications from scratch unfeasible from a cost perspective. What better platform to develop in to take advantage of this vast array of pre-existing, pre-tested code than Java (or one of it's offspring such as Scala)?

let Java languish (4, Funny)

nurb432 (527695) | about 4 years ago | (#32791550)

Oh wait, i thought this was a poll.. Nevermind.

Microsoft vs. Java Trailer (+5 funny) (0)

Anonymous Coward | about 4 years ago | (#32791650)

Scala (1)

Laz10 (708792) | about 4 years ago | (#32791702)

The java language isn't that important to develop any further.
It is the platform that matters and the platform will live on long after java the language goes into decline.

Currently the successor to java looks to be Scala.
http://www.scala-lang.org/

Scala compiles to java byte code, so standard java libraries will work just fine.
It is type safe (unlike ruby and groovy)
It performs about the same as java code

If you are a java developer, I will highly recommend getting "Programming Scala"

Re:Scala (1)

toriver (11308) | about 4 years ago | (#32792214)

But Scala uses a functional paradigm, and thus represents a different mindset to the OO nature of Java, and even the syntactic mindset of the C family. But yes, it is another tool for writing code targeting the VM.

An aside: How many .Net developers use F#, the functional programming equivalent there?

Re:Scala (2, Informative)

RPoet (20693) | about 4 years ago | (#32792308)

Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.

Java may not be as important (0)

Anonymous Coward | about 4 years ago | (#32791720)

but who will release, in a timely fashion, the important Java client updates to patch holes in the existing code?

Java Lives On (1)

helix2301 (1105613) | about 4 years ago | (#32791812)

Oracle will not let Java die. It needs Java for a lot of its applications plus other company's need Java so stay alive. I was just at a customers just recently that runs Novell and the entire infrastructure is OES Linux and Free Suse. All most every desktop tool and web tool was Java based.

Paying for Oracle Java? (3, Insightful)

esarjeant (100503) | about 4 years ago | (#32792086)

What about the prospect of having to pay for Oracle Java? The client would continue to be free (JRE) but if you want to compile code it will cost you. How would Java fair if there was a $100 developers license?

Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...

Re:Paying for Oracle Java? (1)

RPoet (20693) | about 4 years ago | (#32792292)

How could you "corner the market" like that? Java has an incredibly strong free software culture around it; making the compiler proprietary (it's free software today) and then even charging for it, would be Oracle Java's death knell and a free fork would take over.

Re:Paying for Oracle Java? (1)

StormReaver (59959) | about 4 years ago | (#32792386)

Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...

Don't lose any sleep worrying about that, as it has a near-zero chance of being reality. Oracle certainly could try such a move (it's in the corporate culture), but it would have no teeth. When SUN open-sourced Java, the former assumed the role of steward, and surrendered the role of dictator. There is no way that Oracle can now force people to bow down to its will with Java.

There would be short-term angst for developers, and short term profits for Oracle, but there would be an inevitable fork of not only the code, but of the name. Java (or whatever new name was given to the forked language) would continue under new management, and life would go on. The whole issue would fade away in a reasonably short period of time, and would become just minor background noise in the long run.

Given that, Oracle is not run by complete idiots (much as it may seem from time to time). Doing what you propose would be product suicide.

Re:Paying for Oracle Java? (1)

grasshoppa (657393) | about 4 years ago | (#32792390)

I would see something like that working like RHEL vs CENTOS.

Some companies would pay the fee ( for extended support? ), while others would use the free alternative.

And let's face it, there would be a free alternative. Within minutes of the announcement, a million forks would be created from the last release.

Android? (0)

Anonymous Coward | about 4 years ago | (#32792258)

Dalvik, and the language used are VERY similar to Java and the JVM. The libraries may be different, but Android appears to be a major platform. If nothing else, Android will be around, and can probably be coded into a very similar to Java platform.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...