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)
what is this, moulin rouge ?
Read radical news here
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.
I finally got things setup just the way I want them in my 32-bit install and now the only things that were keeping me from running 64 bit are fixed. Obviously, I now have to reinstall.
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.
The time has come to begin discussing 128 bit computing.
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.
My employer recently outsourced timesheets to ADP, and ADP uses a horrid Java plugin. Hopefully this will get it working in Linux (well, when the site is stable enough to work--I expected better of ADP).
Okay, on one hand, native 64 bit apps are good because they speed up data execution--in theory. On the other hand, is this really "stuff that matters"? This isn't new technology. I read slashdot so I can get news on stuff in the industry that has some kind of impact, not to hear about product feature announcements. In other news, a network admin noticed the linoleum in the corner of the slashdot server room curled slightly today. x_x
#fuckbeta #iamslashdot #dicemustdie
""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"
Buy and build a nice 64 bit system, just to load it up with bloatware... nice.
Skip...
So... the most desirable applications for 64 bit Linux are virtual machines to run applications meant for somewhere else?
So much for the "mainstream" myth.
It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.
Not that it matters now. Sun has already lost. They have zero desktop adoption and aren't going to get any, because they treat their biggest evangelists and early adopters like crap (flash for linux? sadly, yes). As a developer, I haven't been using JavaFX at ALL. No browser adoption, doesn't run on my chosen platform, doesn't show any interest in making my platform a priority. Why the hell should I write an app that requires yet another 30 meg download?
I get all the vendor lock in, it's not open source so it's evil arguments. Save them. This is about Sun totally missing the boat, and doing nothing to fix the problem.
But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...
For most people there is nothing to hold you back from running 64-bit Linux.
Except madwifi-ng drivers. I can't even count how many times people have bugged me about their Atheros cards not working in Linux, only to find that they were running a 64-bit distro.
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
.
Dang pesky 32-bit MacBooksPros!
.
Though a big Java fan, Java plugin into a browser ==fail. They should scrap it and get us a 64-bit javafx plugin.
Seriously! This is great news. I'm buying new hardware right now!
Be still my heart.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Been using 64 bit Linux for a while and never once had I needed this Java that you speak of.
Please provide more information as it sounds useful. Is this some sort of Ad-blocking software, a browser accelerator, or a bookmark saver?
It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.
Many cisco router web-management applications are crappy java programs, and will work with one AND ONLY ONE ancient version of java.
I think it's cisco's way of making newbies learn to configure routers from the command line.
They're not the three most desirable apps on Linux, they're the three apps that hadn't yet gone 64-bit.
Just an example of something that doesn't work in 64 bit... not that it holds me back.
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
IBM's 64-bit Java for Linux has been out for a long time...
http://www.ibm.com/developerworks/java/jdk/linux/download.html
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.
All I need now is the ubuntu update manager to give me the option of a 64bit upgrade without a complete reinstall.
sheesh
Check me, please ...
Doesn't Java have just about the slowest memory management ever created? Why would I ever run a program written in Java that needs over 4GB of data segment **inside** a browser JVM?
Seriously folks, why?
While I'm at it, why would I need a 64-bit browser? I certainly won't have that much data and integers and pointers that are 2x the normal size isn't good for any browser.
It isn't like 64-bit is twice as good as 32-bit. That's just something all the 64-bit crazy people who don't understand crap think.
BTW, I previously worked porting C/C++ code to Dec-Alpha machines in the mid-1990s, some of the first 64-bit UNIX code created.
So, when we're going to have a 64 bit Skype? And a 64 bit Google Earth?
And thus is the problem with Java. The "run anywhere" just doesn't hold any water.
Java is just 90's shit like practically everything from the dotboom era. I remember so many failed Java projects from back then. So many...
The question is not "What is holding back 64-bit computing?"; the question is "What compelling reason is there for upgrading?". Short of hosting databases or crunching numbers, there really is no immediate reason. And if you are browsing the web on a database or scientific server, shame on you (although I don't see why you wouldn't just use a 32-bit browser build).
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.
Except when you're talking about Java 6.
I don't know what the hell Sun did with Java 6.
I'd never had compatibility problems with any previous version, but 6 was full of them.
However, I believe 6u10 is finally a Java6 release that's actually safe to use.
Advanced users are users too!
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.
Doom 3 is still lacking a 64-bit binary.
Does anyone know if Sun now supports webstart on 64bit linux?
RealPlayer: Buffering...
...
...
And this is from a joke earlier this month.
>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.
"For most people there is nothing to hold you back from running 64-bit Linux."
yeah apart from the lack of a native wireless driver that works properly on my laptop you insensitive clod!
So I can finally junk all the 32 bit stuff.
And to cap it all, the JVM is utterly non-portable, so much so that barely 1/4 of the highly varied boxes in my computer room complete the installation cleanly
perhaps you need to take the 'how to double-click install.exe' course again?
i call you an epic fail! :P
[ i know i shouldnt feed the trolls, but i'm bored ]
Why in the hell would you want to load PDF into your web browser session?
Even when using Acrobat, I detest opening it in the browser. It puts limitations on the reader as well as blocking functionality of the browser enough for it to feel wrong (i.e. one window with two likely search dialogs, one of which has nothing to do with the actual PDF being read). If I forget and do Ctrl+F, I spend a couple of seconds confused that it found nothing before remembering that it was a pdf in a browser not normal content.
Nowadays, I prefer Evince for day-to-day pdf reading (some special cases Acrobat still has features for, but when those are not needed, I prefer the clean Evince interface).
XML is like violence. If it doesn't solve the problem, use more.
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.
Wouldn't it be a better world without Java?
If so, I hope they use web start to keep their deployments in sync with the client's native system.
The great thing about web start is that if you need 1.3, 1.4, 1.5, or 1.6 JVM's installed, you can run each independently using the application's JNLP settings without having to fiddle with getting the right JVM in the application's path.
That said, Having done extensive work on Java Web Start for an enterprise app, Sun doesn't make the technology very easy for people to create web start apps without a lot of knowledge/work.
Bye!
So basically the article says2008 is the year of 64 bits Linux?
AFAIKT, this works great. The library plugin name isn't that obvious though - for firefox 64 bit, you need to symlink (in .mozilla/plugins directory):
libnpjp2.so -> /usr/lib64/jre1.6.0_12/lib/amd64/libnpjp2.so
My test site[s] work great.
http://spaceflight1.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/JavaSSOP.html
About bloody time
It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.
Of the things I need Java for, the only thing that survives Java 6 is Puzzle Pirates.
Finally! A year of moderation! Ready for 2019?
> perhaps you need to take the 'how to double-click install.exe' course again?
Sure, try it. Install the 64 bit Windows JVM and seen if you can find any java applications that actually work with it.
Azureus for example claims that no JVM is installed.
Java has its uses (though in my very personal opinion the Desktop is not among them), but portability is not really among the things it provides.
...When CS4 runs natively on 64bit Linux. Some of us need that shit for our education/jobs you know?
My 64-bit work environment never needs these plugins, I don't miss them. Web browsing is much better without them.
The biggest reason of all is interop. A piece of Java code that runs in 32 bit mode successfully will wrap around and work exactly the same on the 64 bit platform. Perl will work differently. if a piece of Java calls a piece of identical Java and one is on 32 bit and the other 64 bit then they will work properly, Perl will behave erratically.
Basically its the difference between a language that has been designed for longevity (Java) and one that just defaults to what ever is around (Perl).
Defaulting to what the processor has is the opposite of future proofing as it ensures that your current code WON'T WORK PROPERLY IN THE FUTURE. Sorry to shout but it really is quite important. The Java code will work the same on 32 bit and 64 bit versions while the Perl will work differently, thus it will not be future proof.
To really future proof your code what you need to do is plan for those things and assign your file size to be a long and guess what Java returns a long.
Perl and Design go together in the same way as Illinois and Probity.
An Eye for an Eye will make the whole world blind - Gandhi
I wish they did. Then our support reps wouldn't have to go out and uninstall java updates when some tech accidentally updates java while he is out fixing another problem.
OWWW now I have to switch to 128 bit just te keep up my elitist appearances
Gwenole Beauchesne has committed a lot of fixes in the past few weeks; the latest version is quite stable. In fact, it never crashes the browser for me, at worst the plugin instances die but a simple page reload fixes it.
Separating the plugins in another process allows Fedora 9+ to isolate them in their own, limited SELinux context. Even if there's a performance price for it, it might well be worth it.
Here's a clue for you buddy - you CAN'T just install the 64bit JVM. You need both the 32bit JVM and the 64bit JVM. :-) I run into this all the time with app servers where the 64bit JVM actually makes sense. Azureus surely doesn't need it.
Portability? I can't count the number of times I've copied a jarfile from one platform to another and had it just work. Java suffers from dependency hell just as much as a the next platform, which is perhaps it's biggest deficiency...
Except the lack of a compelling reason to run 64-bit Linux on the desktop.
Seriously, what can I do on a 64-bit desktop Linux computer that I can't do on a 32-bit Linux computer?
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
64bit computing is coming here slowly. I jumped on 64bit computing as soon as Adobe released Flash 10 and I am loving it.
What? I have written several Java programs. I have only had that happen once and it was because I did a really sloppy hack.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's a program that turns Usenet into human-readable form, not some sort of Web3.0/push/feed/buzzword thingie that beeps your cell phone whenever your girlfriend goes to the can. (Just thought I'd clear that up for you younguns.)
Pan is 32-bit and OK but I find all sorts of nagging problems with it. The biggest is that if you try to get headers from a newsgroup with lots of messages (say, over a million) it just hangs.
Running Windows Usenet clients in Wine is one solution, but I'd really like a FOSS solution.
Anybody got any suggestions? I'm an old fart and won't give up my Usenet until they pry it from my cold, dead fingers.
So not 32-bit for the plugin, but 32-bit for the app. At this point, I'm not overly bothered by the presence of extra libraries to run independent applications. I'm just bothered by circumstances like Firefox, where the browser requires some 64-bit to work, but the vendor provides 32-bit. And before everyone says 'nspluginwrapper', that helped, but flash was a lot more flaky than either the 32-bit install or the 64-bit native plugin.
Sure, I agree that a 'pure' 64-bit environment sounds cleaner, but practically speaking it is of inconsequential functional impact, given how the distributions successfully provide both concurrently.
XML is like violence. If it doesn't solve the problem, use more.
Now, after 64-bit flash, and 64-bit java, we now only miss a 64 bit Luxtrust libgemsafe module... So, Luxtrust, when are you going to move?
https://bugzilla.mozilla.org/show_bug.cgi?id=440964
I just tested this one.
From what I have understood, Jave 6 is *completely* compatible with Java 5. It ships with more integrated libraries and the performance has been improved, but all Java 5 code should run flawlessly on Java 6.
The only reason why these Java 5 apps at your work refuse to run with Java 6 is because of a buggy version check within those applications. Instead of checking (version>=5) they are checking (version==5), which is simply a bug that should be fixed in said software. Complain to the companies that developed these 3rd party applications and file this as a bug report.
It sucks big time!
The enhancement request asking Sun for this was submitted in January 2003.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695
No more complaining about Microsloth being slow to deliver...
I suspect that when that time comes around someone will implement a JVM with a larger primitive than Java's long (think 64 bit int), but in the meantime use this:
http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html