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.
64-bit Slashdot still has a few kinks to work out.
I'm colorblind, you insensitive clod!
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.
For most people there is nothing to hold you back from running 64-bit Linux.
Except the fact that Microsoft Windows is superior in every aspect.
...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
64.0 bits should be enough for anyone.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
obviously you need to reinstall... with 128-bits Linux...
"I think this line is mostly filler"
""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."
Owning a 32 bit computer might be an issue.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
Makes a change, most people around here are joke blind.
But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...
What is it with large corporations and only creating RPM files for their software? I got the .bin file, but it just extracts to the current directory, without listing where all the files need to be copied to...
If anyone can post a quick tutorial (or list of folder locations), that would be awesome.
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 get it.
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.
My Intel processor claims that 63.99 bits should be enough for everybody.
If I have nothing to hide, don't search me
What already works for me on 64-bit Ubuntu Intrepid Ibex is this:
Sun has always made it a royal pain to use their java. 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. This version seems like more of the same, or maybe even worse. I went to the java.net page linked to from the article, downloaded the file. It's a shell script, and when you run it, the first thing it does is print out a license and ask if you agree to it. Some of the contents of the license:
So in other words, it's not open source under the Open Source Definition.
I think it's great that Sun has GPL'd their implementation of java. Three cheers for Sun for doing that. But they've proved over and over again that any open-source project they control will have a closed development process, will ignore their user community, and will be a massive pain to install and work with. So the really good thing about Sun GPLing their version of java is that now, finally, we've gotten to the point where people other than Sun -- people who Get It about open source -- can take the ball and run with it.
Find free books.
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.
Unlike Flash, Java source-code was perfectly open and available for years (it has even been GPL-ed for a while, but before that was still available). Why did anyone have to wait for Sun to release the 64-bit plugin instead of compiling one? A fairly small patch was required (long vs. size_t somewhere deep inside)...
FreeBSD was providing Java (with the plugin) for both i386 and amd64 for years now...
What does the fact, that this is news, tell us about Linux developers? First they holler at Sun to release the source, that's already available for download under GPL. And then they still would not touch it, until Sun gets around to it... "Freedom to tinker" my behind.
In Soviet Washington the swamp drains you.
Does anyone know if Sun now supports webstart on 64bit linux?
>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.
The 256GB monster is actually non-production, due to the quirks of the management in our software side they wanted to have "identical" testing capabilities vs prod. Since we are CPU licensed the cheapest way I could get them two non-prod environments to match prod was to match the prod CPU count and double the ram. This way we have room to go prod if we need to. Our DR scenario is currently to either move the prod HBA's into the non-prod server or zone the prod disks to the non-prod HBA's depending on the failure mode, the app is currently not covered by our DR SLA, but should that change then we will begin either log shipping to a like DR box or buy a second SAN for DR and use SAN replication. Oh, and to answer your questions directly:
1)Cost, Oracle RAC is expensive per transaction, it's more of an availability tool then a performance one.
2)Data transform tool and the fact that the best way we have found to maintain decent I/O performance without turning down Oracle's data integrity options is to throw more log writers at the problem, one I/O writer per core.
3)Like I said prod is only 128GB and since our OLTP DB is currently only about 60GB uncompressed I don't forsee us outgrowing a maxed box before the 3 year hardware cycle is out.
4)Currently our primary table is growing about 1.2M rows a month, but we are adding addition capabilities about twice a year so data growth is hard to quantify over a long period of time.
5)Our SLA is something like 95% during SLA hours, hardly hard to achieve with decent equipment. We recently experienced some of the worst downtime in my career due to prematurely outgrowing our old Cisco 9140's (they fell over at ~1.7Gb max traffic, very pathetic), but it was a total of about 4 hours of user visible downtime and even less for the financial systems.
6)DR is talked about above.
Other)Storage, we use a Xiotech SAN, we have 36TB of raw space over 224 spindles which is utilized for file storage, SQL Server, Lotus Notes, and multiple Oracle installations as well as for some boot from SAN application servers. Our next move will probably be to their Emprise 7000 line which will probably suck in all of the data in our current until as well as host document archiving for ediscovery. The Emprise is a beast of a system, scalable from 1TB to 1EB, the bigger limitations are the connected servers (248) and LUN's (1,024).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
An hour of DV footage is 10GB. A 32-bit offset gives you 4GB of addressable space, so that's not enough. A 34-bit offset gives you 16GB, so that's fine. Maybe you're recording raw HD footage though, let's say 1080p, so 1920Ã--1080 pixels. You're editing, so let's say you want 32-bits per channel, three channels. That gives you around 24MB per frame. Let's say 30 fps, so 712MB per second, or 2.4TB per hour. Let's say a filming session is 10 hours, so that's 24TB per file.
Take the base 2 logarithm of that, and you find you need just under 45 bits to represent any offset in it at byte granularity. If you double the horizontal and vertical resolution, you need 47 bits. If you double the frame rate, you need 48 bits. Go to double-precision floats for each channel, and you need 49 bits. If you use stereoscopic cameras, you need 50 bits. 64 bits still gives you a lot of space to play with. When your files are more than 16 exabytes, you should probably consider splitting them a bit. A filesystem more than 16 exabytes is likely to be needed over the next decade (hence ZFS), but 64-bit files are going to be fine for a very long time. Even today, very few files are over 4GB (mostly DV footage and DVD images), and we've had support for those for around a decade now.
I am TheRaven on Soylent News