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

Comments

Re:Under what license and is it opensource....?

[try_anything]

If you work on commercial software, the type of license may determine whether you can use the code in your product.

What benchmarks?

[Anonymous Coward]

It would be nice to see a few links uphold that claim.

Re:The Fastest JDK?

[thule]

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.

Re:The Fastest JDK?

[Anonymous Coward]

Hasn't been funny or true for a long time...

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 responsive than Swing. But compared to purely native applications, they're still noticeably slower.

We really don't see Java applets used much any more. Flash has taken over.

The only reason Java has obtained some level of success for enterprise-grade applications is because most large corporations can afford to spend hundreds of thousands of dollars on expensive, high-end Sun and IBM hardware. Those are the sort of systems one needs in order to make Java truly useful.

It's in the best interest of the Java community for us to admit that Java is indeed quite slow. Only after we have admitted this fact will we truly be able to improve the situation.

Re:x86_64 plugin = Heros

[Jeff DeMaagd]

Personally, I understand why 64 bit isn't necessarily supported, but then, they support Linux and AIX on 64 bit PPC. I don't know if the 64 bit on PPC is because they've had it working for longer, because of its POWER heritage or just because it's their architecture. I also wonder if there is something about the x86 implementation that makes porting to 64 bit pretty hard.

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 operating systems and 64 bit software. I think it may just be a matter of trying to get something to suit most of the market and then plugging in the holes later.

Re:The Fastest JDK?

[badfish99]

Java7 will only get faster
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:The Fastest JDK?

[kv9]

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:

• Java - slow, bloaty

• C - old and krusty, pointers baaaad, get with the times

• Ruby - it's the new Visual Basic

• Python - haha whitespace

• PHP - insecure, noobs

• Perl - gruesome syntax and readability

Re:x86_64 plugin = Heros

[bwt]

I don't really know that many people that are running 64 bit computers, using 64 bit aware operating systems and 64 bit software./i>

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:The Fastest JDK?

[Gr8Apes]

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 I stated precisely that. "[T]ake a loaded dump truck on a racetrack" in reference to using a JSP/servlet for something as simple as a Hello World application. Just in case you're really dense, the container that runs servlets/JSPs usually have considerably more plumbing than Apache + module. I state usually because somewhere I'm willing to bet there's an "optimized" JSP/servlet server that may be much closer to the Apache configuration. Apache is bare-bones.

Regarding coding speed: Give me two equally skilled programmers, and tell them to hook up to a messaging queue, a couple of DBs, and throw in some business logic during the processing of your now somewhat complex "Hello World" app. If you want to make it more realistic, add in some transactional processing with writes to an external store. The Java guy will be at home while the code is tested and in production while the C++ guy is still working on getting the initial skeleton running. Note that in this scenario, which is a much closer semblance of reality in the business world, that the speed of the serving application becomes a miniscule portion of the total response time as the back-end systems and connections to them are your major bottlenecks. There is a reason companies have converted to Java. It wasn't because the development time went up.

And this is not conjecture about Java being the better choice for business programming of the sort outlined - I have seen it in RL with Perl, COBOL, C, and C++. Those languages have their places as well, but large scalable flexible business applications are not it.

BTW, you should note that I think Apache is a fine web server, and it fronts most of the web apps I have worked on and I use it personally.

Re:x86_64 plugin = Heros

[TemporalBeing]

BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned

Yes, x86-64 has been abandoned by both parties. However, Intel according to this FAQ article, and this article 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 wrong in that it is a pure name change and that stuff was in EMT64, which is highly likely; but that's just my take from the page.)

BTW, according to the articles, Intel64 was suppose to start being available in Q4 of 2006. Don't know if they met that or not.

Of course, then there is the additional stuff from Microsoft that states:

Intel64 property is defined only when it is running on an Itanium processor

Which conflicts with Intel's FAQ (see above):

Is Intel®64 the same technology used in the Itanium® 2 processor?
No. Intel®64 is an extension to Intel's processors based on the IA-32 architecture. The Itanium processor family is based on the EPIC architecture. These are two separate families of processors, based on two different architectures. The Itanium processor family is specifically designed for the most demanding mission-critical applications.

Which leaves me to wonder how Microsoft is going to differentiate between IA64 (Itanium's architecture) and Intel64 if they are referencing IA64 by the name Intel64.

Re:The Fastest JDK?

[samkass]

As someone who writes client-side Java, I can say that Swing is actually fairly responsive these days. However, it often suffers from a "first click is slow" problem, where the very first time you do something it's slow, then it's fast after that. So a cursory glance at Java apps often show them in the worst possible light.

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.