People (including Ubuntu/Debian) seem to think that openJDK is just a bit slower and "less polished" but a fine drop in replacement. It has been my experience there is lot's of stuff it still just doesn't support.
The saddest and most obvious was last time I was helping a first year comp sci student they couldn't even do lab #1 in it since openjdk didn't have the fancy new output writers.
Sure you "don't need" them, and a bunch of other things it's missing, but those missing things quickly add up and start spelling lots of software that openJDK cannot run. And also first year comp sci students can't even use it for school.
It is not a drop in replacement that is a bit slower, it is incomplete and I'm tired of people not understanding this. There are things it cannot do and software it cannot run.
Can you elaborate on the missing output writer support? I had a lot of software running with Lucene/Solr and my own code and never had an issue with OpenJDK.
This will be a nuisance, because e.g. Clojure just works better with the Sun Java packages. The Sun packages don't just have performance improvements, but the Clojure devs seem to be actively targeting them. Even if this might lead to improvements to the OpenJDK in the long term it is one hell of a nuisance to have to go around the operating system package management scheme for Java. The lesson is to actively mistrust Oracle and invest more time in solutions that are independent from that company.
E.g. early versions of ClojureScript had a critical bug on the OpenJDK that gave me the impression that (many of) the core developers are using the Sun package and are optimizing for it. There is also the issue of performance, which is supposedly better with the Sun version, but I should benchmark that for my particular applications before making up my mind. What do you use in production? There is a fine line between an acceptable difference in terms of reliability and speed and being too finicky for production. I'd love to hear more about what you're using.
When you have a proprietary implementation competing with an open, compatible, one, you can have two scenarios:
1- the proprietary implementation is the dominant one and the open implementation must lag behind its roadmap.
2- the open implementation is dominant and the proprietary vendors who want to compete with it have to offer a superset of its functionality in order to compete.
In case 1, you are at the mercy of the proprietary implementor (in this case, Oracle). In case 2, everybody is free to steer the evolution of the standard without fear of getting isolated in an incompatible niche.
And Oracle's #1 priority is Oracle's profit. They'll get it even if it means turning your life into hell.
For Ubuntu I expect someone will create a PPA for Sun Java. I don't know if there's anything similar for Redhat/Fedora/Cent but wherever it's possible, I expect that will be the workaround of choice.
The way Gentoo handles this sort of thing (it does it with truecrypt) is keeping the ebuild and so forth around, but when it comes time to fetch the sources it will stop and tell you to go download the tar file from wherever it's usually at and stick it in the dist folder.
Someone will come along like sevenmachines and create a PPA with a "sun-java6-installer" to mirror the "flashplugin64-installer" that downloads the pack of binaries and installs them from Oracle's servers.
Agreed. I spent some time updating the jpackage project's nosrc RPMs to work with newer versions of the JRE. There is a lot of complexity involved in making what Oracle's JRE installer delivers integrate nicely with the rest of the system.
You can download an rpm, so it should just be a matter of conversion. At least the last time I did this, you downloaded a shell script that when you agreed to the license extracted an rpm from itself.
So it should be a little more straightforward. Of course, when yoiu roll your own package, you don't get automatic security updates, so that's still a pain.
Java-related Ubuntu/Debian packages (eclipse, openjdk, maven, ant, etc.) have always been notoriously bad and slow to update. Installing sun-java6-jdk sure made things easier but I guess I'll have to learn how to do it by hand now, just like I do with all the other Java-related software I use on Ubuntu every day.
I think Eclipse is still on 3.3 or something in the main repo! The whole java thing's a bit of a mess from a 'casual user' perspective. Some packages won't work without the sun-java6 ones. Some appear to be optimised for it. There's at least one that I know of (but can't remember the name of at the mo - it's an IDE though) that refuses to install without them!
My naïve self would have thought to try and reduce the reliance on java, but of course the cost (of any type) would outweigh any potential benefit.
http://packages.debian.org/search?searchon=names&keyword... shows Debian stable is on 3.5. That was still one version behind at the release of Squeeze, but saying 3.3 (two more years behind) is unfair. Experimental has 3.7 packages, so the situation seems to be improving.
You must be careful, however, because not every Java
platform is free. Sun continues distributing an executable
Java platform which is nonfree, and other companies do so
too.
The free environment for Java is called IcedTea; the
source code Sun freed is included in that. So that is the
one you should use. Many GNU/Linux distributions come with
IcedTea, but some include nonfree Java platforms.
To reliably ensure your Java programs run fine in a free
environment, you need to develop them using IcedTea.
Theoretically the Java platforms should be compatible, but
they are not compatible 100 percent.
They're destroying the Java ecosystem for casual users and hobby developers, and they do it on purpose. It doesn't affect enterprises and enterprise software development.
It's sad, very sad, but it's the way Oracle works.
This is unfortunate. We'd consistently get hit by a 100% CPU NIO bug by OpenJDK on Ubuntu. OpenJDK also packages Rhino in the org.mozilla package which makes it painful to use a different version of Rhino. It's definitely not a drop in replacement.
I often wondered if making the non-free stuff harder to use (Flash, Java, etc) will push free software devs to improve the free stuff. It might be good for Clojure and other Java projects to work towards having full control over their platform and distribution instead of having to rely on Oracle.
I wonder why Oracle changes that in the first place? Is it their attempt to compete with Red Hat on RHEL? Basically, this means enterprise users will have to move to Oracle's Unbreakable Linux. (Which, is ironically, based on RHEL)
"Linux users who prefer to use the thoroughly tested Oracle JDK 6 or Oracle JDK 7 binaries over OpenJDK builds packaged in their Linux distributions of choice can of course as usual simply get the gratis download at http://oracle.com/java under the same terms as users on other platforms."
So it seems only like a license change, is that true?
When I tested Hadoop, the documentation suggested Sun JDK. Even Android asks for the Sun JDK. http://developer.android.com/sdk/requirements.html I hope all these communities take active effort in supporting OpenJDK henceforth.
Interesting conclusion. This is not like the Flash situation. Both JDK's are acceptable on a technical level. The Sun one is just a bit faster and more polished. In other words: this doesn't really affect the kind of end-users that would be affected by a missing installer for Flash. Oracle is just creating a nuisance for system administrators and developers in a market that Linux is already dominating: servers. These users know how to install the Oracle packages outside of the package system and understand the licensing issue.
The problem here is not GNU/Linux, but Oracle playing politics (again). The result is that they will continue to alienate developers, while their cash cow won't suffer in the short term (hackers aren't responsible for the majority of their business, business-type decision makers are). The decision to focus on an open alternative instead of working around Oracle's antics is what makes GNU/Linux what it is. GNU/Linux isn't just a practical piece of software, but also an idea. That being said, focussing developer time on the OpenJDK seems like a pragmatic move from a practical point of view as well, because licensing reasons are not something you can just ignore when convenient (without exposing your users to a possible lawsuit from Oracle).
That is what I meant when I said that Oracle is mostly creating a nuisance for the server market. It forces sys admins and developers to jump through more hoops to get the software running on their servers (as well as to keep it updated in large deployments!). That is, those that really need it, because I'm sure some people will just switch to the OpenJDK instead, because it isn't unsuitable for production use either.
The trouble with this sort of argument is that it's not always clear what the bug is, only where it is.
For example, I work on browser-hosted user interfaces that sometimes rely on Java applets. I don't know why an applet frequently doesn't work with IcedTea. All I hear back via customers-of-clients is "Your interface doesn't work on Linux".
The advice to uninstall IcedTea and replace it with Sun's (OK, Oracle's) version is now as routine to our client's support people as telling someone with Windows troubles to reboot was a few years ago. That answer has a 100% success rate with these "bugs" so far, so I don't suppose those support staff are going to change their policy any time soon.
As a software developer, I appreciate that this is not at all helpful to those working on OpenJDK/IcedTea. However, as a guy whose rent is paid by what he earns from his clients, I can't recommend that anyone use IcedTea for anything until its well-deserved (in our experience) reputation for poor reliability is addressed.
I was using a double negative, so I never meant to or did say that OpenJDK isn't suitable for production. Apologies for the confusing phrasing if you misunderstood me, but I was stating the opposite of what you seem to have assumed.
I disagree with you. Making good free software improved GNU/Linux position (GCC, Linux kernel, Apache httpd, python and may other successful projects) instead just providing what vendor is shipping binary (drivers for graphic cards, Sun-Java...) All good free software projects would not exist if we ignore them and use proprietary software instead, and community could not have impact on features that are important.
And you can never ignore the possibility of the proprietary software vendor deciding to make your life hard. With free software it's you, not them, who are in control.
As the author of this "crap", I am taking the opportunity to detail this position.
If you are interested in such issues, you are probably aware that Oracle has made the openjdk-7 the base target development of the JVM. Proprietary versions (sun-java7 is you will) are based on the free version.
This is the opposite of the current version (6).
If we do not encourage users to switch to the Openjdk, bugs won't be fixed in the 6 or 7 for a while.
It just seems to me like reinvention of the wheel for its own sake. Why not just make it as easy on the user as possible by providing very easy installs for the most well-developed software, and for more experienced users, continue providing these open-source efforts?
Seems like the same thought process at work that brought us cruft like the Unity UI in 11.04, then forced it on users as default, instead of just offering it as a new, less-stable alternative.
We are not reinventing anything. We are dropping a package which won't be supported anymore.
More over, JDK/JRE 7 is already in the Debian archive and available.
It is not a drop in replacement that is a bit slower, it is incomplete and I'm tired of people not understanding this. There are things it cannot do and software it cannot run.