64-Bit Java For Linux 387
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."
This discussion has been archived.
No new comments can be posted.
64-Bit Java For Linux
Related Links Top of the: day, week, month.
Work is the crab grass in the lawn of life. -- Schulz
Re:Developers section red now ? (Score:4, Informative)
Looks blue to me
64 bit Java? (Score:5, Informative)
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.
Re:Developers section red now ? (Score:3, Informative)
I think the red title might be a "new/hot off the press article" color. I saw it as well, but refreshing it changes it back. At least, that's my guess.
64-bit and 32-bit binaries (Score:5, Informative)
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 my 3rd-party apps do not work with Java 6 (Score:3, Informative)
Re:64-bit and 32-bit binaries (Score:3, Informative)
Re:About time! (Score:4, Informative)
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
OpenJDK already 64-bit (Score:5, Informative)
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
Re:64-bit and 32-bit binaries (Score:2, Informative)
Re:More Java please? (Score:4, Informative)
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.
Re:64-bit and 32-bit binaries (Score:3, Informative)
Get a non-crappy wireless card.
In all seriousness though, my wireless card (Intel 3945 ABG) didn't work with kernel 2.6.25 x64 (though it did in 2.6.24 x86), but then I upgraded to 2.6.26 x64... and it works flawlessly, without redoing any wireless configuration or reinstalling anything else. Even the LED blinks appropriately :) (I wasn't even trying to make the wireless work when I upgraded the kernel, I was trying to make my audio work. Still no luck there.)
Re:no DEB files? (Score:4, Informative)
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.
Re:64-bit and 32-bit binaries (Score:5, Informative)
Re:64 bit Java? (Score:5, Informative)
Linux has had a full-featured 64-bit Java plugin that even includes LiveConnect [wikipedia.org] support for at least months [softwhere.org] via IcedTea [wikipedia.org], a special build by Red Hat of the official OpenJDK source tree. For example Ubuntu 8.10 ships this 64-bit plugin as the icedtea6-plugin [ubuntu.com] package, which I have been using for the past 2 months. And, no, I am not talking about the GCJ or Blackdown Java implementations which are significantly more buggy or incomplete (lacks LiveConnect support).
What is new today is that Sun just released a development build of Java 6u12, build b02 [java.net], which includes the 64-bit plugin. However technically we still have to wait for a couple months before 6u12 is officially released. But again you can already get a 64-bit plugin based on essentially the same source tree via IcedTea.
Re:64 bit Java? (Score:5, Informative)
Actually, the way I understand it, it's for those who want to use the plugin with a 64-bit browser (I didn't realize that was not possible until now). There's no such thing as a "64-bit Java app", only 64-bit JVM implementations.
Can anybody name a good reason to develop new code in the environment? Yes a lot of legacy stuff was created in the 1990s while Java was the new shiny for people too blind to see (or with a PHB too blind...) the myriad problems but new projects?
You're joking, right? Java Applets are dead and buried - and with good reason, they were a horrible hack from the beginning - but Java itself is one of the most important languages we have.
I know Java-bashing is a popular Slashdot pastime, and certainly it's not the most exciting and sexy language out there, but it's popular for a reason. It's got its share of problems (gasp! something that isn't perfect!) and more that its share of outdated myths (gasp! modern JVMs perform well!), but it strikes a pretty good balance between abstraction, performance, and complexity (much as I hate to use this argument, not every programmer out there is a rock star).
I really want to hear what you would recommend as a wholesale replacement for Java. I'm pretty sure I don't know of anything that's as broadly applicable.
(Plus, with projects like Scala and Clojure it's looking increasingly like the JVM isn't going anywhere any time soon, regardless of Java's fate)
Re:64 bit Java? (Score:3, Informative)
Re:Developers section red now ? (Score:5, Informative)
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. [blogspot.com]
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 ..."
Works! But needs a minor fix (Score:4, Informative)
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.
Re:Most of my 3rd-party apps do not work with Java (Score:4, Informative)
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.
Re:no DEB files? (Score:5, Informative)
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.
Re:already have other options (Score:3, Informative)
> Some of the contents of the license:
Yes Sun laywers are a bunch of dicks but remember that this is prerelease software. Normal releases od java don't have some of those nasty bits in the license and we can hope that the license will get improve as they continue the Open Source process with java.
A few posts above I slag Java pretty hard, just trying to be fair. :)
Re:64 bit Java? (Score:5, Informative)
that *is* sun java (Score:4, Informative)
>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.
Re:Developers section red now ? (Score:2, Informative)
Re:Developers section red now ? (Score:3, Informative)
jint == int32_t
jlong == int64_t
Deal with it. When 128 becomes an issue there'll be a jlonger, or something like that. (jquad may be used for quad precision float)
Re:64 bit Java? (Score:3, Informative)
Yea and a decade ago that 'enterprise' stuff was steaming piles of VB. Now it's racks of big ass servers or blades groaning under badly designed layers and layers of Java 'middleware'. Not sure things have actually improved much.
If you had worked with either of them you'd know that yes, things have improved tremendously. Alas, it's evidently you haven't used Java for a real-world project of a respectable size so...
If you have insane amounts of CPU and memory to throw at it to cover up the slowness you can keep a team of medium skill code monkeys permantly employed maintaining all that interfacing between the various middleware products from different vendors.
Which is much better than C++, where you need obscene amounts of CPU and memory to throw at problems, or rather, to all of the "me too" libraries your medium skilled code monkeys used to build your nifty little problem-solver that only they can extend because the code is such a mess. Or were you suggesting Python, Ruby et al which, while excellent languages in their own right, can't beat Java's performance anywhere, anytime?
What? Must have missed it.
Yes, you did. Do you even work in IT? seriously.
Silly me, I thought the primary reason everybody rejected Java and Vista was the bloat and suck.
Silly me, I thought that nobody outside of the hardcore (read: fanatical) C coders rejected Java, but what do I know, I'm only somebody working in IT and looking at available job postings.
No, you notice when a small app starts sucking up all available memory.
And that's when you know the app was coded in C or C++, and the programmer sucked. Or was lazy. Or just a bit careless. Or had a bad day at home. Or one of the other million reasons a C/C++ app may leak.
I've got a cheap crappy basic cell phone. You can almost see individual pixels draw on the darned thing...
Try to find the problem. Hint: it's not Java.
That's a good thing - trust me (Score:5, Informative)
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.
Re:no DEB files? (Score:3, Informative)
1. Sun likes to 'default all java applications to /usr/java/jdk-version or /usr/java/jre-version so feel free to copy the files to any directory you please.
2. Add my_java_path/bin to your .bash_profile or .bashrc file so that you can run java applications from the command line
3. Link my_java_path/lib/amd64/libnpjp2.so into your Firefox plugins directory (forget where it is)
Restart firefox and you should be able to load any applets. You could also set JAVA_HOME to my_java_path, but that shouldn't be necessary.
Re:The source was out there for years! (Score:1, Informative)
except ofcourse that we DID "tinker" ourselves, look at icedtea...
perhaps you yourself should direct your "behind" towards the interweb and learn some facts, before you spew the crap out..
Re:Skype? Google Earth? (Score:3, Informative)
Re:OpenJDK already 64-bit (Score:3, Informative)
IcedTea != OpenJDK != Sun's JRE.
Rather, in approximate terms...
OpenJDK = Sun's JRE download - binary blogs - Java Plugin - Java Web Start
IcedTea = OpenJDK + GNU Classpath replacements + gcjwebplugin + netx
So the IcedTeaPlugin.so is actually cobbled together from gcj. Red Hat decided they couldn't wait for Sun, so they sponsored GPLed IcedTea replacements for applets and jnlp.
Today's announcement is that the 'official' Sun plugin now supports 64 bits. NB It's a totally different code-base from the IcedTea plugin and still isn't GPLed, with no definite time-frame.
Re:Wake me up... (Score:2, Informative)
Re:Developers section red now ? (Score:3, Informative)
The D programming language (the Digital Mars one) has already reserved a pair of types, cent and ucent, for future use as 128-bit signed and unsigned integers.
Re:That's a good thing - trust me (Score:3, Informative)
The latter is precisely what you do in Java when you say "int" - you explicitly state that you want a 32-bit, two's complement signed binary integer. This is by design of the language, and expecting "int" to remain that way is certainly not an invalid assumption or a bug.
The reasons why ints are 32 bits (Score:3, Informative)
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 [sun.com].
Perl and Design go together in the same way as Illinois and Probity.