Slashdot Mirror
64-Bit Java For Linux
LWATCDR writes "First we got 64-bit Flash; then the beginnings of 64-bit Wine; now Sun is providing a 64-bit Java plugin. For most people there is nothing to hold you back from running 64-bit Linux."
← Back to Stories (view on slashdot.org)
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.
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.
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.
The details are trivial and useless; The reasons, as always, purely human ones.
Does anyone know if Sun now supports webstart on 64bit linux?
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
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?
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.
Want Big Business out of government? Take away the incentive and start by getting government out of big business!
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.
An hour of DV footage is 10GB. A 32-bit offset gives you 4GB of addressable space, so that's not enough. A 34-bit offset gives you 16GB, so that's fine. Maybe you're recording raw HD footage though, let's say 1080p, so 1920Ã--1080 pixels. You're editing, so let's say you want 32-bits per channel, three channels. That gives you around 24MB per frame. Let's say 30 fps, so 712MB per second, or 2.4TB per hour. Let's say a filming session is 10 hours, so that's 24TB per file.
Take the base 2 logarithm of that, and you find you need just under 45 bits to represent any offset in it at byte granularity. If you double the horizontal and vertical resolution, you need 47 bits. If you double the frame rate, you need 48 bits. Go to double-precision floats for each channel, and you need 49 bits. If you use stereoscopic cameras, you need 50 bits. 64 bits still gives you a lot of space to play with. When your files are more than 16 exabytes, you should probably consider splitting them a bit. A filesystem more than 16 exabytes is likely to be needed over the next decade (hence ZFS), but 64-bit files are going to be fine for a very long time. Even today, very few files are over 4GB (mostly DV footage and DVD images), and we've had support for those for around a decade now.
I am TheRaven on Soylent News