IBM Releases Fastest SDK For Java 6
IndioMan writes "IBM is releasing an SDK for Java 6 and is sponsoring an Early Release Program to gather feedback from the Java community. Product binaries and documentation are available for Linux on x86 and 64-bit AMD, and AIX for PPC for 32- and 64-bit systems. In addition to supporting the Java SE 6 Platform specification, IBM's SDK also focuses on platform stability, performance, and diagnostics. It's tops on every benchmark."
If they include a x86_64 browser plugin they'll be heros. It's 2007 and Sun still refuses to release a 64-bit browser JRE plugin because..... why?
Top Most Bizarre/Disturbing Error Messages
Sun didn't want to delay the launch of Java 6, so it's Java 7 that's open source.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I forgot to include my sources for that:
Behind the scenes -- from Mark Reinholds Blog.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Funny, but even Sun's JDK blows Perl out of the water.
I know the statement was tagged as funny, but Java is quite fast these days. Java7 will only get faster with some really spiffy JVM ideas. I don't see Python, Perl, and Ruby catching up for a while.
It seems to me that once Java is opened up and is included with every Linux distro out there, Java will not be perceived as large and slow anymore. It will be a simple apt-get, yum, etc away. It will just work.
Why did the parent modded as troll? It's quite true. For example, look at The Computer Language Shootout. Sun's JVM is much faster than Perl in almost every benchmark except for startup times. Perl's memory consumption is somewhere better, but not even close to the same degree that Java is faster.
Those benchmarks are based on Java 1.5, too. 1.6 is even faster.
Karma: Terrifying (mostly affected by atrocities you've committed)
Scimark wasn't even close:
IBM java6:
Composite Score: 482.8282568762099
FFT (1024): 551.8002634079949
SOR (100x100): 568.7588552216857
Monte Carlo : 64.62096017621073
Sparse matmult (N=1000, nz=5000): 219.84569330460474
LU (100x100): 1009.1155122705532
Sun java6:
Composite Score: 617.5119705454583
FFT (1024): 510.7586118547276
SOR (100x100): 829.8686416193439
Monte Carlo : 118.25350583943022
Sparse matmult (N=1000, nz=5000): 470.6355733620428
LU (100x100): 1158.0435200517468
Higher scores are better. Both run on AMD X2 5000+
Sun VM stomped on IBM's. That wasn't true with earlier VM's. IBM used to smoke Sun on scimark. Maybe there's more development to be done.
Why did the parent modded as troll?
Because this is slashdot, and perl is one of the Chosen Few Languages, along with C, Ruby, Python and PHP. Java, being both closed (for the moment) and slow (5 years ago on the client side) is not. Therefore, any statement that compares Java favourably with one of the Few Chosen Languages must be either a troll or flamebait.
It's easier when you stop fighting the groupthink.
It's official. Most of you are morons.
Because this is slashdot, and perl is one of the Chosen Few Languages, along with C, Ruby, Python and PHP. Java, being both closed (for the moment) and slow (5 years ago on the client side) is not.
I believe you mean "Chosen-Few-Languages-for-Slamming". they all get it from the slashcrowd, in no particular order:
Stop Computers/Cars Analogies on S
That's not true. The source code has already been opened as a project:
https://jdk.dev.java.net/
The fact that they haven't made their first release from that product changes nothing.
The slow performance of Eclipse is not due to the JVM, it's about the SWT library and it's bindings with the native libraries. There was an SWT port called SWT Fox that quickened things up a bit. It doesn't seem to be maintained anymore, but the performance speedup was very noticable. Changing the VM probably won't make the slightest of difference.
That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...
In the meanwhile, we've still got customers stuck on 1.3, because our "write once, run anywhere" code doesn't run on 1.4, and it's too much effort to puzzle out why because Sun's runtime is just such a mess.
h tml
There could be several reasons why Java 1.3 code won't run on 1.4. One is if you use sun.* or com.sun.* packages directly, which is funcamentally against portability guidelines. Another could be real incompatibilities. There are very few incompatibilities between 1.3 and 1.4. They are listed here:
http://java.sun.com/javase/compatibility_j2se1.4.
If you keeping customers from using Java 5.0 or Java 6.0 because you can't sort this out, you are keeping them from major performance and functional improvements.