Sun Microsystems on Wednesday released the second beta of Java 6, the company’s next-generation development language targeted at so-called Web 2.0 programmers. Perhaps most enticing for those new to Java, the update adds a framework for supporting popular scripting languages such as PHP.
I heard somewhere that Java 6 will be much faster than previous versions. Is that true already?
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.
There’s another of those worthless phrases I just love to hear. Amazing it’s written *everywhere*.
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 slow Java is. It seems even with the faster proccessors comming out. Java is still slow.
Neal Saferstein
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.
You can’t expect a language that needs to be compiled to run on double click!!
If you install a JRE it runs jar files with douple click, as expected. It also install webstart for jnlp files.
“You can’t expect a language that needs to be compiled to run on double click!!”
What? Did you phrase that right? C and C++ are compiled directly into binaries, they run with a double click. And just in case you mean interpreted languages don’t run with a double click: Ruby, Python and Perl programs whether precompiled or not also run with a double click. See, the interpreters set the file associations up correctly in Windows, Linux and OS X. That’s not the case with Java though.
“If you install a JRE it runs jar files with douple click, as expected.”
In Windows, and perhaps OS X (although I haven’t ever used the later). Although in Windows the file assocation is easily broken by archiving software that tries to snatch the extension for itself, it’s really far too fragile a system, and it’s not even implemented on Linux but instead needs tedious manual work to set up. That’s hardly a portable solution.
“It also install webstart for jnlp files.”
That’s no replacement for the time tested method of telling people where they can download a file that’ll run with a simple double click, and it involves a lot more work in Linux because again Java’s Linux integration is sub par even compared to amateur languages.
You expect java files to run by double clicking them, this isn’t the case – nor is it with c/c++. You’d have to compile them into somekind of binary first (the class/jar file, in Java’s case).
This is much unlike scripting languages which can be run immediately.
“Although in Windows the file assocation is easily broken by archiving software that tries to snatch the extension for itself, it’s really far too fragile a system,”
Well, thats not really the JRE’s fault, now is it?
IF some random program snatched the .exe, .pl or some other extension that would be the exact same problem.
As for JNLP integration that will probably change a lot now that the JRE is distributable by linux dists.
“You expect java files to run by double clicking them, this isn’t the case – nor is it with c/c++. You’d have to compile them into somekind of binary first”
That was implied.
“(the class/jar file, in Java’s case)”
How does this keep getting compared to exe files. Java’s jar archives aren’t set up to work by double clicking in Linux, and in Windows the file assocation is broken by many of the archiving applications. It’s absolutely unreliable.
“This is much unlike scripting languages which can be run immediately. “
I made two comparissons, one for compiled and one for interpreted, just so I covered both bases. I never implied that C++ source files would run just as they were.
“Well, thats not really the JRE’s fault, now is it? “
Frankly I think it’s a matter of bad desing when something as important as a programming language can be crippled by installing an archiving program. Sun could have at least changed the file association and/or complained to the developers of the infringing archiving programs when it first became a problem. Most people will pick an archiving program over a runtime environment for a language that they don’t care much about anyway, and if it was sabotage Sun didn’t put up much of a fight.
What’s worse is that in Linux there is no file association for Java programs, and the location of the JVM varies with the installed version so writing a launcher script is complicated by the fact that the JVM isn’t in a predetermined path.
“As for JNLP integration that will probably change a lot now that the JRE is distributable by linux dists.”
It was distributable with Linux for a long time, as long as distributions didn’t include any other JREs with their distributions, and it hasn’t been integrated on more than five distributions so far. JNPL is a redundancy most Linux users won’t want, all it does is let them preview and download Java applications they want to use, but of those that do use Java applications, they don’t use enough to want something like this on their computers. Java is even less popular on Linux than on Windows or OS X.
I’d love to see Sun fix the many problems with Java that reside outside of the actual language component itself, but I haven’t seen them put in much of an effort.
“Java’s jar archives aren’t set up to work by double clicking in Linux, and in Windows the file assocation is broken by many of the archiving applications. It’s absolutely unreliable.”
Again, this isn’t Javas fault. The linux dists need to handle this better, and as for file associations – thats really not Javas fault either. This goes for ANY file in windows. I could have set .exe fileassociations to UPX. Does that make c/c++ binary files broken? – no, nor is jar files.
“I made two comparissons, one for compiled and one for interpreted, just so I covered both bases. I never implied that C++ source files would run just as they were. “
But why did you imply that java can run without being compiled then? – you DO know the language isn’t interpreted anymore, right ?
“Frankly I think it’s a matter of bad desing when something as important as a programming language can be crippled by installing an archiving program”
right, see first argument. The efact that other programs *steal* file extensions is a fault of the OS and the program stealing, hardly Javas fault!!
“What’s worse is that in Linux there is no file association for Java programs, and the location of the JVM varies with the installed version so writing a launcher script is complicated by the fact that the JVM isn’t in a predetermined path.”
Take that one with your favorite Linux distribution, its not Javas fault.
Fact of the matter is that *binary* files don’t even run under linux (until you chmod +x ’em) – much the same thing as jar files on windows (tagging to be identified as executables), yet somehow it’s ok for linux c/c++ binaries…….
“It was distributable with Linux for a long time”
That it was distributable doesn’t change the fact that it wasn’t distributed.
“I’d love to see Sun fix the many problems with Java that reside outside of the actual language component itself, but I haven’t seen them put in much of an effort.”
Since you’re obviously not looking, or you’re looking for the wrong answers, thats not going to happen.
So, to sum it up.
You need to invent a format that is executable on all known and unknown platforms, that executes on double click. Best of luck.
Or you could use a format that relies on a “handler” of some sort. Which brings us back to the problem. How does the handler know what to handle, by fileassociation of course (or other meta data).
Right so lets setup a handler that handles our own new file type, lets call it a Java ARchive or jar for short.
Lets make it easy to handle for developers and distributers by making it a zip file with a special file (manifest). That way it will run on all platforms that have zip support – including mobile phones.
Then comes along a rogue program that *steals* the association, and then you blame Java??
Would you have them encrypt the file – thus alianating everyone, just for the sake of some rogue programs?
It’s *exactly* the same thing that happens on a day to day basis with many formats, including html (which I open in a text editor *gasp*) or mp3 (that some programs always want to steal from foobar). It’s not Java’s fault, it has never been.
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.
I don’t see the point of switching Swing back to the AWT/SWT approach. In fact, I believe it’s far better to have a choice between native widgets (less portability) and Java widgets (less HIG conformance). Also, SWT isn’t the answer to GUI performance problems. While it may perform adequately on Win32, it is extremely slow on OS X.
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.
QT uses the same approach as Swing, except Trolltech did a far better job of emulating the native theme. Swing can also look native, just look at WinLaF and Quaqua.
wxWidgets is not exactly usable on OS X and it is very ugly on linux and OS X.
“I don’t see the point of switching Swing back to the AWT/SWT approach. In fact, I believe it’s far better to have a choice between native widgets (less portability) and Java widgets (less HIG conformance). Also, SWT isn’t the answer to GUI performance problems. While it may perform adequately on Win32, it is extremely slow on OS X.”
Then I believe the solution for you would be to use native widgets when using a native LookAndFeel, and using Java’s own widgets when using Java’s own LookAndFeel. Anyway the OpenOffice.org widget set could be expanded by Sun and used to provide something with the functionality and consistency of Swing but more standard looking. In case you don’t know this, the OpenOffice.org toolkit looks identical in Linux as in Windows when packagers don’t tinker with it to make it’s appearance biased to one desktop environment over another.
“QT uses the same approach as Swing, except Trolltech did a far better job of emulating the native theme. Swing can also look native, just look at WinLaF and Quaqua. “
Qt paints its own widgets, but it doesn’t do so using an already slow language. Qt is sometimes faster than the native toolkit, I can attest to that.
Anyway, looking like it fits in isn’t as important as running at a resonable speed. Tell me, if servers are mostly administered through configuration files and command lines, what is the point of a widget set as complex as Swing if not to write desktop and workstation software. Would you consider Swing to be fast enough for desktop and workstation use? Most workstation are not high end machines, in fact many businesses I’ve seen have yet to upgrade from boxes that are around a decade old, and even home computers don’t run Swing at an excusable speed. Perhaps Sun should drop Swing altogeter and let people learn how to use swt instead.
“wxWidgets is not exactly usable on OS X and it is very ugly on linux and OS X.”
As I understood it, on Linux it can use the Xforms toolkit or it can use GTK, and on OS X I think it’s supposed to use the native toolkit. I think wxWidgets would be completely indistinguishable from a normal GTK application on Linux, although admittedly not everyone things that looks good. As for OS X, Apple makes its own JVM.
Have a look at some of the screenshots if you’re interested: http://wxwidgets.org/about/screensh.htm
“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. 🙂
One of the benefits of Java 6 is escape analysis and lock elision. In your example, the compiler could detect that the StringBuilder instance doesn’t escape from the method body and choose to remove the synchronization.
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.
Perhaps most enticing for those new to Java, the update adds a framework for supporting popular scripting languages such as PHP.
Anyone have more info on this?
Henrik
http://jcp.org/en/jsr/detail?id=223
I just wanted to add my 2c to the swing hammering, Swings ui speed also depends on the platform and partially on perception.
I will give an example. Open a menu in swing on windows side by side with a windows native program, swings menu opens twice as fast as the native windows program, but the windows program feels faster. Reason, swing opens it in one push mostly double buffered, windows does not use buffering and achieves a fade in effect.
Same goes for menu movement, which is known as the grey box problem, which is if you move a menu in swing you see a grey box for a short period which gives the perception that the movement is slow while in fact the menu already has been moved.
There are myriads of these small perception problems. JDK 6 cleans a lot of them up. Swing feels really being faster.
As for the minimizing problem, here is memory fragmentation and hence the inherent constant windows swapping an issue, native windows uis do not run into this problem because the ui lib runs in ram only, while if you leave a swing or generally any app open the mem can become fragmentet and it is swapped out, this is not that visible on console apps, because they often do not net an adhoc response or run in constant cycles, but in swing this is unfortunately very noticable because once you deiconize the app, the memory fragments become swapped in and voila the app suddenly needs the swapping process to finish before being able to draw several parts of your window.
However afair, there is somewhere a jvm param to prevent that problem. (at least in newer jdks) i do not have the param handy now, but if someone can post it I would be grateful.
It is not that I do not say that the problems are not there, but often the perception is worse than what really happens, and especially in the ui area the JDK 6 cleans a lot up regarding this small programs.
In my opinion Swing has a reputation well deserved in its first incarnations, but in the current state of affairs I would say Swing is one of the better toolkits around (definitely better than SWT and GTK2)
It is better to switch to another skin anyway than to use the native look and feel. (most users can cope easier with something completely different looking than something being 98% right)
the more interesting stuff is under the hood, native scripting support and finally standardized bytecode weaving, which in the long run could be a killer combination, because you basically now can hook every scripting language there is into the jvm and not only interpreted but fully compiled.
Dynamic class change, no problem, bytecode weaving can take care of it, dynamic type change, ditto.
Also this lays the foundation for a standardization of orm mappers into the jvm on a bytecode level. The JPA is the first sign of things to come, it in the long run will become a standard VM extension, and some JPA implementations already use bytecode weaving (which caused problems in JDK5 on non Sun VMs because the weaving mechanism was not standard then)
Add annotations to the mix and you have a real killer combination.
If you feel that Java GUI are slow or ugly, please check out this example I wrote with some colleagues at Sun for JavaOne 2006:
http://www.jroller.com/page/gfx/?anchor=aerith_a_very_cool_swing
There is also a link to a video of the application so you can see all the animations in the UI.
The source code will shortly be available at http://aerith.dev.java.net
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…
Take NetBeans for example, the first version weren’t optimized or polished enough for day to day uses. Now, I look at it and it is now acceptable performance-wise, it’s great looking, got great features, etc… NetBeans is GREAT example of what a strong Java GUI Application can look like if the programmers put their mind into it.
As a Java Developper, I’ve noticed that the best looking Swing Application are the one that are NOT constructed using a WYSIWYG GUI Editor…
“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.
Does anybody know if Java v6 will be released under CDDL, GPL or other OpenSource license? I know that Sun promissed opening Java, and I think that Java version 6 could be good time to do it. I’m hopig v6 will be free software.
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…
I find it odd that people presume that every developer using a particular language are as well-versed in that particular language as are the engineers who developed the language.
I don’t care what the language, it’s going to take several years to become proficient and well-versed in any language. Someone should do a study on the relationship between app performance and language exposure.
There were lots of valid arguments, but please, the comments sound like none of those guys critizizing Swing had a look at JDK6 so far. The situation has improved tremendously Swingwise again.
There so far were two big boosts regarding Swing. JDK 1.4 pushed the Swing rendering on Windows into DirectX (it stayed the same on the other platforms)
and then 1.6 which really is way faster than before.
Some said that Qt did a better job speedwise, yes, but I rather doubt the language is the issue there. I think it simply is the fact that Qt was better optimized.
Before further commenting how slow Swing is, try JDK6 first and then comment.