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

Comments

Developers section red now ?

[unity100]

what is this, moulin rouge ?

Re:Developers section red now ?

[MaskedSlacker]

Looks blue to me

Re:Developers section red now ?

[nschubach]

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.

Re:Developers section red now ?

[Anonymous Coward]

64-bit Slashdot still has a few kinks to work out.

Re:Developers section red now ?

[Anthony_Cargile]

I'm colorblind, you insensitive clod!

Re:Developers section red now ?

[Anonymous Coward]

Makes a change, most people around here are joke blind.

Re:Developers section red now ?

[thrillseeker]

I don't get it.

Re:Developers section red now ?

[tomhudson]

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

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:Developers section red now ?

[mR.bRiGhTsId3]

Ok, but Java longs are 8 bytes, even in 32-bit whereas in C they are still often 4 bytes. Its not the end of the world, just something to be aware of if you might have to deal with big numbers.

Re:Developers section red now ?

[setagllib]

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: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:Developers section red now ?

[thtrgremlin]

Can I mod the moderator +5 funny for modding the parent -1 off-topic?

Re:Developers section red now ?

[m50d]

With today's standards, sure. But what about in the future when that file's just a high-quality movie, say?

Re:Developers section red now ?

[zergl]

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

Refactor your ints to long if you need bigger values?

Apart from that, the link's criticism specifically refers to Arrays still using a 32bit int index without the capability to use a long instead but you might be able to work around that by using another datastructure instead should you really need that much Objects stored in one container.

Re:Developers section red now ?

[shutdown -p now]

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)

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:Developers section red now ?

[ckaminski]

The idea of a data warehouse is that it gloms all the other data from your other systems, aggregates it, and generates lots of reports, extra BI data. Ideally, it can be completely lost, and it can be rebuilt from scratch the next day. Pain in the ass, but not particularly necessary to have fully redundant. But you want powerful, because all your business users will be hammering it for reports, and data mining.

Re:Developers section red now ?

[TheRaven64]

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.

64 bit Java?

[Whiney Mac Fanboy]

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:64 bit Java?

[QuantumG]

Someone has to be slower to load than the acrobat reader plugin.

Re:64 bit Java?

[Whiney Mac Fanboy]

Someone has to be slower to load than the acrobat reader plugin.

Not even Java can take that prize.

Java Joke:

Knock Knock.

Who's there?

...

...

...

...

Java!

Adobe Joke:

Knock Knock.

Who's there?

...

...

...

...

Crash.

Re:64 bit Java?

[Al Al Cool J]

That's not really a properly-formed knock knock joke. How about:

Knock Knock.

Who's there?

...

...

...

...

Java!

Java who?

...

...

...

...

Java few minutes? 'Cause this might take a while.

Re:64 bit Java?

[doktorjayd]

you're confusing java applets circa 1997 with the java platform.

take a look through the it job listings and see how much java comes up.

much, if not most, server side *enterprise* work is done in java, which is a mature, robust, reliable, performant and scalable platform for which there are myriad commercial and open source libraries to give any project a great set of building blocks and frameworks on which to build.

i check out language du jour a couple times a year, and every time it reaffirms java's benefits.

the problem with applets is they were generally pretty hacky, but there are some good ones out there.

( check out the yahoo games website - my wife has been addicted to literati for years, and its a nice little java applet ).

java on the desktop has a place too, however its the same set of rules for design and structure as applets: done well, nobody would know/care what language its written in, but done poorly without care for threading models and it'll quickly turn into a steaming pile.

then theres j2me, and i'd wager if you have any tivo type device, or even set-top box for your cable service, or blu-ray player, or most mobile phones these days, then you have java working for you there too.

not that i'm arguing for applets by any means, but the more people spread the same old rants as above, the more i'm inclined to correct them.

Re:64 bit Java?

[HeronBlademaster]

I hope you mean "C#/Mono disease"...

Anyway, there are lots of reasons to use Java (though not in a browser setting) nowadays. Just my two cents. YMMV, not all languages are created equal, not every language is good for every project, etc etc etc.

Disclaimer: I have a great dislike for Java, but the job offer I just accepted is almost exclusively Java work. Silly me.

Re:64 bit Java?

[tyrione]

you're confusing java applets circa 1997 with the java platform.

take a look through the it job listings and see how much java comes up.

much, if not most, server side *enterprise* work is done in java, which is a mature, robust, reliable, performant and scalable platform for which there are myriad commercial and open source libraries to give any project a great set of building blocks and frameworks on which to build.

i check out language du jour a couple times a year, and every time it reaffirms java's benefits.

the problem with applets is they were generally pretty hacky, but there are some good ones out there.

( check out the yahoo games website - my wife has been addicted to literati for years, and its a nice little java applet ).

java on the desktop has a place too, however its the same set of rules for design and structure as applets: done well, nobody would know/care what language its written in, but done poorly without care for threading models and it'll quickly turn into a steaming pile.

then theres j2me, and i'd wager if you have any tivo type device, or even set-top box for your cable service, or blu-ray player, or most mobile phones these days, then you have java working for you there too.

not that i'm arguing for applets by any means, but the more people spread the same old rants as above, the more i'm inclined to correct them.

You're too professional. People around here suffer from SADD and if something doesn't tickle their leg just right it flies right over their heads.

Re:64 bit Java?

[this great guy]

Linux has had a full-featured 64-bit Java plugin that even includes LiveConnect support for at least months via IcedTea, 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 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, 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?

[glwtta]

And this story is only important if somebody out there has a burning need to run a 64bit Java app... in a web browser.

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?

[Skrapion]

Oh please. You're telling me you can implement a webcam viewer with Javascript?

The only real alternative for Java applets is Flash. Of course, compared to Flash, Java applets have a lot of downfalls. The VM takes a ridiculous amount of time to start up, and it's really intrusive when it sits in your system tray and constantly announces its new updates.

However, this is Slashdot, which means there's lots of open-source advocates around. So for all the OSS advocates out there, stop and think for a minute before you bash Java applets. They're not great, but they're the only open alternative to Flash right now.

Re:64 bit Java?

[TheUser0x58]

Java applets are the only cross-platform technology that can do full 3D rendering in the browser.

Re:64 bit Java?

[psetzer]

I wait with bated breath for a hyperlink that I can click on to play an Ajax version of Quake 2. Until then I'll just have to make do with http://www.bytonic.de/downloads/jake2_jogl11.jnlp instead.

Re:64 bit Java?

[doktorjayd]

Now it's racks of big ass servers or blades groaning under badly designed layers and layers of Java 'middleware'

so your premis here is the problem is the language/platform rather than the design at fault?

If you have insane amounts of CPU and memory to throw at it to cover up the slowness

either you need to replace the tandy coco you mention later as your primary pc, or you could actually _try_ it before you bag it. ( trying it again after 1997 might also be an idea..)

Must have missed it.

that tends to happen when you have HASUB* syndrome. it happens, dont worry about it. you probably havent noticed a lot of stuff.

.. some rant about java and vista bloat related to java desktop. and then brings solaris and mac into it. pfft.

yawn.

No, you notice when a small app starts sucking up all available memory. Java sucks memory so hard GNOME starts looking lean in comparison

i can malloc my way into something that smells the same in c too.. only in java you're less likely to leak.

hey actually put players on shelves that take upwards of two minutes to go from tray close to anything useful appearing on the display

huh? i drop blu-ray disks into my ps3 and its playing within a few seconds. you're smoking crack.

I've got a cheap crappy basic cell phone. You can almost see individual pixels draw on the darned thing...

unless you run an application on your cheap crappy phone, you're probably looking at just the cheapness and the crappiness of the phone, not java.

i think what you really meant in the above post was more along the lines of 'get off my lawn'.

i know this is slashdot, but occasional fact checking really cant hurt if you're going to go on a raving rant about your hatred of specific technologies.

*HASUB syndrome: Head And Shoulders Up Bum syndrome

Re:64 bit Java?

[Samah]

Best.
Joke.
Ever.

Re:64 bit Java?

[Simon80]

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.

Try C++, which seems to get much less attention than it should. It's undeniably faster than Java, but equally good at creating usable abstractions.

Re:64 bit Java?

[timeOday]

Good riddence to java 32 and 64bit, Sun freed it about a decade too late for most people to give a crap

I still think the failure of Java on the desktop is a tragedy and hope it will rise again (though I'm not holding my breath). What has replaced it for rich applications on the web? I see steaming, muddled heaps of web-specific "standards" and scripting languages which, individually, are too weak to do much. Give me a real language, for pete's sake. Yet, my experience with Java in the browser was as bad as everybody else's - they hardly ever worked. Either my JVM wasn't new enough, or it froze up.

But what I see missing from this discussion so far is a reminder that, at the height of their power, Microsoft killed Java on the desktop very intentionally - they put a polluted "MS-Java" with embrace-and-extend hooks into Windows. So Sun sued them and in retaliation, Microsoft made sure Java on the desktop was a pain in the butt for everybody. It was still possible, but too much trouble to bother. This history is important because it means Java still might succeed if it were given a fair shake. And now that Microsoft is less dominant (and RAM is cheap :) maybe - just maybe - the phoenix can rise again?

Re:64 bit Java?

[Draek]

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.

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:64 bit Java?

[julesh]

The only real alternative for Java applets is Flash. Of course, compared to Flash, Java applets have a lot of downfalls. The VM takes a ridiculous amount of time to start up, and it's really intrusive when it sits in your system tray and constantly announces its new updates.

Down to less than 2 seconds on my system, these days. Each new release seems to take less time than the last. And the update announcements can be disabled, if they annoy you.

Also, Java applets have a lot of upsides to flash as well:

* Ability to access network services (not just via XMLHttpRequests), so live streaming data is a possibility
* Signed applets can access local system resources that Flash cannot
* Use useful APIs to do stuff that's beyond the capabilities of Flash (e.g. the Java port of OpenGL)
* Don't have to design your user interface as a series of frames that you move between to show and hide aspects of it (yeuch... I've done one project of Flash UI design, and that was more than enough for a lifetime thanks.)
* Much, much easier to support internationalisation
* Acceptable calculation speed for CPU-intensive stuff

I'm sure there're more. OK, Java applets are a heavyweight solution. But they are the only solution other than ActiveX for many problems.

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.

64-bit and 32-bit binaries

[robo_mojo]

For most people there is nothing to hold you back from running 64-bit Linux.

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.

Re:64-bit and 32-bit binaries

[aled]

I think there is a problem running a 64 bit browser with a 32 bit Java plugin.

Re:64-bit and 32-bit binaries

[bobstreo]

Yeah if only running wireless in 64 bit worked without the ritual blood sacrifice. Or ndiswrapper, or having to re-install with every kernel update.

Stupid ath wireless.

Then maybe I'd care about Java/Flash...

Re:64-bit and 32-bit binaries

[Froeschle]

While it is true that you can run 32 bit binaries under 64 bit Linux, one problem I have had in particular is the combination of the two. I have a 64 bit system but I could only run the 32 bit version of the Java plugin under 32 bit Firefox, which of course breaks most other existing 64 bit plugins that would not work under a 32 bit Firefox installation. There are wrappers and such but the whole thing is just a major PITA. I for one welcome the new 64 bit Java plugin!

Re:64-bit and 32-bit binaries

[HeronBlademaster]

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:64-bit and 32-bit binaries

[aled]

This one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 more: http://www.linuxforums.org/forum/redhat-fedora-linux-help/50082-64-bit-java-plugin.html

Re:64-bit and 32-bit binaries

[j79zlr]

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

Re:64-bit and 32-bit binaries

[eulernet]

I really love the comment:

Submitted On 07-FEB-2005
The_Crusher

Please fix for Tiger. We certainly won't appreciate having to wait 18 months for a fix that's probably trivial on Sun's part.

Most of my 3rd-party apps do not work with Java 6

[rminsk]

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.

128 bit computing is around the corner

[Anonymous Coward]

The time has come to begin discussing 128 bit computing.

Re:128 bit computing is around the corner

[Hal_Porter]

64.0 bits should be enough for anyone.

Re:128 bit computing is around the corner

[corsec67]

My Intel processor claims that 63.99 bits should be enough for everybody.

Re:128 bit computing is around the corner

[FlyingBishop]

Who was the genius that modded this interesting? 128 bit computing is a joke. Even if we had anythin resembling the amount of memory you need to make 128 bit computing worthwhile (That's 16.8 million Terabytes of RAM,) it is likely that this hypothetical computer (if any possible use on the desktop could be conceived) would have something on the order of 2048 cores, if not many more.

In those circumstances, I would prefer the architecture that restricted each core (or a subset of cores) to their own 64 bit domain of memory addresses. Anything beyond that could be handled by speaking between the different cores.

I can accept that there could be some applications in a hundred years or so that might require 128 bit on the desktop. That said, while 64-bit might not be enough for anyone, it is almost without doubt enough for any individual processor.

And we've just nearly finished porting everything to 64 bit. I'd rather emulate 128 bit on 64 bit hardware than do that again.

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:128 bit computing is around the corner

[johndmartiniii]

Agreed, I'm so sick and tired of playing with this old in-memory relational database with a separate record for every atom in my house.

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.

For most people

[Anonymous Coward]

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.

Re:For most people

[kimvette]

Why? 1.84467441 x 10^19 bytes ought to be enough for anyone!

Re:About time!

[INeededALogin]

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

Re:Aw crap

[aled]

obviously you need to reinstall... with 128-bits Linux...

Pamplona: Running with the bits.

[Ostracus]

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

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 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 open, the situation can only improve with time.

no DEB files?

[supernova_hq]

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.

Re:no DEB files?

[atomic-penguin]

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

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:no DEB files?

[tyrione]

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

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:no DEB files?

[ADRA]

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.

OpenJDK already 64-bit

[thule]

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

/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so

$ file /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so

/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Re:OpenJDK already 64-bit

[ChunderDownunder]

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.

And here's your impetus to upgrade!

[Wee]

Seriously! This is great news. I'm buying new hardware right now!

Be still my heart.

-B

Re:More Java please?

[Nicopa]

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.

Google Gears?

[at_slashdot]

Just an example of something that doesn't work in 64 bit... not that it holds me back.

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.

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.

Re:already have other options

[jmorris42]

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

push this button

[fatmatt_oz]

All I need now is the ubuntu update manager to give me the option of a 64bit upgrade without a complete reinstall.

Works! But needs a minor fix

[StarHeart]

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

[FictionPimp]

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:Most of my 3rd-party apps do not work with Java

[mabinogi]

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.

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

webstart?

[asv108]

Does anyone know if Sun now supports webstart on 64bit linux?

Re:About time!

[afidel]

Dear god, the reason you didn't want to go over ~1.25GB of heap in Java x86 isn't that it can't go higher, it's that garbage collection times become significant enough that they cause user noticeable delay and possibly timeouts.

that *is* sun java

[sentientbrendan]

>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:Aw crap

[RiotingPacifist]

Meh powers of 2 are for wimps, 100bit Gentoo is where its at!

That's a good thing - trust me

[Weaselmancer]

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:That's a good thing - trust me

[thtrgremlin]

Either int will be a fixed size and longer ints will have another name, or you can explicitly state the size of int as a declaration. This has always been done and 'good coding' should include explicit declaration. It is when people cut corners and use "what works" that can quickly create regression bugs when backwards compatibility is integrated, but you didn't follow good coding guidelines. "That always worked fine suddenly stopped working" issue. This is also why a lot of those "bugs" don't get fixed.

People need to follow proper coding guidelines, not try to stop things from progressing. Programming has always been progressive in this way, and just relearning the new way has never been much of a way to keep up.

Re:That's a good thing - trust me

[shutdown -p now]

Either int will be a fixed size and longer ints will have another name, or you can explicitly state the size of int as a declaration.

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.

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:That's a good thing - trust me

[ckaminski]

I think you mean that long is always at LEAST 4 bytes.

Re:Skype? Google Earth?

[VincenzoRomano]

Skype is there! Just google it as the company seems to shy to show it.

Re:Wake me up...

[peppepz]

By that time, CS5 will be out, you'll need it, and it won't run natively :) .

The reasons why ints are 32 bits

[MosesJones]

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.