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."

128 bit computing is around the corner

[Anonymous Coward]

The time has come to begin discussing 128 bit computing.

No debian lenny support

[GPLHost-Thomas]

But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...

Madwifi-NG

[8086ed]

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.

Re:Madwifi-NG

[dido]

Well, I have a laptop that has such a card, and well, I found a version of the MadWifi drivers that works well enough [madwifi-project.org] on my 64-bit Gentoo. I must admit though that the search was incredibly frustrating, but given the recent news that Atheros has gotten more [slashdot.org] open [slashdot.org], the situation can only improve with time.

IBM Java

[Anonymous Coward]

IBM's 64-bit Java for Linux has been out for a long time...

http://www.ibm.com/developerworks/java/jdk/linux/download.html

already have other options

[bcrowell]

What already works for me on 64-bit Ubuntu Intrepid Ibex is this:

apt-get install openjdk-6-jre openjdk-6-jdk icedtea-gcjwebplugin

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:

• 3.1 Licensee may not duplicate Licensed Software other than for a single copy of Licensed Software for archival purposes only.
• 3.3 Except as otherwise provided by law, Licensee may not modify or create derivative works of the Licensed Software, or reverse engineer, disassemble or decompile binary portions of the Licensed Software, or otherwise attempt to derive the source code from such portions.
• 3.5 Licensee shall have no right to use the Licensed Software for productive or commercial use.
• 6.1 This Agreement will commence on the date on which Licensee receives Licensed Software (the "Effective Date") and will expire twelve (12) months from the Effective Date, unless terminated earlier as provided herein.
• 6.2 Either party may terminate this Agreement upon ten (10) days' written notice to the other party.

So in other words, it's not open source under the Open Source Definition [opensource.org].

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.

The source was out there for years!

[mi]

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 [freshports.org] (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.

Re:Developers section red now ?

[afidel]

I'm already running computers with a quarter terabyte of ram you insensitive clod.

Seriously, the data warehouse server I'm implementing this week is an HP DL585 G5 with 4x AMD 8378 and 256GB of ram using 2x Brocade 815 8Gb HBA's =)

Re:64-bit and 32-bit binaries

[j79zlr]

64-bit flash did fix those issues. You can download the alpha version here [adobe.com]. I've been running it on Gentoo for a few weeks without issues.

Re:128 bit computing is around the corner

[Anonymous Coward]

~128 bits = 2km * 2km * 2km cube of silicon.
~168 bits = every atom on earth.
~190 bits = every atom in the solar system.
~262 bits = every atom in the universe.

Re:Developers section red now ?

[Profane MuthaFucka]

If you're using a file that requires more than 64 bits for the file pointer, you may be happier using a database.

I'm just sayin'

Re:Developers section red now ?

[afidel]

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).

Re:64 bit Java?

[julesh]

Can't recall seeing a big gaping hole on a page where a Java Applet would be in at least a year. And this story is only important if somebody out there has a burning need to run a 64bit Java app... in a web browser.

Which you can't do, because Java runs all applications with a memory usage limit, which for an applet there's no way of changing, so you'll get the standard limit.

Actually, it's important if someone wants to run a 64 bit web browser and use Java, because 64 bit browsers can't interface with 32 bit plugins.

IIRC, there's now also a 64 bit flash plugin available (another recent release). This might mean that 64 bit linux distros no longer need to install 32 bit compatibility environments by default, which would be a welcome improvement.

Re:That's a good thing - trust me

[Oberstille]

They should do what the C standard did to solve this problem. A C int is generally of whatever size the architecture is most easily capable of manipulating. On nearly all modern architectures, this is four bytes, but this is not mandatory. On certain embedded systems, I've seen two (and even three, on a 24-bit DSP) byte integers. The long type (or, in C99, the int32_t type), however, is always 32 bits or four bytes, and that's why both long and int are valuable as distinct types.

Re:128 bit computing is around the corner

[tyrione]

It took 30 years of PC use to roughly move from 8 bit to 64 bit and you're expecting it to take 100 years to move from 64 bit to 128 bit?

It sure as hell won't take that long, not to mention the notion of Memory won't even be remotely the same as it currently stands.

Re:64 bit Java?

[ckaminski]

Java applets as a technology was hurt by a myriad of factors,

1. The rapid evolution of the language
2. The poor VM performance (before Hotspot)
3. Poor browser support
4. No default installations, except the MS JVM.
5. MS introduced incompatibilities and extensions

Sun should have laid off the "Java replaces the desktop" rhetoric, and paid Microsoft to ship the JVM on Windows. It would be as ubiquitous as Flash is today.