Slashdot Mirror
64-Bit Java For Linux
LWATCDR writes "First we got 64-bit Flash; then the beginnings of 64-bit Wine; now Sun is providing a 64-bit Java plugin. For most people there is nothing to hold you back from running 64-bit Linux."
← Back to Stories (view on slashdot.org)
Looks blue to me
Linux has had 64 bit java for donkeys years... *rereads summary* - oh, Java browser plugin. A piece of the 90s I was hoping we'd all left behind.
There are shills on slashdot. Apparently, I'm one of them.
Lack of 64-bit {Java,Flash,Wine} doesn't hold you back from 64-bit Linux. A decent Linux distro can handle both 64-bit and 32-bit binaries.
Most of the 3rd-party applications my work run only work with with java runtime 5.0 and do not work with 6.0. Until sun provides a 64-bit version of Java 5.0 then I will be stuck on the 32-bit version with a 32-bit browser.
...that is all.
yup, very much about time. All of us sysadmins in Java shops have been hitting the 4 GB maximum for awhile. Java really does love the memory
The article implied that IcedTea (OpenJDK) is already 64-bit. My system reports the plugin as a 64-bit shared object. This release from Sun just makes it part of the official Sun Java download.
$ rpm -ql java-1.6.0-openjdk-plugin-1.6.0.0-7.b12.fc10.x86_64
$ file /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so
I don't think you quite understand what JavaFX is... JavaFX is an alternative way of creating Java applets, which will run on Java Plugin.
The simplest thing you could do, is use the "alien" package to convert it to a .deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.
As for where the Java files go, they usually go under /usr/lib/java or /usr/lib/jre if I recall correctly.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
Well, if it were running on 64-bit java instead of 64-bit perl, it wouldn't - java ints are still only 32 bits in "64 bit java.
Someone forgot to future-proof their language. 10 years from now, when you're running a 128-bit cpu with a quarter-terrabyte of ram, those 32-bit signed ints are going to look mighty quaint. "What do you mean, I can't store the [file size|number of inodes|ipv6 address|whatever] in a 128-bit int? What do you mean, 128-bit java doesn't have 128-bit ints? You're shitting me, right? This is 2018 ... what's gonna happen in 2038 - we gonna have a 2k38 java problem? No? Why should I believe you? You can't even right-size your ints ..."
It includes a plugin and javaws support. The two major things sun java 64bit has been lacking for years. It is still lacking the rim.cgi, but I have never had a need for it.
The plugin needs some polish. It doesn't properly declare it's version. Which makes a kvm application I use fail, because it tries to check the version.
Havoc Penington, the bane of my Linux desktop.
Yes, we have one we payed a few hundred grand for. SungardSCT can suck my balls. Not only does it only work with java 5, but it has to be the exact right version. Do the wrong patch and its all over.
The simplest thing you could do, is use the "alien" package to convert it to a .deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.
As for where the Java files go, they usually go under /usr/lib/java or /usr/lib/jre if I recall correctly.
Alien is not going to fly as Debian is in the midst of moving Lenny out the door and this would first start in Experimental, then move to Unstable/Sid, which need to make sure they are lintian clean. I'm going to file a reportbug on this with the owners of openjdk-6 and get this moving into an update to the openjdk-6 all around.
>apt-get install openjdk-6-jre openjdk-6-jdk icedtea-gcjwebplugin
>Sun has always made it a royal pain to use their java
You are criticizing sun java, but that *is* sun's Java implementation. The only part that isn't is the icedtea-gcjwebplugin.
>For years they've always wrapped everything in click-through licenses, so you couldn't just download it and install it using your distro's packaging system.
Huh?
For years I've been able to download and install sun java through ubuntu. Before they rebranded it as "openjava" you could still download it. The ubuntu package manager would *pop up* that clickthrough license that you are talking about.
>, it's not open source under the Open Source Definition
Not being open source doesn't stop it from being used on Linux... Most production Linux systems have proprietary software on them, especially proprietary drivers and firmware. You probably have some on your box and don't even know it.
For that matter, it's impossible to have a completely open source system because the hardware itself is not open source. Stopping at the software layer is totally arbitrary. All Linux users have *some* level of comfort with proprietary technology.
For that matter, Sun controls Java's language definition, so the language itself isn't really open. If you want an open platform, use C++, Python, Ruby, Javascript or any other language that is community controlled or standards based. Java is really an awful language, so I don't understand what your holdup is. You need to use Java, but not Sun Java? Use Java or don't, but don't Use Java and try to do it in a stupid way that will never work properly
People widely use Sun Java in production environments because the alternatives are buggy as hell. The "openjdk" you reference is actually just sun java repackaged, not an independent effort, but I used the older open source versions of java back in the day, and they were all awful and buggy. GNU Classpath in particular just does not implement much of the java libraries.
Write some stuff in C#/.NET sometime. Especially the embedded version. You'll see why. Every time MS puts out some patch...stuff breaks. Why? Because they do crap like this.
I have an embedded platform that has the .NET 2.0 binaries on it, as well as a 3.5 version. And I had to hack that one in from binaries from Visual Studio manually. The 2.0 binaries don't run on 3.5. The 3.5 binaries don't run on 2.0. It *sucks*.
So - if you suddenly doubled the size of an int it would break backwards compatibility and do this sort of horrible crap to Java. People who use java 1.2-1.6 would need their 32 bit ints. If you wanted the same box to run your 64 bit int Java, you'd need two sets of binaries. And a way to switch between them.
Trust me, you don't actually want this.
Weaselmancer
rediculous.