IBM Releases Fastest SDK For Java 6 117
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."
64? (Score:2)
Re: (Score:2, Funny)
Re: (Score:1)
Open Java? (Score:2)
Re:Open Java? (Score:5, Informative)
Re:Open Java? (Score:5, Informative)
Behind the scenes [sun.com] -- from Mark Reinholds Blog.
Re: (Score:1, Flamebait)
Re:Open Java? (Score:5, Informative)
https://jdk.dev.java.net/ [java.net]
The fact that they haven't made their first release from that product changes nothing.
Re: (Score:1, Informative)
https://openjdk.dev.java.net/ [java.net]
Re: (Score:2)
Re: (Score:1)
Under what license and is it opensource....? (Score:1)
Re: (Score:1)
Re: (Score:3, Insightful)
Re: (Score:1)
Re: (Score:2)
You're a little confused. The license that javac and the jvm are to be released under has nothing to do with the JRE.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2, Informative)
Systems Affected
Sun Java Runtime Environment versions
* JDK and JRE 5.0 Update 9 and earlier
* SDK and JRE 1.4.2_12 and earlier
* SDK and JRE 1.3.1_18 and earlier
Re:The Fastest JDK? (Score:5, Informative)
Comment removed (Score:5, Informative)
Re: (Score:1)
Re:The Fastest JDK? (Score:5, Funny)
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.
Re:The Fastest JDK? (Score:5, Insightful)
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:
Re: (Score:1)
The debian shootout is worthless (Score:2)
The class of problems for which Perl was created is a bit more complex than i
Re: (Score:1)
Re:The Fastest JDK? (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Yes, and Java 53 will be really good, and everyone will like it.
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.
Re: (Score:3, Interesting)
Are your "write once, run anywhere" applications using internal APIs, or are they relying on bugs in the 1.3 class libraries to run? Personally I've only ever come across code that DOESN'T run properly on 1.3, due to bugs introduced between 1.2 and 1.3, and fixed in 1.4.
Re: (Score:2)
Re:The Fastest JDK? (Score:5, Informative)
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.
Re: (Score:3, Informative)
Sorry, but I don't believe that. You probably have problems to run 1.4 java on a 1.3 VM
1.3 byte code must by definition run on a 1.4 machine, and if there is indeed a problem in the class libraries a simple look at the exception trace should show you where. Even if
Re: (Score:2, Informative)
Well, you're probably not a Ruby developer then :-) Ruby's switching to a new VM in the next release, it's part of the mainline CVS sources. I've not benchmarked it myself, but it's supposed to be 2x faster already.
Re: (Score:2, Informative)
1998 called, and they want their joke back.
Hasn't been funny or true for a long time...
Re: (Score:3, Insightful)
I think you're wrong. Even today, over 15 years since Java was first announced, we see little use of it for client-side development. There are only a handful of consumer-grade applications written in Java, with the most popular being Azureus and RSSOwl. Even then, one of the chief complaints against them is their lack of responsiveness and their excessive memory consumption. And keep in mind that they use SWT for their GUIs, which is in fact far lighter and more r
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I want to see a benchmark of a servlet pushing a simple http 'hello world' versus an apache module doing the same thing. And then with a thousand requests per second. I'm sure that you're sure that java will keep it up, it's just that I'm not so sure.
Why would I feed a simple html "hello world" via a JSP? That's like taking a loaded dump truck on a racetrack. It's a "benchmark" wholly slanted to the "lightness" of C++.
As far as rates go, I'm not willing to take a stand on current possibilities, as the load tests I've done are on systems who's bottlenecks lie in relatively long term data retrieval and processing, not network I/O. In these scenarios Java easily meets or exceeds C++ in performance and coding time is considerably quicker under Java, as the
Re: (Score:2)
Re: (Score:2, Insightful)
If you read my post carefully, then you'll have noticed that I said 'servlet', not 'JSP'.
The net result is indifferent after JSP compilation. JSPs are servlets. So once compiled, there is no difference between the two. You can, or could, precompile JSPs as well. (I haven't bothered with this feature since 2001, so don't know if it was dropped or still exists in new modern implementations. The QA regression run on a prod deployment also compiles all the JSPs.)
I was trying to make an orange vs. orange comparison here.
and you failed. Here's why:
On the one hand you have precompiled ... java-code embedded in the server, on the other hand you have an apache module written in C, embedded in the server. In the first case, a request will have to pass via an arbitrary native (JVM-) implementation of 'select', in the latter case you're dealing with one of the fastest webservers on the planet executing native code.
If your reading comprehension were actually as high as you apparently think, you'd note that by implication
Re: (Score:2)
That's being a wise-ass for the sake of being a wise-ass. There is no way to predict _how_ a JSP will be compiled into a servlet (it's engine specific, after all), ergo no way to compare the outcome. For all I care the engine encodes a JSP to go to sleep for a second or so before it produces any output. Wouldn't violate the spec, but I wouldn't be able to tell.
And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable; what do you want t
Re: (Score:2, Informative)
]] JSPs are servlets.
That's being a wise-ass for the sake of being a wise-ass.
wise-ass? I think not - you explicitly stated servlets, not JSPs when in truth JSPs are for all intents and purposes servlets.
There is no way to predict _how_ a JSP will be compiled into a servlet (it's engine specific, after all), ergo no way to compare the outcome. For all I care the engine encodes a JSP to go to sleep for a second or so before it produces any output. Wouldn't violate the spec, but I wouldn't be able to tell.
The end result is a class file on every single system I've worked on. The conjecture that spurious crap happens is an empty strawman at best. Some engines may be more efficient than others, but that's true of any set of compilers.
And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable;
You're missing my point: the application server within which servlets run typically contain far more plumbing than Apache web servers. They were also des
Re: (Score:3, Informative)
Maybe you should look at an actual benchmark [caucho.com] instead of assuming
Re: (Score:2)
people compare code which is linked into a webserver (java) with external scripting languages like PHP and perl
What? Java code is not "linked into a webserver", it runs in some flavor of "container" (e.g., Tomcat is a servlet container that contains the RTE necessary to support Java servlets). You could say that it's linked to a web server, but no more so than PHP or Perl.
Don't confuse a Java app server with a web server. An app server takes a lot more memory and often can't be tuned for performance to the same extent as a standalone web server. OTOH, you can usually front an app server with one or more standal
Re: (Score:2)
Sorry, but this is simply wrong. Java is as fast as anything else. If you feel Azureus is slow and unresponding the reason is its written by an unexperienced programmer. Java is a simple language, in relation to C, and with modern IDEs it is as simple to hack code together as with Visual Basic.
The only reason Java has obtained so
Re: (Score:2)
The Client vs. Server argument seems to always be mentioned whenever Java's performance comes into question... as if server-side Java is some kind of turbo-charged utopia. It's not. Throwing more hardware at inefficiency doesn't make it fast. It only covers up the problem. I don't care that this kind of waste has become the norm in the Java community. It's fundamentally repulsive.
Java is definitely slow for client
Re: (Score:2)
A great man once said: "You can always write bad code." This seems like a simple statement, and if you think you understand it, read it again. At its base, it is saying something akin to what Godel said in his incompleteness theorem.
Java never promised any of the things you said, and no decent programmer would have believed it if it had. The "speed of develop
Re: (Score:2)
Java is a compiled language. I'm kind of surprised you would write with such authority on the language and make that mistake.
Sorry, but I don't consider byte code to be compiled. Just in time compilation isn't quite the same thing, it's a translation layer. If it were, then JavaScript and C# would be considered to be compiled languages.
The fact that Java can be compiled, doesn't necessarily make it a compiled language, IMO. If I'm wrong in this, then I apologize. It is possible to compile Java with gc
Re: (Score:3, Insightful)
In any case, the meme that it's impossible to write a fluid, responsive UI in Java is just as wrong as it is on the server-side.
Re: (Score:2)
Re: (Score:2)
Of course, our client doesn't use either, but rather our own GUI we wrote in house. And it's extremely fluid. Java simply isn't a slow language anymore.
Re: (Score:2)
The slowest thing about Java has been Swing, and the slowest thing about Swing has been the startup times. I switched from Java to C++ .Net for my personal programs because of this. However, I installed Sun's JDK 1.6 a week ago, and I was amazed at the improvement in startup time. I just did a "race" with a calculator program that I wrote in both C# and Java, and they both started up in less than a second. When I first wrote the Java program several years
Re: (Score:2)
x86_64 plugin = Heros (Score:5, Interesting)
Re:x86_64 plugin = Heros (Score:5, Interesting)
Re: (Score:3, Insightful)
With respect to the browser plug-in, I don't really know that many people that are running 64 bit computers, using 64 bit aware operatin
Re: (Score:2)
In my case, that's because of a lack of support from the vendors. I can have a 64 bit OS *or* wireless networking, for example (thank you, Netgear).
Re: (Score:1)
Alas, while 32bit Windows XP is prevalent, 64bit is a minor concern.
Re: (Score:2)
Wild guess: they have one or two guys on their project and they've ported to the hardware that they have on their desk.
Re: (Score:3, Insightful)
I do, except I run a 32-bit firefox that I install by hand because I need a java plugin that works. You have to remove the barriers before people will use it, and once you do remove the barriers, they will come.
Re: (Score:2)
Usually that would be sufficient, but for a just in time compiler, 64-bit clean is not enough. It also has to be *rewritten* to produce 64-bit code. So I think there is a long way to go for Java before it catches up with the hype.
Re: (Score:3, Informative)
Re: (Score:2)
and I'm looking forward that nothing at all is happening.
The few people having the skills and the need to have the plug in likely have no time to do it.
The people having the time, likely lack the skills or the motivation. I really doubt that there are programmers out there who have the feeling: Wow, today java is GPL, lets hack it better, I start immediately! Ma! Coffee!! Fast!
angel'o'sphere
Re:x86_64 plugin = Heros (Score:5, Informative)
There are 2 ways to get a 32-bit Java plugin running under a Linux/AMD64 environment (BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned):
Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.
Re: (Score:1)
Re: (Score:3, Insightful)
Yes, x86-64 has been abandoned by both parties. However, Intel according to this FAQ article [intel.com], and this article [intel.com] is using the name Intel64, which according to the second article is just the EMT64 stuff renamed and enhanced by Intel. EMT64 was basically Intel's rip-off of AMD64; and according to the second article Intel64 is EMT64 with the SSE3, HT, and other Intel specific technologies. (I could be wron
Re: (Score:2)
It doesn't matter what Intel chooses to call it (they have changed their mind 3 times: IA-32e, EM64T, Intel64). The fact is, Intel cloned the AMD64 architecture. AMD wrote the architecture specs [amd.com] and they gave it the name AMD64. When you install NetBSD or OpenBSD on a 64-bit Intel processor, you install NetBSD/amd64 or OpenBSD/amd64, these guys adopted the proper architecture name.
Other vendors use other names, Microsoft and Sun use x64, some use x86-64. Should you use these names ? No. Just stick to the
Re: (Score:2)
Re:x86_64 plugin = Heros (Score:4, Informative)
Re: (Score:2)
Java for PS3? (Score:1)
* Linux® on x86
* Linux® on PowerPC® 32-bit #!
* Linux® on PowerPC® 64-bit
* Linux® on AMD64/EM64T
* IBM AIX® on PowerPC 32-bit
* IBM AIX® on PowerPC 64-bit
What benchmarks? (Score:3, Insightful)
Re: (Score:1)
It seems like ./ eds or submitters making up crap to spice up headlines again. That's the nth time this week and I want my money back. I read TFA and couldn't see any claim to it being the fastest, although looking at the features there's plenty to make it interesting without additional ./ marketing spin.
By the way, is it "fastest" as in it's stuck fast and not going anywhere, or did you mean quickest?
Re: (Score:2)
Actually, IBM's JVMs have always had a reputation for very good performance. Years ago, I found IBM's Java 1.3 routinely beat equivalent code in gcc for many numeric algorithm benchmarsks.
Re: (Score:1)
Which doesn't change the fact that I can't find the claim in TFA. The assumption, however good or bad it may be, was used as a headline when there are plenty of good things that could be used for ligit headlines _and_ there are other high performance jvms. At the risk of starting a religious war, how does this stack up to BEA/JRockit on various architectures?
...then again "Fastest Ever" does sound catchier than "IBM adds OS Level Stack Traces". Nice marketing ./
I'm sure I will download and use this jvm, b
Re: (Score:1)
Unless you meant "quickest" as in "most alive"?
This was released back in November of 2006! (Score:2, Informative)
http://www-128.ibm.com/developerworks/forums/dw_t
Not all benchmarks better (Score:5, Informative)
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.
Still makes me wonder (Score:2)
E.g., when Hotspot first came around, it claimed to accelerate some benchmarks thousands of times, which was already suspect. It turns out that in one popular benchmark at the time, it completely elliminated the loop. Which in and by itself would be a valid optimization, if it were on the general case. But it turned out that as little as changing an "if (A == B)" to "if (B == A)" was enough to disable that optimization. Sun's sm
Re: (Score:3, Informative)
Doesn't seem to be the case here. I'm doing some pretty heavy numerical stuff with java these days. The Sun java6 VM definitely outshines others at the moment. That used to be the case with the IBM VM. Maybe once it comes out of early release it'll be back to it's former glory.
Re: (Score:2)
Do you think they reported enough precision on those numbers? They lost me after 482.8...
Does this mean a faster Eclipse? (Score:2)
Re:Does this mean a faster Eclipse? (Score:5, Informative)
That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...
Bindings (Score:2, Interesting)
The SWT binding directly accesses gtk through JNI. This may have suited IBMs purposes of accessing gtk through the SWT API but might not be the most optimal binding of gtk to Java.
The java-gnome [sourceforge.net] project produces java bindings for gtk. They are in the process of being re-written from scratch using 2007 best practice JNI binding techniques. I suspect that an SWT implementation using t
Re: (Score:2)
Tip: open comments that you want to moderate in a new tab. Mod them after you're done reading the discussion.
(yeah, I've been in that boat before)
Re: (Score:2)
There are many good things about Swing, and it's interface is surely written in a better Java dialect
Re: (Score:2)
Your problem is you have set the wrong selection mode for JFileChooser.
If I do this:
JFileChooser file
Where are the sources ? (Score:3, Interesting)
SUN has released the sources to it's compiler and JDK.
IBM where are thou the benefactor and promoter of Open Source ? Show us the GPL sources to your JDK and compiler!
Not working on Debian unstable (Score:2)
Could not create the Java virtual machine.
This is probably caused by NPTL-less glibc. Anyone with suggestions how to fix it?
Great! (Score:2)
Re: (Score:2)
Re: (Score:2)
WSAD Won't Support It (Score:1)
Microsoft (Score:1)
The MSJVM will reach its end of life on December 31, 2007. Customers are encouraged to take
proactive measures to stay informed about obsolete software and move away from the MSJVM
in a timely fashion. The MSJVM is no longer available for distribution from Microsoft and
there will be no enhancements to the MSJVM. Microsoft products and SKUs currently
including the MSJVM will continue to be retired or replaced by versions not containing
the