Canonical To Remove Sun Java From Repositories, Users' Machines 307
New submitter an_orphan writes "Apparently, Oracle's 'Operating System Distributor License for Java' is expired, causing Ubuntu to not only remove sun-java from the partner repository, but from user's machines."
An the point is? (Score:5, Interesting)
To shoot oneself in the foot?! I just don't get it. Wouldn't Oracle want to have their platform deployed as widely as possible? Someone's asleep at the helm. Just like at the media companies. Seems some big corporations these days are like chicken running around headless...
Writing was on the wall (Score:5, Interesting)
Gentoo saw the license expiring, and did a proactive thing: flipped the "fetch restriction" flag back on, forcing users to pull it manually and slap it into the right place to install/upgrade.
Re:Is this April first? (Score:5, Interesting)
On Linux, most java developers consider that OpenJDK is the default implementation and that Sun JDK is more or less discontinued.
And yet, a customer that I used to support has an app that will not run on OpenJDK, only on Sun Java. I do not know if it is sniffing the JVM or if it makes use of an undocumented feature AKA bug but it won't even load with OpenJDK. No, I don't have the source.
Not a fan of IcedTea (Score:5, Interesting)
I have encountered numerous problems in recent years with Java code that simply doesn't work on IcedTea. It's not doing anything clever or undocumented. It runs fine on Windows, on MacOS, and on the same Linux boxes but with a different Java run-time. On some of these projects, we had so many problems that we explicitly no longer support IcedTea and won't even consider support requests from customers who insist on using it.
I don't know about any other JREs based on OpenJDK, but IcedTea is so bug-ridden as to be unusable, and has been for a long time.
If only Java were always Java (Score:4, Interesting)
I work in a Java shop. We run Sun Java 6 on a mix of Solaris and Ubuntu. I'll be handrolling a deb [github.com] from the Sun Java tarball precisely because not everything can be trusted to work identically between Sun Java 6 and OpenJDK 6.
We just recently hit a weird bug which turned out to be a "how did that ever work?" moment - revolving around different implementation-specific behaviours in Sun Java 6u24 for Solaris SPARC and Sun Java 6u26 for Linux.
We'll be moving to OpenJDK, but only after thorough testing. OpenJDK 6 is a proper Java, but we've discovered the hard way not to make any such move without thorough testing. Because programmers are human and bugs happen. Never trust, always verify.
Re:"from user's machines" (Score:5, Interesting)
No, they're just going to remove it. If you want OpenJDK, you have to install that by hand.
For almost all users, OpenJDK is just fine and is the one to use. (e.g. any Java plugins in the browser, almost any Java app). Anyone who is affected by this went to some effort to install Sun Java by hand specifically.
Re:An the point is? (Score:3, Interesting)
I have ten years' Solaris experience. Oracle buying Sun was when I took my boss and my boss's boss aside and strongly put the case that we needed to get the hell off Solaris immediately and go to Linux. (That I was advocating against my own CV was persuasive in itself.)
We commissioned a new box (12-core x86) to run a proprietary Java app; Linux versus Solaris would have made no difference; but Oracle charged another £300 for one year's Solaris licensing when CentOS was free. I HAVE NO IDEA WHAT THE HELL THEY THINK THEY'RE DOING.
Re:An the point is? (Score:5, Interesting)
It's being replace by OpenJDK. It was planned to happen like this for years. This was planned obsolescence with a gradual move to OpenJDK. Their is no surprise here except for those who didn't know it was coming. The summary is inflammatory but if you read the article you see that this is nothing really.
Re:Is this April first? (Score:2, Interesting)
The single, centrally-managed, integration-tested and conflict-resolved tree is sort of the main advantage of Debian, though. I can see alternate possibilities, but they would be quite different models for distribution management.
Compared to the situation on, say, OSX (which I use more often these days), what I like about Debian's one tree is that there's less buck-passing. If it's in Debian, it's a bug somewhere in Debian. I might've reported it to the wrong package, but then the maintainer will usually reassign it to the right one, not just throw up their hands and say, "sorry, not our bug" like you get with reporting bugs to Apple. Sometimes they'll forward the bugs upstream and wait for a resolution, but they'll also try to figure out how to mitigate impact or incompatibilities locally, if possible. I'm not sure how you could maintain that working structure without the single tree.
Re:"from user's machines" (Score:4, Interesting)
I'm curious. What specifically is lacking in OpenJDK that causes your project to be incompatible? Finding out from someone who's been-there-done-that is much preferable to hitting that specific brick wall yourself.
I had thought it was only a few things that were different - sound (fixed), serial IO (fixed... I thought) for example.
Re:"from user's machines" (Score:4, Interesting)
Well, you're going to have a problem in the future, because Oracle is replacing Sun's Java with OpenJDK. It's going to be the "real" java from now on. The summary, like usual, left this important fact out.
Almost right, but not quite. As I understand it, Sun's (now Oracle's) JDK will still exist, but it will no longer be the Reference Implementation. OpenJDK will become the Reference Implementation.
This does, of course, mean that OpenJDK will be the "real" Java, and that there should (in theory) be no differences between Oracle JDK and OpenJDK— and if there are differences, then it's Oracle JDK that's wrong. But Oracle's JDK will still exist.