OSNews

Short answer - yes Much faster

Client mode will be much faster - I don't think the server mode has sped up much, though.

server/enterprise will be the center of attention for the next release, i think they call it dolphin or something like that

Can you comment on whether Swing itself will be faster?

Well, I've been using some of the weekly builds, and whilst I can't quantify it, Swing is definitely more responsive.

Actually, i dont know why the person who wrote the this piece of news mentioned about web 2.0 or not so important aspect basic "scripting support". Java 6 does not have stuff directly related with Web 2.0 (Except the Sun JDK -not JRE- will contain Rhyno, Javascript for Java ) and nobody actually said something like that.. On the other hand, it has tons of client side improvements.

A good list of new features can be found here:

http://java.sun.com/javase/6/webnotes/features.html

It amazes me even today, how People thinks java is slow. It seems even with the faster versions comming out, people are still same.

I keep hearing how fast and cross platform java is and I have even seen benchmarks showing its speed, but for some reason all the java applications I use are still god awful slow.

My other pet peeve is that much of the software I have used seems to have specific JVM version requirements which pretty much offsets any gain from being "cross platform".

I don't know exactly where to put the blame for all the poor java software I have used, maybe the problem is in poor implementation rather than in the language used.

Either way the end result seems to be that I have used so much bad java software I have a distaste for the language even if the marketing material and benchmarks tell me I am wrong.

I keep hearing how fast and cross platform java is and I have even seen benchmarks showing its speed, but for some reason all the java applications I use are still god awful slow.

I think java GUI toolkits could use some optimizations, and it is getting them in 1.6. It seems as though responsiveness is often an issue with java programs, which gives the user an impression of being slow even though the actual work is being done quickly - maybe there are also some GC issues impacting this? Java is quite fast if you just run console apps with little interaction. Some java apps are quite good, so it is clear developers can work around any performance issues if they try hard enough. Netbeans, for example, is built entirely on Swing and runs quite well in Windows, at least on my computer (which has tons of ram and a fast cpu - maybe on older systems I could see a problem).

My other pet peeve is that much of the software I have used seems to have specific JVM version requirements which pretty much offsets any gain from being "cross platform".

I'll admit that "cross platform" is a bit of wishful thinking, but I haven't had too many issues - pretty much everything will run on Sun's 1.4 or 1.5.

"I think java GUI toolkits could use some optimizations"

That is truly an understatement.

I've used Java, I cut my teeth on the language before switching to C++ and it's not bad. It's pretty fast when used for console applications, but when you try to write graphical applications using Swing the speed drops so much you wouldn't know it was the same language.

What probably did the language in for me though was the lack of integration into the OS. Even new scripting languages developed by people of far less fame than Sun microsystems integrate into Windows and Linux to the point where only double clicking on the file will cause it to run. Java on the other hand needs to be paired up with a launcher, or in Windows it can simply be packaged up into a jar file, although once an archiver program supporting that format is installed it fscks up that association and you're back to having to write a launcher application or script.

Sun does need to improve Swing performance very much, frankly they aught simply to do what the swt project did and tie it into the native toolkits, even if that doesn't provide a consistent look across platforms. They could also use Qt if they don't mind the license fees because that supports the big three operating systems and then some, or they could use wxWidgets if they'd rather keep it free, although I'd feel resentful if they picked a tookit which integrated into Gnome really well and looked hideous in KDE. Sun's best bet may be to expand the OpenOffice.org widget set for Linux and Windows to the point where Java can use it to replace swing. OS X isn't Sun's problem as far as I know since I think Apple writes their own JVM.

You know a swing needs optimization when you have a program sporting two dozen or so of its widgets minimized for a few minutes on a computer with a 2 Ghz processor, 512 MB of ram, a GForce FX 5200 video card and no other software running, and when you bring the program back up you can hear your hard drive grinding for several seconds while the computer painfully repaints those widgets one item at a time. This doesn't happen with Java console applications, and it makes me wonder why Sun Microsystems ever though it was reasonable for a toolkit that's used for desktop and workstation applications; after all, servers wouldn't need to use swing much, config files and CLIs are what server admins tend to use.

"I don't know exactly where to put the blame for all the poor java software I have used, maybe the problem is in poor implementation rather than in the language used. "

Most certainly.

For instance, I know lots of programmers who concatenates string (with the "+" symbol) instead of using StringBuffer.

Sometimes, it is justified. But for instance, I managed to make a colleague's program run FIVE TIME FASTER than with the original code by using StringBuffer.

IMHO, lots of people make the error to think they do not have to manage the memory. They are wrong. The garbage collector is a helper mechanism, but not the panacea. And sometimes, lots of objects are instanciated unusefuly, which cause lots of delay.

In fact, people should code in Java like they would code in C - and even if we have to think in C, it is more pleasant to code in JAVA IMHO. If not... it is quite logical that programs are slow.

Edited 2006-06-22 06:33

"For instance, I know lots of programmers who concatenates string (with the "+" symbol) instead of using StringBuffer. "

I did the same thing, d'you know why? Because all the text books taught me to do it that way, and the same is probably true for your colleague. I wasn't introduced to the StringBuffer object until very late on, by then I was already transitioning to C++. Such features need to be introduced early on in textbooks and need to be reinforced though use in the sample code where appropriate.

"IMHO, lots of people make the error to think they do not have to manage the memory. They are wrong. The garbage collector is a helper mechanism, but not the panacea. And sometimes, lots of objects are instanciated unusefuly, which cause lots of delay. "

Many text books will not tell people these things. I had more Java text books than I have C++ text books, yet I learned proper memory management from the C++ books, with one particular book touching on the topic in great detail throughout the whole book. In comparisson none of my Java textbooks did more than introduce the topic, instead they took the garbage collector for granted.

"it is more pleasant to code in JAVA IMHO"

Java has it's advantages, from being very backwards compatible to being a language that became the de-facto standard in many CS courses. I've had a hard time letting go of it, and ultimately I kept almost all my books and still maintain one of my Java applications; but I much preffer C++, especially since Swing cannot yet be made to go at a reasonable speed on the desktop. I'd pick the language up again if Sun could fix the two things that bug me the most about it. It is that easy, just two things: integration into the OS, and Swing being far too slow, yet Sun hasn't fixed these problems despite knowing about them for years.

And I know a lot of programmers who persist in using StringBuilder instead of StringBuffer despite working in Java 5 environments and making use of generics.

e.g.

public String prepParameterisedString(String A, String B) {
StringBuffer buf = new StringBuffer();
buf.append("start string ");
buf.append(A);
buf.append(" middle of string ");
buf.append(B);
buf.append(" end of string");
return buf.toString();
}

this would be faster if you use StringBuilder as StringBuffer is thread safe and therefore has monitors or locks (not sure exactly how implemented) which are unnecessary in this usage. :-)

For instance, I know lots of programmers who concatenates string (with the "+" symbol) instead of using StringBuffer.

In Java, all concatenation is done with StringBuffer. Including the "+" operator.

Please show your bencmarks.
The benchmarking I did for some of our code showd it is *fast*. About 5 times on average faster equivialent pythin code, and only 10% slower (one routine not withstanding that was twice as slow) than the equivialent C/C++ code (yes it was a mix of C/C++ :-( )

Relative to others Java still is a memory hog, has slow VM startup time,and GUI/Swing (which our benchmarked routines didn't use) feels slow.

Give it an x86-64 and 2 GB of RAM, S-ATA RAID and what not. And then java applications are actually reasonably speedy.

Try Azureus with such a system and then try it on a 1.5 GHz system with "only" 1 GB RAM og and some lame old-style ATA ( pretty much my system )

Azureus is butt slow on my system, while it has an almost acceptable performance on a x86-64 system.

That said, I have to say that not all Java applications are as bad as Azureus. Eclipse is just as bad, but jrisk isn't -it just has some annoying bugs, but it's small and - if not fast - at least not as slow as Azureus and Eclipse.

People who are claiming that Java is slow is probably talking about Hotspot Client version's performance. While people who are claiming that Java is reasonably fast is probably talking about the Hotspot Server version's performance.

Hotspot client version before Java 6 does very little JIT optimization in order to lower memory footprint and startup delay. Java 6 brings a number of important performance improvements to the client version.

http://jcp.org/en/jsr/detail?id=223

Cool, looks great. I especially like how well it blends in with the system UI.

Romain knows his stuff when it comes to making Swing look great.

It's worth also checking out two articles published by OSNews about Java's appearance and speed, with the former featuring quotes from Romain:

The Java look-and-feel debate (http://www.osnews.com/story.php?news_id=10633)

The Java performance debate (http://www.osnews.com/story.php?news_id=10729)

I also borrowed technics outlined by Romain to make my own Swing app, if I do say so myself (http://www.andy-roberts.net/software/jacman/index.html)

"You can take ANY languages and make slow application. Slowness and slugishness isn't a Java exclusivity... "

Poor programmers using C and C++ can write faster graphical applications with GTK, Qt or wxWidgets than good programmers can with Java and Swing. Well written Java applications can reduce the drag enough to make up for the remaining lack of speed by being high quality applications. But the fact remains that Swing is so slow that it won't run on the majority of computers in use today with acceptable speed. For example, I'm contemplating writing a new gradebook program for my Physics teacher, he's using a very old Mac for one gradebook program which has a feature that isn't available in any Windows software. I thought I'd reproduce the application for Windows, or preferably rewrite it so it's portable. Java would be ideal for the task, but it's just too slow for every computer in the school right now, and that's not uncommon in schools and businesses. Because of this I'm porting my applications from Java to C++ and Qt and I'm investigating wxWidgets as a possibility.

Don't get me wrong, I would really like to be able to keep using Java. But speed as well as OS integration are too inconvenient at the moment.

As far as i know this will not happen for Mustang (JSE 6) release. i guess open sourcing such a huge project takes time and makes a lot of desicions to take. This is IMHO more difficult than open sourcing Solaris for Sun.
But of course, one may ask the old question, what difference does it make while you can see the code and contribute to it today...