"As mentioned in part 1, Java 6 has to please end-users but it must also appeal to developers in order to make those killer desktop applications. I think that many GUI developers will agree that the Swing API is very powerful and flexible. That said, many feel it's too difficult and ultimately question its ability to deliver a robust desktop application (for a reasonable cost - whether that be monetary or mental!) As promised, I shall offer an overview to what Java 6 will offer developers to ease them towards putting Java on the desktop."
Post a Comment
Member since:
2005-06-29
From the article:
Because Java, like many UI toolkits, uses a single threading approach (called the Event Dispatch Thread, or EDT), directly calling resource intensive operations when responding to button presses blocks the EDT. It's this phenomena that's usually to blame for the perceived performance problems.
Anybody want to tell me what toolkit isn't single threaded?
Windows forms locks you out and throws exceptions when accessed from threads which don't own the form.
Gtk is not thread safe at all, you have to make sure to use a global lock provided by gdk.
Maybe Swing seems slow because things which wouldn't be slow operations in say, c, or C#, are slow in Java? Or are Java programmers just that much worse than your average C or C# programmer?
Certainly threads aren't more difficult to use in Java than in C.
Member since:
2006-01-06
Member since:2005-07-06
You should read part 1 (http://www.osnews.com/story.php?news_id=15883). Java has had hardward acceleration. Generally it's not enabled by default, IIRC.
Member since:2006-10-02
Swing is hardware accelerated more or less starting from 1.5 IIRC, new version brings improved OpenGL pipeline so things should looks better. Still, there is many bugs in OGL drivers wrt 2D operations, so on Linux new pipeline is disabled by default. Hardly Java fault...
Since I was following JDK6 development (weekly builds, yay!) it's clear to me that this release brings many improvements to client side. Sadly Linux part isn't as shiny as it would be... yep, marketshare, I suppose. Still there is 2 major obstacles for Java desktop apps:
- lack of MVM
- very non-agressive releasing unused memory to OS
There are many other aspects (sucky JNI, heap must be in one chunk, lack of stack allocation, desktop integration), but these two above are really killing Java desktop space.
Member since:2005-07-14
My least-favourite Java feature is the need to specify memory partition sizes on the command-line when you launch an application (like, say, Eclipse).
This was ridiculous in old versions of Mac OS (like System 7), retaining it in a "modern" and "legacy-free" platform is crazy.
- chrish
Member since:2005-07-06
This is a problem with normal GCs: they don't interact as much as they should with the VM subsystem of the OS.
Note that there have been some research on this topic and I remember a paper of a guy who made a VM-aware GC, if memory serves, he got an interesting improvement.
The big problem is that the VM must be modified for this: in his research he modified Linux's VM.
If a real GC used this, I think that this kind of patch could be integrated into Linux kernel, but for Windows..
Member since:2006-10-02
Member since:2005-07-06
I asked this in another forum, but didn't get any reasonable reply.
Can you tell me how shared class loading that Java 5 does now, and Apple has done for some time, dramatically differs from solving the primary problems folks think that an MVM will solve?
Note: http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.htm...
The primary benefits of an MVM is overall reduction in resource load and improved start up time.
Class Data Sharing does much of this, but doesn't have the problems that an MVM does. So, I'm just curious how an MVM would dramatically improve over the current tech.
Member since:2006-10-02
According to this (http://java.sun.com/developer/technicalArticles/Programming/mvm/) article current research implementation of MVM on Solaris/SPARC reduces start-up time from 60% to 90%, footprint reductions have ranged from a half to a third (it is probably less optimistic with advent of JDK6).
Startup time thingie is easy - Java MVM can work as daemon/service, so freshly started apps just connect to them - no need to spawn another instance.
Memory footprint reduce comes from fact, that much more components can be shared between Java apps. If you have JDK installed do the simple test - launch some Java app and then connect to it using jconsole. When you look at memory stats you will see that allocated heap memory can be small (few megs in case of simple GUI apps) but additional memory allocated by VM will be 20 megs or more. This memory contains VM related data and classes, jitted code and similar. Part of this data is currently shared using class sharing mechanism, but my understanding is that with MVM much more of this memory can be shared between apps.
So to answer your question - yes, in term of benefits MVM is similar to class data sharing. It just can do much better.
But when (and if) we will see MVM in action - good question :>
Member since:
2006-03-14
Member since:2005-07-06
Member since:
2005-11-13
But can anybody list any other signficant advantages of coding Java apps on the desktop, other than its ability to go cross-platform? I am not and never have been a fan of cross-platform GUI desktops apps, because it seems like you have a choice of doing one of the following:
1. Limiting your feature set to things that are guaranteed to work on all platforms
2. Have platform-specific features that don't work on other platforms.
I say if you're going to write something, you should write it to integrate fully with whatever desktop enviroment you're coding for. Each enviroment/OS has features that make it unique, and I just don't think it's a good idea to try and 'shoehorn' an app that runs on all of them.
Anyway, for those of you who are Microsoft-haters out there and are begging for more diversity on the desktop, it's not reasonable to expect that if we end up with 5-6 different operating systems to choose from, you're going to be able to build apps easily that run on all of them, and still have a native look & feel.
If I were developing for Windows, I would most definitely look to .NET, as that is basically the future of Windows development. On Linux and Mac, I would look to something that could produce native apps.
Member since:2006-01-12
1. Limiting your feature set to things that are guaranteed to work on all platforms
2. Have platform-specific features that don't work on other platforms.
AWT took the first approach you mentioned by offering barebone features. Swing was aimed at solving the first problem by making the GUI completely platform independent.
As for 2, it probably apply more to SWT than Swing.
The truth is you are not likely to need more than half a dozen integration features per platform, which can be easily handled by JNI if they are not already offered in the Java platform.
As for the look and feel, to achieve the best fidelity, you should design you GUI for the platform where fidelity actually matters (eg. OS X and Gnome. Definitely not Windows) and make use of the excellent work done by the WinLaf and Quaqua projects.
Member since:2005-11-13
As for the look and feel, to achieve the best fidelity, you should design you GUI for the platform where fidelity actually matters (eg. OS X and Gnome. Definitely not Windows) and make use of the excellent work done by the WinLaf and Quaqua projects.
Meh .. I would say when you need committees to pick apart the inconsistancies of a toolkit as compared to their native OS counterparts, you probably haven't arrived 
And don't think that fidelity doesn't matter on Windows either. Sure, we'll let you get away with a different skin, but do something as minor as show me a Save As dialog box that doesn't look like the native one, and I'll blackball you for it.
Member since:2006-01-12
Sure, we'll let you get away with a different skin, but do something as minor as show me a Save As dialog box that doesn't look like the native one, and I'll blackball you for it.
Actually, the Save dialogue boxes in almost every version of MS Office seem to differ from the Windows native dialogue. I don't think people complained about Gimp's Save dialogue often either.
Also, I am talking more about the layout of widgets.
Member since:
2005-07-14
Hey, wait, wasn't Java "5" (1.5) supposed to revolutionize everything Java, finally make it fast enough for desktop use, etc.?
Will developers ever be able to use 1.6 (oh, sorry, Java 6) for anything? All of the Java shops I've worked with have been using old runtimes... in one case, they're still using 1.3. Not necessarily because they want to, but they don't want to learn a new set of work-arounds for platform-dependant problems in the runtime.
Except for the monsterous size of the runtime on Windows, and the crazy list of dependencies on OS X and Linux, I still think .NET/Mono are doing things better, despite Sun's long and well-publicised head start.
- chrish
Member since:2006-01-12
All of the Java shops I've worked with have been using old runtimes... in one case, they're still using 1.3. Not necessarily because they want to, but they don't want to learn a new set of work-arounds for platform-dependant problems in the runtime.
Are you talking about Java Enterprise platform or Java Desktop platform?
All in all, writing portable java programs (or porting) should still be easier than writing portable C (or porting) programs.
Member since:2005-07-06
your comments are far from truth.
Monstrous size? .Net is much bigger then JRE. and what crazy dependency and platform-defendant problems are you talking about? i know there are real and immense platform dependency issues are with .Net and Mono. give me a break, Java does the best job on platform independence considering the variety of application types (Gui, web, portable..) . talk about FUD.
Member since:
2006-01-12
Since multithreaded OGL is already available on OS X and is probably quite stable, I am assuming the problem with Java 5's MT OGL pipeline has everything to do with poor OGL drivers on linux as opposed to problems with the implementation itself.
I just hope OGL drivers on linux would improve so that they would be able to bring MT OGL back someday.
Member since:2006-10-02
Sun Java 1.5 had multithreaded OGL pipeline, but this different thing and has nothing in common with single-threaded aspect of Swing. Probably every major UI toolkit is single threaded, read here - http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.ht....
Java 1.6 OGL pipeline was rewrited and made single threaded:
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_impr...
http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_pe...
Java for OS X is developed by Apple. Since they know their OS better I assume that Swing is hardware accelerated when possible...
Member since:
2005-07-12
There are currently more Swing apps than Eclipse RCP apps. But that's because Swing has been around for ages. Eclipse RCP is the new kid on the block. And it seems that Eclipse RCP is gaining ground quite quickly. The list of Eclipse RCP based apps, both proprietary and open source, is getting quite impressive. Adobe Flex Builder is currently the most high profile of the proprietary apps, and Azureus, RSSOwl, RadRails, Weblogic Workshop, and Eclipse itself, are all good open source apps.
I don't care about Swing vs SWT, or Eclipse vs NetBeans arguments / flame wars.
But it does seem that the SWT / Eclipse RCP native look and feel, reduced memory usage, and shorter load times, and overall better speed, are all big wins in favor of Eclipse RCP. Not to mention that Eclipse RCP is a great framework upon which to build applications, taking care of much of the plumbing/infrastructure work.
Is SWT / Eclipse RCP perfect? Of course not. Is it better then Swing? That's a toughy - Swing is looking quite nice these days, but still has problems with memory usage, start times, copy and paste, and most of all, fonts.
And Eclipse RCP is about the only thing I really like about Eclipse, or just basic Java development. Try doing anything J2EE with Eclipse, and you're up for hellish torture.
Member since:2006-02-25
Sorry for beating an old drum (already mentioned it here on various comments), but not all are aware:
SWT/RCP do not support BiDi interface (for right to left written languages like Arabic an Hebrew) on anything but windows. This renders it unusable for many developers.
Swing supports it well enough.
Member since:2006-10-02
Eclipse RCP isn't exactly new kid on the block. I've seen much enthusiasm when SWT appears, but now most ppl agree that in respect to memory requirements, start time and speed both toolkits are comparable. SWT has better integration on Windows platform, but thats all.
Talking about RCP - this is distinct issue. I think that Eclipse has better plugin architecture, documentation and *much* better PDE. That't the real advantage
Member since:
2005-07-06
Flash and Javascript are now the standard for rich web front-ends and .NET is the preferred toolkit for windows.
The main 2 reasons for that is that they are all easy on the eye and are pretty simple to use.
Java for desktop was until now over engineered and its looks disliked by end users....
SUN should spend their resources on something else.
Member since:2006-10-02
Member since:
2006-03-20
Member since:2005-07-06
