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

64?

[countach]

x86-64 isn't just for AMD anymore you know!

Re:64?

[Anonymous Coward]

Yeah, but I run your mom, and man, she runs *hot*.

Re:64?

[Menelkir]

With Java?!

Re:64?

[Anonymous Coward]

No, her pussy. Though it smells really bad, like something crawled up and died (Lemmiwinks?).

Re:64?

[Anonymous Coward]

She run's hot as in Hot Coffee, not Hot Java.

Open Java?

[Beuno]

Whatever happened to all that "Open Source Java" thingie?

Re:Open Java?

[VGPowerlord]

Sun didn't want to delay the launch of Java 6, so it's Java 7 that's open source.

Re:Open Java?

[VGPowerlord]

I forgot to include my sources for that:
Behind the scenes -- from Mark Reinholds Blog.

Re:Open Java?

[badfish99]

In other words, as ever with Java, Sun has hyped up interest with promises that it has yet to deliver.

Re:Open Java?

[rdean400]

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.

Re:Open Java?

[Anonymous Coward]

But the fact that only parts are Free Software (or "Open Source" as they call it) yet does.
https://openjdk.dev.java.net/

Re:Open Java?

[paisleyboxers]

Its called Eclipse, they wrote the whole program in Java.

Re:Open Java?

[rdean400]

Most of the reason that Sun couldn't open source Java 6 is because there is a large quantity of code in there that is licensed from 3rd parties. They're working on resolving the issues now, so that they can completely open-source it by the summer.

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

[gd23ka]

Inquiring minds want to know.

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

[iangreen]

why do people care so much about licensing? weird.

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.

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

[iangreen]

I guess in my experience, the license is totally irrelevant as I am providing services, and not distributables. I suppose it would be much better for end-user programs... but I find the idea of using Java for end-user programs generally unappealing, not to mention that Sun always provided a freely distributable JRE....

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

[jlarocco]

I guess in my experience, the license is totally irrelevant as I am providing services, and not distributables. I suppose it would be much better for end-user programs... but I find the idea of using Java for end-user programs generally unappealing, not to mention that Sun always provided a freely distributable JRE....

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:Under what license and is it opensource....?

[ahadsell]

GPL V2. http://www.sun.com/software/opensource/java/faq.js p#a1

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

[ahadsell]

Err, it's Sun's JDK that's GPL V2, not IBM's. IBM's not releasing source so far. Sorry.

Vulnerability

[VirusEqualsVeryYes]

Could Java 6 be affected by the recent Java vulnerability?

Re:Vulnerability

[jerkface.us]

FTA

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

The Fastest JDK?

[pestilence669]

The Fastest JDK? So... that puts it somewhere between G.W. Basic and Perl?

Re:The Fastest JDK?

[Anonymous Coward]

Funny, but even Sun's JDK blows Perl out of the water.

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]

1998 called, and they want their joke back.

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

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

[Yosho]

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.

Re:The Fastest JDK?

[Yosho]

Of course, I meant to say "Why did the parent get modded as troll?" That'll teach me not to use the preview button...

Re:The Fastest JDK?

[Anonymous Coward]

Java still has dogshit slow class load times, which makes java GUI apps all the more painful to load. I'm personally glad more GUI developers DON'T use it.

Re:The Fastest JDK?

[Time_Ngler]

Client side, that is true. Server side, its just as fast or sometimes faster. See http://kano.net/javabench/ and http://www.aceshardware.com/Spades/read.php?articl e_id=153

Re:The Fastest JDK?

[Tim C]

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.

Re:The Fastest JDK?

[badfish99]

It's certainly possible for Java code to run fast, once it's been through the just-in-time compiler, i.e. once it has been compiled to native code. That would surely be true for any language. But that means that you have to load up the whole of the compiler into memory in order to run your program. This is fine on a server, so long as you don't care about the cost of memory. It's a disaster on a client machine.

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

[jrumney]

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

[MartinG]

Out of interest, are you using AWT or Swing?

Re:The Fastest JDK?

[bytesex]

The links you provide have nothing to do with 'server side' and have headings like 'Why the(!) java is fast and C++ sucks'. Such a heading is obviously not indicative of bias. Furthermore, 'serverside', people compare code which is linked into a webserver (java) with external scripting languages like PHP and perl. 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.

Re:The Fastest JDK?

[Decaff]

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.

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

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

[angel'o'sphere]

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

Sorry, but I don't believe that. You probably have problems to run 1.4 java on a 1.3 VM ... that can be tweeked however by forcing the 1.4 compiler to generate 1.3 compatible byte code.

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 you have used the same faulty class often, e.g. a com.sun.faulty.MyClass ... you should be able to rewrite your code to use my.working.repalcement.of.MyClass very simple.

angel'o'sphere

Re:The Fastest JDK?

[angel'o'sphere]

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.

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

Well, that again is only your perception. $100.000 for one high end SUN/IBM machine is less than I cost one year. That of course has nothing to do with Java being fast or slow. Lots of companies use linux clusters to run the java applications, especially when it is a web application. So they don't need your estimated expensive hardware at all.

On the server where you are facing a lot of concurrency, network access, data base access, security and other concerns, there is no other language/environment existing meeting our days demand on: available fluent programmers, available libraries/tools, speed, and far more important speed of development

angel'o'sphere

Re:The Fastest JDK?

[Gr8Apes]

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 potential for bugs is simply lower.

The blanket statement that A is better than B in all cases simply isn't true.

Re:The Fastest JDK?

[PinkPanther]

Perl - gruesome syntax and readability

Best ... language ... ever!

Re:The Fastest JDK?

[bytesex]

If you read my post carefully, then you'll have noticed that I said 'servlet', not 'JSP'. I was trying to make an orange vs. orange comparison here. On the one hand you have precompiled (again, therefore not a JSP) 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. I am under the impression that this is all a bit over your head maybe, but would you be willing to take bets on tomcat ? or oc4j ? or websphere ? I know I wouldn't.

Secondly, that bit you wrote about coding times, you can shove that in your dump truck, because any of that is subjective and entirely dependent on your expertise.

Re:The Fastest JDK?

[metamatic]

Java7 will only get faster with some really spiffy JVM ideas. I don't see Python, Perl, and Ruby catching up for a while.

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

[Anonymous Coward]

is there maybe a paid Microsoft troll in the forest?

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

Re:The Fastest JDK?

[Doug Neal]

Yes - there's economies of scale involved with Java, it comes into its own in huge server-side applications... the startup time and overhead are nothing compared to the benefits you get from the built-in memory management and dynamic re-optimisation. It often works out faster and more memory efficient than the C/C++ equivalent.

Re:The Fastest JDK?

[Doctor Memory]

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 standalone web servers for serving static content (images, boilerplate text, CSS) and get the improved performance, plus the ability to serve dynamic content.

Re:The Fastest JDK?

[bytesex]

]] JSPs are servlets.

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 to test - database access ? How can you possibly tell what it is you're waiting for ? Well, in my experience, you're waiting for network latency, no matter what you program your client in. I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver.

As for programmability (which, I suspect, is really your point) then I guess your conjecture is as good as mine. The fact that there are more java programmers out there, or that business people use java programmers more doesn't necessarily mean that java is better for the job; it might just mean that java is more comprehensible to stupid people.

Re:The Fastest JDK?

[pestilence669]

Is Eclipse written with Swing? I'd say it suffers from more than the first click problem.

Re:The Fastest JDK?

[Gr8Apes]

]] 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 designed for different tasks. You'll note that my originally statement was that your "'benchmark' wholly slanted to the 'lightness' of C++.". That statement is true, and even more true in light of the above sets of statements.

what do you want to test - database access ? How can you possibly tell what it is you're waiting for ? Well, in my experience, you're waiting for network latency, no matter what you program your client in. So you're admitting that the performance of your application layer is largely irrelevant? Then what's the argument about?

I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver. which is irrelevant for an application layer. Let the webserver serve web pages, let the application tier do its job.

As for programmability (which, I suspect, is really your point) then I guess your conjecture is as good as mine. The fact that there are more java programmers out there, or that business people use java programmers more doesn't necessarily mean that java is better for the job; it might just mean that java is more comprehensible to stupid people. Perhaps C++ programmers are so set in their ways of making buggies.... (just in case you don't get the double entendre, as you seem to be intentionally dense, that's a direct reference to the buggy manufacturers in the early 1900s as those new-fangled motor vehicles started taking over. It's also a reference to how C/C++ programmers continually produce the same common bugs, over and over again in their code - buffer overflows, bad pointer math, etc. Not that Java programmers don't do their own versions of these things, they just get there faster.;)

But seriously - you're either an elitist snob C++ programmer or a troll - I don't really care to figure out which. I personally think C++ has grown into an abomination of its initial intent, which was a clean concise OO version C. Either way, I've met folks in both that are unfit for coding. It just so happens that in C/C++, those that are unfit are generally filtered out pretty quickly because continuous crashes are hard to hide. (Yes, Java is more forgiving.)

Meanwhile maybe I'll go checkout the latest releases of Smalltalk or Ruby, or perhaps even Eiffel.

Re:The Fastest JDK?

[pestilence669]

Java is not as fast as anything else. A statement like this can only come from a non-C++ coder.

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 applications. There's just no argument, not even bad coding practices can explain why it's so bad. When was the last time you used client-side Java and thought, "Wow, this is snappy." For example (since I can't throw project code up here):

Eclipse is slow even with Sun's latest JVM. I've seen (and debugged) C++ applications, written much more poorly, that execute much faster... and crash less often... and use much less RAM... and not freeze up while doing garbage collection... and not struggle so hard to write a 4k text file... etc.

I use Eclipse daily. I use it on Windows, Mac OS X, and Linux. It sucks on all three platforms because it's slow, prone to crashing, and has periodic bouts of unresponsiveness. This sums up my experience with Java everywhere I've used it. It's not the code, as Eclipse is actually written quite well. Besides, isn't Java supposed to prevent developers from writing code bad enough to cause a crash? I think it's the JVM, but I might be wrong. Java developers (all of them) might just not be very good, because that's the only other explanation.

As someone who has a lot of practical experience with Java in the workplace, the supposed "gains" in coding productivity ("Speed of development") are a tad over hyped. You can still leak resources and memory. You can still code dead locks and race conditions. You still have to profile your code & memory usage. Large programs execute slowly and erratically. On top of all of this, Java still has its fanboys that insist it's not so bad. I'm still surprised at how much developers will put up with just to avoid learning a compiled language.

Re:The Fastest JDK?

[jgoemat]

And I was trying for a bare-bones comparison, because anything beyond bare-bones is equally unpredictable; what do you want to test - database access ? How can you possibly tell what it is you're waiting for ? Well, in my experience, you're waiting for network latency, no matter what you program your client in. I want the bare-bones comparison precisely because it tells me what I can expect in terms of primary throughput from a webserver.

Maybe you should look at an actual benchmark instead of assuming servlets would be slow. Yes, it depends on the platform, JDK, and servlet container. Resin with the IBM JDK did 510 'Hello, world' pages per second while mod_perl/Apache did only 324. The 'Hello, world' servlet even been mod_php on Apache's static page rate of 497 requests per second. With a 'Hello, world' implementation, you really have to look at the web server overhead. Where did you think the overhead was going to be in writing to a stream? What made you assume a servlet would be slower? It really depends on how the web server performs.

Re:The Fastest JDK?

[Javagator]

Swing is actually fairly responsive these days

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 ago, the startup time was (if I remember correctly) about 8 seconds.

Re:The Fastest JDK?

[Anonymous Coward]

Someone please mod this faggot down for using "enterprise-grade" in a sentence. Thanks.

Re:The Fastest JDK?

[rpdillon]

You can still leak resources and memory. You can still code dead locks and race conditions. You still have to profile your code & memory usage.

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 development" you mention is not about bugs, it is about how concisely you can capture the idea in code. Java is better than C++ in this respect (IMHO), but not much. It is a lot better than C, but not as good as Python/Ruby/Lisp.

I'm still surprised at how much developers will put up with just to avoid learning a compiled language.

Java is a compiled language. I'm kind of surprised you would write with such authority on the language and make that mistake.

Re:The Fastest JDK?

[pestilence669]

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 gcj, but this is an extra step that requires external tools. Do you think it's really fair to include external, and optional, tools? Besides, gcj isn't exactly endorsed in many circles because of loosing platform independence.

...it is about how concisely you can capture the idea in code

concise
Expressing much in few words; clear and succinct.

/* Because: */
int[] values = new int[] { 1, 2, 3 };
System.out.println("Hello world");

/* Is so much more concise than: */
int values[] = { 1, 2, 3 };
cout << "Hello world\n";

Re:The Fastest JDK?

[rjshields]

I think you're wrong. [snipped some cruft]

I think you're wrong, since the GP was talking about the old Java slow joke being funny. Every time there's an article on /. some wazzock comes along and makes a joke about performance or memory. It's simply not funny any more when you've heard it 1000 times.

Re:The Fastest JDK?

[samkass]

No Eclipse is written in SWT, which while it uses "native" widgets also imposes a Java-to-native translation. I haven't benchmarked SWT against Swing, so I'm not sure.

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

[be-fan]

It's a disaster on a client machine, because current OSs go to a lot of lengths to make C apps quick to execute, but leave everything else out in the cold. C/C++ applications load fast because the C runtime is already in memory and ready to go. Operating systems could have integrated support for caching, sharing, and loading JIT'ed chunks of code, but they don't. Not because of complexity reasons (linking, loading, and sharing an ELF shared library is no harder in principle than doing the same for a JIT'ed assembly for any language), but because they are built on the assumption that everything in the world can be made to look at the system level like C.

Things would likely look a lot different in a system where Java was the default language, and C was the interloper. In such a world Java apps would run substantially faster than they do now, because you could get rid of things like memory protection, position-independent-code, etc, that you don't need when you're dealing with a safe, JIT'ed language. Java apps would also load substantially faster than big C/C++ applications do on present systems. You see, when the compiler is available at runtime, program loading becomes really simple. You don't need the complex (and slow) shared library linking protocols you need to support C code. Instead, just store cached images of non-relocatable JIT'ed code. If adding or upgrading a library invalidates a cached image (a relatively rare operation), you can always just re-JIT the image with a small amount of overhead. This sure beats processing hundreds of relocations and doing tons of shared library symbol resolution *every* time you start an application!

x86_64 plugin = Heros

[baptiste]

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?

Re:x86_64 plugin = Heros

[Anonymous Coward]

maybe because the JIT compiler has to convert the java instructions to x86-64 instructions, so it's not just a simple recompile.

Re:x86_64 plugin = Heros

[Anonymous Coward]

maybe because the JIT compiler has to convert the java instructions to x86-64 instructions, so it's not just a simple recompile.

Right, because that's so different when it's running under a browser than under the standalone VM that ALREADY EXISTS FOR X86-64.

Re:x86_64 plugin = Heros

[bcrowell]

By March, 100% of Java will be available under GPL, right? So at that point, I would think that anybody who has the skills and time will be able to clean up any code that's not 64-bit clean, and compile a 64-bit browser plugin. I'm looking forward to seeing some really good things happen in OSS with Java, now that all the licensing impediments are going away.

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:x86_64 plugin = Heros

[this great guy]

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

• Use the Blackdown Java plugin, they provide a 64-bit version (it works ok, but I have come across at least 1 applet able to crash it).
• Use nspluginwrapper that allows you to load 32-bit plugins in 64-bit browsers.

Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.

Re:x86_64 plugin = Heros

[Builder]

Amen brother!

Re:x86_64 plugin = Heros

[Tim C]

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

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:x86_64 plugin = Heros

[thsths]

> to clean up any code that's not 64-bit clean

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:x86_64 plugin = Heros

[ChunderDownunder]

indeed, the hardware is here today. software needs to catch up. amd chips have been 64 bit for some time and with the release of core 2 from intel, every desktop/notebook will be 64bit capable within 12 months.

Alas, while 32bit Windows XP is prevalent, 64bit is a minor concern. :-(

Re:x86_64 plugin = Heros

[Shawn is an Asshole]

Blackdown provides 1.4.2 with a 64-bit plugin, so what's really keeping Sun from doing the same with 1.5 or 1.6?

Re:x86_64 plugin = Heros

[Superfluid Blob]

Do you have a reliable citation for Intel adopting the AMD64 arch name?

Re:x86_64 plugin = Heros

[angel'o'sphere]

Hehe,

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

[bill_mcgonigle]

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.

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: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:x86_64 plugin = Heros

[Anonymous Coward]

It's Intel 64 to them.

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:x86_64 plugin = Heros

[this great guy]

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 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 official arch name, AMD64. When AMD cloned the IA32 (aka i386) architecture, AMD processors were (properly) recognized as being IA32 or i386 processors, so let's do the same for this generation of processors and use the proper name: AMD64.

Re:x86_64 plugin = Heros

[bcrowell]

Hmm...interesting...this article says that there are 64-bit VMs with JIT. And this one talks about "beta versions for Windows 2000 and Linux on the Itanium platform (the virtual machine being a true 64-bit application)." Now it may be that these JITs are just compiling to x86 code, which then runs on an Itanium, so maybe it wouldn't be quite as fast as code that was specifically generated for the Itanium instruction set, but still I would think the performance would be plenty good enough for running applets in a web browser, which is what the OP was talking about. AFAICT, the issue is simply that nobody has put the work into packaging the existing 64-bit VMs as browser plugins.

Java for PS3?

[ja]

Looks like it could run, not only on AIX/PPC but on a Playstation as well:

        * 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

Re:Java for PS3?

[Anonymous Coward]

You are the king of wishful thinking.

What benchmarks?

[Anonymous Coward]

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

Re:What benchmarks?

[Max Littlemore]

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:What benchmarks?

[Decaff]

It seems like ./ eds or submitters making up crap to spice up headlines again.

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:What benchmarks?

[Max Littlemore]

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, but being the fastest is not the selling point. As a developer there is a lot more in this sdk release that warrants my attention.

my $.02

Re:What benchmarks?

[Haeleth]

By the way, is it "fastest" as in it's stuck fast and not going anywhere, or did you mean quickest?

Er, what? Fastest and quickest mean the same thing in this context.

Unless you meant "quickest" as in "most alive"? :P

This was released back in November of 2006!

[Anonymous Coward]

This was originally released back in the middle of November 2006!

http://www-128.ibm.com/developerworks/forums/dw_th read.jsp?forum=367&thread=142364&cat=10

Not all benchmarks better

[greg_barton]

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.

Re:Not all benchmarks better

[drooling-dog]

Composite Score: 482.8282568762099

Do you think they reported enough precision on those numbers? They lost me after 482.8...

Does this mean a faster Eclipse?

[Fuzuli]

That'd be nice. At the moment, eclipse has this sluggish performance when it comes to swt on linux. The VE project on my ubuntu box is much slower than in windows, and if this new jvm can perform better in this aspect, then I'm happy to read this. (there are alternatives to ve, and overall performance is fine, but again, faster is better...)

Re:Does this mean a faster Eclipse?

[owlstead]

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

Re:Does this mean a faster Eclipse?

[bill_mcgonigle]

That cost me two moderations. Why aren't moderations in a discussion depended on the *branch* of the discussion? Oh well...

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:Does this mean a faster Eclipse?

[Anonymous Coward]

So why use SWT at all? Maybe in the early days, swing was slower, but the Eclipse UI and eclipse itself crawls on my XP box, even though it uses native widgets. Meanwhile Netbeans and the swing UIs I build with it are snappy.

What did they get wrong?

Re:Does this mean a faster Eclipse?

[owlstead]

When I use a file open dialog box from spring, I cannot open folders because when I press enter to open them, it selects the folder and returns instead. That simple fact makes Swing *completely* useless to me. Swing is was and will ever be a bad idea. It's just horrible to work with as well - WAY to many members in each class, way to many options and it always tries to emulate everything - and does so badly.

There are many good things about Swing, and it's interface is surely written in a better Java dialect than SWT (the constants in SWT are, e.g., just horrible), and the functionality is astounding. But the idea of simply emulating everything is not working. The whole idea of a Java interface that looks exactly the same on any platform is just plain STUPID. People don't use many platforms at the same time. They use one platform and want everything to look and work great *on that platform*.

Netbeans is snappy, yes. It's also one of the worst interfaces that I've seen in my *life*. Note that I've tried every NetBeans version from 3 to 5.5. I always get stuck using it for even simple programs. And the content assist and refactoring are *way* behind those of Eclipse. It's better for GUI building (without additional plugins) but after my last, simple, GUI project crashed never to return to full functionality, it was the 6th or 7th NetBeans to go into the bin.

Re:Does this mean a faster Eclipse?

[Decaff]

When I use a file open dialog box from spring, I cannot open folders because when I press enter to open them, it selects the folder and returns instead. That simple fact makes Swing *completely* useless to me. Swing is was and will ever be a bad idea. It's just horrible to work with as well - WAY to many members in each class, way to many options and it always tries to emulate everything - and does so badly.

Your problem is you have set the wrong selection mode for JFileChooser.

If I do this:
JFileChooser fileChooser = new JFileChooser();
fileChooser.setFileSelectionMode(JFileChooser.FILE S_AND_DIRECTORIES);

I can reproduce your problem. But, if I leave out the file selection model setting, or set it to
JFileChooser.FILES_ONLY
then the open dialog will only return if someone selects a file and presses enter. If they select a directory and press enter, it will go into that directory.

Netbeans is snappy, yes. It's also one of the worst interfaces that I've seen in my *life*

Well, it has won awards for its interface, but I guess this a matter of personal taste.

Still makes me wonder

[Moraelin]

It still makes me wonder. Sun has been known to do crass benchmarketting before.

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 smart guys literally recognized and elliminated the _exact_ bytecode sequence of that particular benchmark. In actual programs the gains and ability to recognize dead code were _much_ lower.

Not to say IBM doesn't do the same thing, but I'd take such claims with a grain of salt. If on one particular benchmark Sun is doing twice as well, but not on the general case, well, you know what I'll suspect.

Re:Still makes me wonder

[greg_barton]

It still makes me wonder. Sun has been known to do crass benchmarketting before.

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.

Bindings

[ChunderDownunder]

This isn't to prove, per se, that the fox toolkit is any faster than gtk but that the corresponding translation to Java is.

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 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 this approach would far outperform the current offering. Maintenance would be far simpler too: no native code in the SWT layer!

Where are the sources ?

[mritunjai]

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

[Thorgal]

When started on Debian unstable it terminates immediately with:

Could not create the Java virtual machine.

This is probably caused by NPTL-less glibc. Anyone with suggestions how to fix it?

Re:Not working on Debian unstable

[Anonymous Coward]

This is probably caused by NPTL-less glibc. Anyone with suggestions how to fix it?

Yeah, fix your distro.

Do you think modern multi-threaded code that relies on NPTL-semantics is going to work with your shitty old Linuxthreads-enabled userland? Think again.

Great!

[Doctor Memory]

Now if they could only port Websphere to it! Seriously, I tried to install a web service on a new Websphere server, just upgraded to Websphere 6.0. It wouldn't run, because 6.0 only supports Java 1.4.2! The new V6.1 runs 1.5, but doesn't support web services unless you install an extension, and even then doesn't fully support the spec (only the @WebService and @WebMethod annotations). I find it odd that IBM supposedly has such cutting-edge JVM technology, but it just trickles down to their actual money-making products...

Re:Great!

[ghoul]

For IBM JVM writers Websphere is the main paying customer while all the rest are the test customers. They will no doubt port it ot Websphere once it is stable. I have run WAS 6.1 with JDK 6 but not with webservices so maybe the SOA portion needs to be ported. What exact problem did you get with Webservices?

Re:Great!

[Doctor Memory]

I didn't write down the exact errors, but I do know that it didn't recognize the @WebService and @WebMethod annotations, and ISTR it didn't support JAXB 2.0 (none of the javax.xml.bind.annotation classes). It also had some issues with my WSDL file, I think it didn't like the "RPC/document" (as opposed to "RPC/encoded") endpoint definition.

The Computer Language Shootout is useless.

[Anonymous Coward]

Dude, The Computer Language Shootout is not indicative of real-world performance at all. Microbenchmarks are inherently useless when it comes to showing the performance of a programming language implementation.

Your language implementation may do great on some 15-line microbenchmark, but when you incorporate that same code into a larger application, it can easily become a major bottleneck. These microbenchmarks often don't stress the cache as a real application would. Thus you often get far better results, just because the entire benchmark, and often any accompanying data sets, can be stored completely in the L1 cache of your CPU. This isn't the real case in any actual software that uses the benchmark code, and so performance falls through the floor.

This is often what we see with Java benchmarks. Yeah, some tiny app that does some very specific task performs relatively well. But then when part of a larger system, this same code is extremely slow.

Re: The Computer Language Shootout is useless.

[Yosho]

Ok. I'm not saying that in the real world, Java will perform just as much better than Perl as it did in those benchmarks -- but I am saying that it will still blow Perl away. It simply doesn't make sense that Java could soundly beat Perl in almost every single benchmark and then suddenly be worse in a "real" situation -- besides, many of those are possible real situations. In my job, for example, I do a lot of FFTs. A lot. Regardless of how the other aspects of the language perform, whichever language can do FFTs the fastest is generally the best for my purposes.

So, rather than hyperbole and unsubstantiated anecdotes, do you have any verifiable data that backs up your opinion?

Re: The Computer Language Shootout is useless.

[Anonymous Coward]

In my job, for example, I do a lot of FFTs. A lot. Regardless of how the other aspects of the language perform, whichever language can do FFTs the fastest is generally the best for my purposes.

Insofar as your purposes are limited to doing FFTs, yes. Of course, the language that does FFTs fastest is likely to be a language that can be compiled into libraries that can then be called from any other language you choose, so you are still likely to find yourself free to choose the language you use for everything apart from the FFTs completely without regard to how fast it can do FFTs.

The same goes for most performance-critical code, which is why more and more people are choosing languages that perform hideously poorly, like Java and Ruby.

The worst Intel64's maintainance!!!

[Anonymous Coward]

Intel64 says:

• 64-bit flat virtual address space
• 64-bit pointers
• 64-bit wide general purpose registers
• 64-bit integer support
• Up to one terabyte (TB) of platform address space <-- It's dangerous!!! It's (32+8)=40-bit !!! It will be tiny like there is not space in 256 times of 4 GiB !!!

Why? Is it the evilness Intel's FUCK YOU to all the world?

TOP SECRET, NON-DISCLOSURE, NDA, WAR, COMMERCIAL BUSSINESS, MILITARY ARMY.

WSAD Won't Support It

[curmudgeon99]

Why is IBM even bothering to write their own JDKs? Don't they know that WebSphere and WSAD are dead? JBoss and Eclipse have murdered them in their sleep. Having had to deploy on WebSphere and develop on WSAD, I would say it was a mercy killing. I would be curious to see the sources to see how they did it. See the compromises. Java Lectures for Free - Free Java Lectures

The debian shootout is worthless

[crucini]

I'm getting a little tired of seeing that "benchmark" posted. I am not some kind of blind perl-worshipper - I mostly program C++ these days. But I have to point out that the programs in this benchmark are far from the domain where Perl is commonly used. Calculating digits of PI? If you actually need to do that, use C. Trees? Not a common structure in Perl programming. The language has a built-in associative structure (hash).

The class of problems for which Perl was created is a bit more complex than integer math. The point of both Java and Perl is to manage complexity at the cost of some performance loss. In a typical Perl program, much of the CPU time is spent in the hash implementation and the regex engine. Both of these are written in C and well optimized.

Want a more real-world comparison? Check out the phonecode paper of Lutz Prechelt. (Warning - pdf).

Prechelt's data agree with my experience. Java applications are, on average, slow. Perhaps this is due to mistakes in coding or deployment. Either way, the "benchmark" on debian is self-serving nonsense.

Microsoft

[Ozgur Uksal]

In this url, http://www.microsoft.com/mscorp/java// , it is stated,
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 MSJVM on a schedule to be announced.

what doest it mean?

ozgur uksal