Linked by Andy Roberts on Thu 19th May 2005 19:33 UTC
Java Java Swing comes with "pluggable look-and-feel technology", which essentially boils down to the fact that interfaces can be "skinned" (although this is simplifying a tad) and is therefore, extremely flexible. By default, Java ships with a cross-platform look-and-feel (LAF), which means your apps can look consistent across all platforms, or LAFs that mimic the look of a specific platform, say Windows, for example. However, one of the chief complaints of Java desktop applications is its "look". It basically stems from two issues:
Order by: Score:
Java Look-and-Feel
by DoctorPepper on Thu 19th May 2005 20:02 UTC

The Java look-and-feel "problems" don't really bother me. I realize some people get all hung-up on the look of their app, and that's cool too. For me, the ease of development, functionality and cross-platform support are far more important.

It's not really the ugliness ...
by Darius on Thu 19th May 2005 20:07 UTC

When I'm using a Java SWING app, it's not really the way it looks that bothers me - it's the way it feels/handles. You can paint it up to look just like a Windows, but when I'm using it, I can instantly tell it's a Java app, because it's usally running (or shall I say, crawling) about half the speed of my other native apps.
Honestly, Java on the desktop sucks and needs to go away, and .NET along with it. It benefits only developers who want to write cross-platform apps - it has absolutely no benefit to 98% of us who only run one OS full-time. I'm speaking as an end user who is tired of developers making excuses for the piss-poor performance of these languages, virtual machines, or whatever the hell they are. I never run Java apps unless there's absoltuely no other alternatives available. I don't really run .NET apps either, but at least they're a helluva lot more consistant with the way that native apps on Windows behave.
If you want to write cross-platform apps, either do it with C++ bindings or find another way to make them run respectably.

OS X
by Myrd on Thu 19th May 2005 20:09 UTC

I feel that the way the guy just puts Mac OS X aside is a bit unfair. Especially when he brings up some semi-crappy LAF and says "it should be good for any platform." Yeah right. No offense, but such a GUI will not fit at all with standard Mac OS X apps, so no it is not good for any platform. And just as wih Windows, Java Swing apps on the Mac do have some inconsistencies with their native counterparts. Just from the GUI I can tell that it's a Java app, because the way the widget work and look is generally less polished, etc than default Carbon or Cocoa widgets. If he hasn't really used Swing apps on Mac OS X, then he shouldn't comment on it and just admit that he has no experience there, not just say "it's good enough there, not an issue".

RE: It's not really the ugliness ...
by Abraham on Thu 19th May 2005 20:11 UTC

Either your machine is extremely slow or you're running an older JVM, but I use Swing apps all the time and honestly I don't notice a difference.

Netbeans
RSSOwl (SWT though)
JAlbum
LimeWire

To be honest the speed isn't that bad

RE: It's not really the ugliness ...
by Myrd on Thu 19th May 2005 20:12 UTC

No benefit for cross-platform apps? How about the fact that they're there. Guess what, if it was written in some non cross-platform manner, chances are you wouldn't be running it because it wasn't made for your platform. Cross-platform development does give more benefit for end-users, simply because they get more apps to run. Also, if you say "well they could do it natively for both", then that still doesn't solve the fact that it will take more time, making either less apps (made by the devs over the same time frame), or poorer quality but same number of apps (over same timeframe). Either way, you _do_ benefit from cross-platform development.

Good review
by Andrewg on Thu 19th May 2005 20:13 UTC

Good level headed review. It shows Swing can be used to make good looking apps. I especially like the imagery app http://www.xerto.com/images/screen-shot.png

That is one of the best looking apps I have seen.

@Darius - I find Java, especially 1.5 to be fairly fast. It is also just going to get better and better. The benfit of using Java is you get a nice language with an excellent standard library, which can be used to make apps quickly. And finally we are seeing that good looking, fast cross platform is possible too.

NetBeans
by Juan C Nuno on Thu 19th May 2005 20:24 UTC

Yes, I have to agree that the default Swing LAF sucks. But it doesn't keep me from using NetBeans at work. And the performance is just fine for me.

And what do I use NetBeans for? Java GUI development. I think Java is a badass language, the libraries are rich and very useful, and I actually enjoy using Swing and the Java language in general. Swing is not pretty by default, but that's what pluggable LAFs are for. My favorite is the Alloy Look and Feel.

forget it
by Dracula's dead star attorney on Thu 19th May 2005 20:24 UTC

Linux and Solaris users, for instance, are used to seeing mixed toolkits on the screen.

Used to does not mean that everyone likes that. I solely use Qt and Gtk-2 applications, everything else is banned. And I'm still pissed about the fact, that even with the gtk-qt-engine, Gtk-2 applications just look nearly as my Qt ones. Java desktop applications (aside Eclipse,SWT/Gtk)!? Thanks, not for me.

This whole native debate...
by CaptainN on Thu 19th May 2005 20:30 UTC

I think this whole native look and feel debate boils down to a simple lack of understanding about the difference between Application development and UI design.

Developers want a tool kit that will allow them to through something together and have it look as polished as a well designed Apple or Microsoft application.

Well it just isn't going to happen, no matter how good the tool kit. If you want good design, hire a designer.

These are two separate and important disciplines.

AA Text and Metal/Ocean
by Anonymous on Thu 19th May 2005 20:33 UTC

Probably 90% of the problem has to do with the above. The text looks quite poor and it's really annoying that you can't change it easily globally, and the default theme really is atrocious (can't choose a strong enough word). Certainly developers can change the look and feel, but so many of the freely accessible applications that will give people a perception of java will not bother changing the default.

So I guess I'm in the camp that thinks it's ok to have different looks/toolkits, but it might be nice to be able to "fit in" as an indistinguishable application if that's what you want as a developer.

As several people have stated, providing an almost approximation of the graphics of a native application can sometimes do more harm than good.

All of this aside, take a look at how Mozilla Firefox has managed to distribute a cross platform application that has native look and feel with OS/desktop integration that performs quite well. Why Swing/SWT (Sun/IBM) have such a hard time with this I don't quite understand.

GTK+
by Anonymous on Thu 19th May 2005 20:35 UTC

I use 100% GTK based applications. Java applications stand out like a sore thumb.

RE: AA Text and Metal/Ocean
by CaptainN on Thu 19th May 2005 20:36 UTC

Maybe they should just include a Mozilla module and have everyone define their UIs in XUL. I think I heard that something similar was coming to Mono - that would be even better, to define the UI of an app in the same way in both Java and C#.

RE: It's not really the ugliness ...
by Romain Guy on Thu 19th May 2005 20:40 UTC

I understand your concern. The fact is developing a Swing application does not give you good performances for free. You have to know how Swing works. When you do, then you can use it wisely. The most common problem is related to event handling and the Event Dispatcher Thread (EDT). When you click on a button, your code runs in the EDT and if you perform long operations in this thread, you block the whole app. There are dozens of good documentation about how to work around this problem and it is very easy. When you do that correctly, 90% of the responsiveness problems disappear.

Myrd: Blaming Java application for not looking perfectly native on MacOS X is not relevant I think. First, remember that Java needs to cope with multiple platforms and it cannot, at least easily, offer a perfect look and feel on each of them and still bring you the portability you would expect. Having a perfect Windows XP look and feel and a perfect Aqua look and feel for the same app can be very tricky: the differences between them might totally break the UI design. An application that looks fine with Plastic look and feel might just looks awful with Aqua, because its layout is not optimized for this look and feel. This is a very complex issue. At last, as much as I love my Mac and MacOS X, let's be honest, there are a lot of inconsistencies accross the applications shipped with OSX. Java on MacOS X needs attention on other more important issues. There are real problems with complex painting operations for instance, both in Java 1.4.2 and Java 1.5.

RE: AA Text and Metal/Ocean
by Romain Guy on Thu 19th May 2005 20:44 UTC

The anti aliased text provided by Java until version 1.5 is awful because it does not allow to do subpixel anti aliasing (or ClearType or whatever). It should be available in Java 1.6 though and this will definitely help.

And Firefox and Thunderbird do not totally succeed in looking and feeling like native applications. On my P4 1.6 Ghz laptop, FF/TB menus are not as responsive as in other applications for instance.

It's not really the ugliness ...
by Davy Mitchell on Thu 19th May 2005 20:57 UTC

I agree speed is the main issue.

On my desktop Python, C# all run fast but Java apps are always slower. Even Goslings own applications...

@Darius
by SpookyET on Thu 19th May 2005 20:59 UTC

Let's see what you have to say when 5 years for now most of the new apps for windows will be written to target .NET! Don't put .NET in the same box with Java.

RE: It's not really the ugliness ..
by Romain Guy on Thu 19th May 2005 21:00 UTC

Java applications do not run slowly, they APPEAR to run slowly when they have a GUI, because of some misunderstanding of the Swing API (which, I reckon, is sometimes hard to use). Seriously this is due to how the toolkit is used.

Slight tangent
by Rayiner Hashem on Thu 19th May 2005 21:12 UTC

I'm a big believer in having the same L&F throughout the platform, and I think MacOS X and GNOME do an excellent job of that. What gets me, however, is how inane the Windows UI has become. The three screenshots there are pretty funny --- you could have easily added Visual Studio.NET to the mix to up the total to 5 different L&Fs in Microsoft's own applications. The Office screenshot was particularly jarring. I'd never seen Office XP until now, and I didn't realize that the horrid Keramik rip-off had infected the *entire* Office lineup. I had the impression it was just Visio...

Why does Microsoft do this? Especially when Apple seems to have no problem keeping things coherent?

Swing rocks
by fedetxf on Thu 19th May 2005 21:16 UTC

I use Sswing applications every single day. JEdit, Squirrel-SQL. The Ocean Theme rocks. The metal theme is ugly, but even when Squirrel has support for downloading specially made themes I prefer the default. I also use Netbeans. I don't even have 2d acceleration (Diamond Stealth 64 DRAM 2 MB PCI card with S3 chipset) and I see it runs very well.

People like native over anything else so they complain. When you don't have to code everything, you can always ask for a pure C solution or all native toolkits.

wxWidgets?
by ralphy on Thu 19th May 2005 21:18 UTC

why isn't everyone using wxWidgets yet? It uses the native toolkit of whatever platform you're on, and everyone's happy.

I've distributed a number of apps using it, and it's great.

RE: It's not really the ugliness ..
by fedetxf on Thu 19th May 2005 21:23 UTC

Java applications do not run slowly, they APPEAR to run slowly when they have a GUI, because of some misunderstanding of the Swing API (which, I reckon, is sometimes hard to use). Seriously this is due to how the toolkit is used.

Right. I learned to use it the right way and having buttons and menus return control instantly while the task runs in the background rocks. It just needs arranging the long running task call and that's all. Swing is great once you get into it a bit more than a simple GUI builder allows you to.

After all these years
by Mike on Thu 19th May 2005 21:30 UTC

After so many years of research, it still amazes me what a mess most desktops are. I'm no zealot, but when it comes to the GUI I am all for consistency. For instance, the official Apple guidelines state that the metal look should be used for apps that represent a real-life device, right. So what the f*&k is wrong with these programmers at Apple, what's up with Safari, what's the real-life device equivalent of a webbrowser?

Seriously, how does this happen at a company such as Apple? It really amazes me, no matter how brilliant some of their stuuf is, how can this happen?? Does no one ever stop to think about that.

And then Java has a general look and feel, but that's a bit weird, because it's cross-platform, so I should think that the best option would be to just look like the host platform, as much as possible. Having these themes and such will only get us nowhere. Look at what some software companies do with programs. Have you ever tried Nero Showtime. It took me 1 minute to find the volume control on that piece of garbage. And I'm not even talking about all that crap software that comes bundled with scanners, printers and usb devices. My desktop looks like a toystore/electronics shop!

It just goes to show that if you give people/companies these tools, they will abuse 'em, and make more shitty looking apps, with radio buttons in dropdown menu's and silver/shiny grab/hold/release/twitch controls.

Bah!

@Rayiner Hashem
by betamike on Thu 19th May 2005 21:33 UTC

"Why does Microsoft do this? Especially when Apple seems to have no problem keeping things coherent?"

As much as I love OS X, its a bit misleading to say Apple is entirely uniform considering there is the Panther default window, brushed metal, and the new gradient windows in Tiger.

RE: betamike
by Romain Guy on Thu 19th May 2005 21:38 UTC

Well, let's say Apple is more uniform ;)

RE: wxWidgets?
by theorz on Thu 19th May 2005 21:39 UTC

I personally can't stand wxWidgets apps. The may use some native widgets, but that doesn't make them behave anything like native apps. They always seem to have the wrong widget spacing, the wrong widget placement, and the wrong icons on the buttons. They also do not make very good use of the platform's features. They look enough like a native app to get your hopes up, but when you try to use it you realize that it is all wrong.

Personally the way that AbiWord handles cross platform GUIis is the best. It may be more work, but you end up with something that is actually useable on all of the platforms.

Wrong so many ways.
by BlueCoder on Thu 19th May 2005 21:42 UTC

Some points:
- You should bring up the Windows L&F it's greatly improved.
Esp. compared to that produced by .Net.
- Come on 8pt. Antialiased. You must have a $2000 monitor.
This cheap piece of junk from Gateway, you couldn't tell.

The Metal and Ocean look and feel are the BEST THING OUT THERE for anyone wearing glasses, or over 35. Notice the BOLD Menu items? Notice the larger Font Sizes... Easier on the eyes and less eye strain counts.

I include a Menu item so the user can pick their look and feel. I default to Windows, users eventually switch to METAL.

Different designers have different goals, I let the user decide.

You're also not addressing the Swing advantage of Resizability. The ability to shrink an app to a small corner of the screen and still be usable. Great for utility programs.

My rule of thumb: The SMALLER and THINNER the fonts the worse the L&F experience.

RE: wxWidgets?
by Romain Guy on Thu 19th May 2005 21:44 UTC

I developped an email client with wxWidgets (well wxWindows at this time) and the API was a nightmare compared to QT and Swing. Since then I can't use them #@!

GTK native, that's ugly!
by Carlos Rodrigues on Thu 19th May 2005 22:13 UTC

I agree with this. Having a L&F totally different from the native one isn't something to worry about.

Now, what I really hate is the "native" GTK L&F, which is totally wrong in oh so many ways... (it looks like some frankenstein GTK app) And it is the default, and in some apps you can't even change it (swing.properties file is ignored), like the Java Wireless Toolkit.

RE: XUL apps inside SWT/Swing->JREX
by Anonymous on Thu 19th May 2005 22:37 UTC

This is an interesting project:

http://jrex.mozdev.org

it also has support for swt:

http://justthe.net/jrex/

What's really cool about this is that you can programmatically control the entire web browser from within java, and then you can pass events from within the browser back. So you could essentially create a very dynamic browser.

RE: After all these years
by Daniel on Thu 19th May 2005 22:52 UTC

I'm no zealot, but when it comes to the GUI I am all for consistency. For instance, the official Apple guidelines state that the metal look should be used for apps that represent a real-life device, right. So what the f*&k is wrong with these programmers at Apple, what's up with Safari, what's the real-life device equivalent of a webbrowser

You should not understand this literally. I'm not a Mac user, but this makes perfect sense to me. A Web Browser is in the same class of object as a TV set for example: A device that is used to stream content on one or more channels. The device is used to display the content, but it is not the content.
In document oriented applications, the window _is_ the document. This is true for applications like Pages or Preview.
The separation between these two kinds of applications is often very confusing (for example many people still don't get the fundamental differences between the Nautilus File Browser and a folder displayed by Nautilus). Using a different LAF for device-like windows (virtual or realistic) makes a lot of sense to me and I wouldn't mind to see the idea being adopted by free software desktops.

It also looks better. ;)

Geeky solipsism
by noisy on Thu 19th May 2005 23:00 UTC

It's funny, this article reminded me of why I got out of the IT business.

The truth is, no-one outside of a relatively small, mostly young male, cabal of geeky types gives a stuff for the 'look and feel' of applications. The vast majority of ordinary users hardly notice (in my experience) when an application looks different (iTunes on Win XP is a notable example). They want apps to be easy to install, work once installed, not break, be intuitive to use, not force them to think about too many options or alternative ways of doing things and generally just get out of their way so they can do their work/playing/communicating/whatever.

Redundant
by Eike Hein on Thu 19th May 2005 23:51 UTC

Face it: Being cross-platform simply takes honest, hard work. Abstraction layers won't keep up.

Justifications for alternative L&Fs don't really matter
by Lumbergh on Thu 19th May 2005 23:51 UTC

...because at the end of the day the fonts look like crap. There is no getting around that. Ok, maybe if you're on a CRT and have bad vision, but until 1.6 gets subpixel rendering in, Swing just doesn't cut it.

Let's face it. Swing is a huge blunder by Sun when they could've at least tried to use native fonts

look & feel
by Michelle of the Resistance on Fri 20th May 2005 00:02 UTC

having diferent toolkits on the same platform doesn't really bother me as much as ugly looking stuff like (default) swing. Take a look at trillian 3, simply beautiful http://cerulean.ord.cachenetworks.com/img/features_screenshots_3x1....

crossplatform vs native apps
by Anonymous on Fri 20th May 2005 01:03 UTC

i'm myself a full-time developer and i have a few words to say about crossplatform and native development.

the biggest problem is always consistency. as soon as you start writing an application that will work on more than one platform, you say goodbye to consistency.

its not someone's fault, its just a reality. all platforms behave differently. its really hard to keep a little bit of consistency when youre targeting more than one platform.

i know that alot of developers are concerned about this problem, mainly because 90% of all developers are scared to miss the java/.net/ect train.

i was myself in that situation a while back but i wasnt so happy about this. i found myself writing apps using languages/toolkits that i didnt even like a little bit.

finally, i jumped out of the train and i went back to my good old habits and im so happy today. i am a windows developer and i love programming directly with win32 apis. alot of people tell me that i waste some precious time doing everything by myself but i personally think that they are all wrong.

see, you can write code/debug like 20% faster in java/.net/ect but it takes you alot of time to get used to the platform. and when you start being efficient, something new appears on the market.

even worst, you have to deal with the consistency issue. at the end, you are doing something that youre not even enjoying youself.

im not saying that crossplatform development is bad and i even do some myself. but its not really interesting in my cases (for both the developers and the users).

when you adopt a platform, writing native applications is always the best way to go. you can do everything you want that way, theres no limitation.

finally, theres one more thing i got to say. not all java/.net/ect apps are bad. i think this is a misconception due to the fact that alot of non-experienced programmers use those platforms because they "seem" like way more easy to learn than others.

2 cents
by Anonymous on Fri 20th May 2005 01:45 UTC

At my workplace, the company is in the process of deploying a new client/server java app which wil replace an old visual basic app we have depended on for years. There is some grumbling about performance (it took years for the visual basic app to overcome it's performance issues), but no complaints about look and feel really. A button is a button, it's just the unfamiliarity of the new interface layout that is a concern right now.

I rather appreciate the fact that we are moving to a java client though, for the reason that we will theoritically be free to deploy on other operating systems if desired at some point in the future. We could mix client machines, even have a few Macs in there and the application should still work, even though it may look a little funky.

On my home machine though, I don't enjoy running java applications. Even though I have come across a few programs like Oxygen that would be useful to me, I can't see myself spending money to purchase a copy. I imagine how much better the software would be if someone could just write a native version for my computer. I would even give up some of the feature set just to lose some of the interface 'wonkiness' of the java version. By having the single cross-platform code-base, the developers have been able to concentrate on maximizing features, but that's not good enough for my money. I would rather have the application that targets my machines native features.

Now that the hype of Java has died down, it's easy to see that Java wasn't intended as a cure all for the world of application design. It was a toolset that solved a need for Sun. It is the application layer that let Sun create enterprise applications that could be deployed on both Solaris and Windows. They allowed others (like Apple) to license the kit so they had the opportunity to participate in that world, but Sun's interest only extended as far as those two platforms they needed for their own interest. And for that purpose Java is OK.

Re: fedetxf (on Squirrel)
by Darius on Fri 20th May 2005 02:12 UTC

I use Sswing applications every single day. JEdit, Squirrel-SQL.

You've got to be kidding right? I've tried JEdit and it's ok (I like UltraEdit more), but Squirrel? That is like the biggest piece of shit known to man. It is this this one app that most of my hatred of Java comes from, because I have to use it every damn day. A few years ago at work, we were using a program called Toad that, when compared to Squirrel .... well, let's just say there is no comparison. However, you can't keep using a $500+ app for free and hope to stay legal, so out when Toad and we had the god-awful Squirrel forced upon us. Many of us cried for months and I even begged my boss to let me buy some other app just so I wouldn't have to use it, but no dice. This program sucks in so many ways, I could write a 500-page novel called 'Why Squirrel Sucks.'

v Here's The Bottom Line, Morons
by Richard Steven Hack on Fri 20th May 2005 02:45 UTC
re: L&F
by Anonymous on Fri 20th May 2005 02:50 UTC

The Windows L&F for Java is horrible. XUL? Just as bad. It's not just how your widgets look, it's also how they work.

Right click on a textbox in explorer. Right click a text box in WMP. Right click a textbox in Office. Right click a text VS.NET. They look slightly different, but they all work the same. Now right click a XUL textbox. Java textbox? All out of place. Completely incosistent context menus. File Browser control? Same problem.

This kind of disparity is very evident when working with unicode and multiple languages. Native widgets that perform the same kind of task work the same way, have the same options. But Java? XUL? Oh no.

Microsoft Apps
by konkat on Fri 20th May 2005 04:24 UTC

Office XP looks the same on my computer as Office 2000 does. I don't use any XP themes so that could be it. Messenger and Windows Media Player aren't too far a departure from other Windows apps either. So I'm not too sure about the arguement of MS apps having a large variance in their GUI appearance.

I never skin my apps except the ones that come with a crazy default skin I usually change them to a "Windows Classic" skin.

The last Java app I ran was Azureus and it was a resource pig. The Oracle DB and IBM DB2 database software are done in Java and I'm not too fond of those eiher. Funny thing is that for running Java I get better performance using the Microsoft VM instead of the Sun VM. In my experience .Net apps take longer to load than non-.Net apps but run fine once loaded.

TOAD
by fedetxf on Fri 20th May 2005 04:27 UTC

Use toad with anything but Oracle... Or multiple DBs.

haha
by jm on Fri 20th May 2005 04:30 UTC

what cross platform issues? I don't recompile java code for windows, linux, solaris to make them work in those platforms, i just execute the jar file, so whats the problem? The gui still behaves the same way.

I agree with Darius: Swing is slow.
by renoX on Fri 20th May 2005 05:18 UTC

Some says that it is because apps are badly programmed, my question is: how is-it possible than Sun itself is not able to make fast Java client app then?

In Solaris9, they rewrote some applications used for managing the OS in Java, and the result was sloooowww.

Now this has benefits: tired of seeing the 'rolling disk' each time I clicked, I learned the command-line administrative commands to avoid those awful Java apps.

RE: I agree with Darius: Swing is slow.
by Romain Guy on Fri 20th May 2005 05:40 UTC

Hey Sun is a large company, you can't expect all the employees to know well all the technologies of the firm. I'm pretty sure all Microsoft people are not equally good at DirectX programming ;)

Swing GTK look'n'feel
by Chris Lord on Fri 20th May 2005 05:47 UTC

Java is the language of choice at my university, so I have fair experience with using Swing. All three (major) platforms are available to develop on, and I take the trouble to see that things work nicely on all three.

I'm a big believer in consistent and nice looking interfaces: The nicer your GUI looks, the more productive you are, is my belief - So everything using native widgets is a big thing for me. It goes as far in that I refuse to have GTK1 or Qt installed on my own PC, as I don't want there to be the potential of me seeing applications using different widgets. Sometimes this limits me in that I can't use certain applications, but now, as all my applications look the same and follow the same design philosophies, I can get a lot more work done than when using a 'hybrid' interface.

Getting to the point, the Swing GTK look and feel is a crime. How it could even be suggested that it's a 'native' look and feel is beyond me. I don't understand why the chosen method of creating a native look'n'feel is to re-implement the widgets in the style of that platform, instead of just using the native rendering?

Disregarding how poorly it actually simulates GTK rendering, and how few theme engines it can simulate, it is also *slow*. Using the GTK look and feel disables optimised rendering - Scrolling in a JScrollPane, for example, causes the update rectangle to be the size of the visible area rather than the size of the newly exposed area. There is a lot of work to be done on this, and I hope in the future that the native look and feel's (which are passable on Windows and Mac, imo), actually use native rendering.

On a slightly different note, has anyone tried SwingWT? http://swingwt.sourceforge.net/ - Perhaps an interim solution.

GuI sex appeal
by Anonymous on Fri 20th May 2005 05:58 UTC

It's alla bout sex appeal (which Java lacks)

I don't really get this exclusive focus on 'LAF'
by karl on Fri 20th May 2005 09:23 UTC

I value a consistent desktop. I value having a degree of consistency between the apps that I regularly use. To a large extent I achieve this by using software primarily written with one toolkit and carefully choosing themes. I occassionally do use programs written in another toolkit-and of course these application don't look like the rest of the applications on my desktop. But this in and of itself is not a problem.

The fact that an application uses a different widget set/toolkit does not, by itself, negatively impact usage. But each and every application provides an interface between itself and the 'system' underlying the desktop. These interfaces are: file open/save dialogues and print dialogues. If I was given the choice between having a desktop with apps where each app had it's own toolkit/widget set but each app made use of the same file save/open and print dialogues vs. a desktop full of apps where each app had the same 'LAF' but differing file save/open and print dialogues, I would always choose the former.

Where I work I have 300 users. I have never noticed them having problems with apps which look different from other apps. But there is no end to the difficulties which popup when users are confronted with 5 different interface dialogues. The spacing of icons, the justification of application text, the coloring of the widgets-all of these things pale in contrast to the difficulties surrounding differing interfaces to the 'system'.


Where I work we used to provide both xpdf and the older adobe acrobat reader 5.0. This in the context of gnome-2.8 desktop with mozilla and openoffice. As such my users were forced to come to terms with 5 different sets of interfaces and this was the source of so many errors and so much frustation on the part of my users. The actual applications themselves were not that problematic-the widgets sets/toolkits in use by these application were each quite different but the the users had little difficulty adjusting to differing fonts, colors, icons etc. The problems were all caused by these differing interfaces.

With the older adobe acrobat one was confronted with a file open/save dialogue which a) routinely opened up in the /tmp directory misleading users to store their documents in /tmp and users searching in vain for their pdf's in the /tmp directory b) routinely selected the mozilla cache file name for the pdf which was some ungodly long string of meaningless charachters. The result was mayhem.

Occassionally I would take a look inside /tmp and find that people had been storing their documents there not understanding that each time the server booted the contents of /tmp were being deleted. Then there was the issue of the print dialogue. This issue was compounded by the fact that not only do openoffice, mozilla, acroread and xpdf but also too many of the gnome-2.8 apps each have wildly different print dialogues with apparently contradictory and contra-intuitive options.

Moreover none of the applications actually did any printing-all they did was hand over the postscript output that they produced to cups which actually does the printing. And of course with the exception of those apps which made use of libgnomeprint none of these apps new that there was exactly one printer available for the users which only printed to A4 and only printed single-sided. But invariably applications would end up fighting over the paper size. My users would download random word documents from the web-most written in english by americans who use letter size paper. Invariably Openoffice would try to send a letter sized document to our Hewlett-Packard Laserjet 4 plus. This invariabley caused the printer to crash-because there was no letter sized paper.

All of these applications came with print dialogues which listed a plethora of options which were simply meaningless. We only have one printer. We only support one paper size. That printer doesn't do color and doesnt do duplex printing.

Ideally each application would use the same print dialogue and this print dialogue would query cups to find out a) how many printers are connected b) which options are supported by which printers and c) when a printer was selected only those options which were actually supported by the printer were available.

These issues are also at play when each multimedia application has to be configured differently to work with the same physival devices (alsa/dvd/cd etc.)

Consistency between applications and the system with which the applications interface is of paramount importance. Nothing else is as confusing to new users who don't understand the complexities of the system-and these interfaces should exist primarily to hide this complexity. How often do inexperienced users save files and then spend hours looking in vain for what they just saved ? And this is a real problem on all platforms I have worked with and is just incredibly discouraging. Each of my users has a Desktop directory and I worked hard to get programs to default sto saving to that directory so that when someone downloaded a file of saved a newly created document that they might actually have a chance of finding it.

I love GUI aethetics as much as the next person. I really like it when all of my appliations have similiar menu structure, the same button order in dialogues and other such issues. But this stuff pales in terms of relevancy and importance in contrast to the issues involved in the interfaces with the system.

How does this stuff relate to Java and/or the specifics of Javas' LAF's-simple, Java applications are all guilty of the same fundamental mistake of presenting my users with interfaces which compound their difficulties in performing the mundane taks of open and saving files and printing. I really don't care if they look nice or have nice eye candy or even if they are dogged slow -I worry will my users be able to carry out their mundane tasks without getting lost, sidetracked or defeated by interface inconcsitency.

Performance
by Anonymous on Fri 20th May 2005 09:23 UTC

There's always someone trying to defend Swing by saying that it is really fast, it's just that everyone is programming it wrong.

Now it's time to show a link that describes this secret way to program acceptable Swing apps. You may want to email James Gosling too.

Using native widgets is hard!
by Andy Roberts on Fri 20th May 2005 09:33 UTC

Java did go down the route of native widgets, which can be seen in the AWT package. The problem was that it only came with basic widgets and not many devs enjoyed using them.

SWT is Java toolkit that uses native widgets. Except it does and it doesn't. In their quest to provide a consistant API across all supported platforms, they came into difficulties, and in effect, they have to play to the lowest common denominator. Say platorm A, B, C and D allows feature X, but platform E doesn't, then feature X has to go, at the disadvantage of the other platforms. There are even widgets that SWT emulates for certain platforms as they simply don't exist. As a programmer, if you are aiming to support multi-platforms this way, you need to become aware of the little intricacies of them, e.g., [from the SWT page]:

"For example, programatically giving focus to a "radio" button on Windows will cause it to be selected. Period. Since it would be exceedingly difficult (and is counter to the Windows user-interface look and feel) to prevent this behavior, the Windows version of SWT generates events as if the user had "clicked" the radio button when it is given focus. This means that well-written applications can ignore the differences, but also means that smart developers will test SWT applications on every platform which they are to be delivered on."

The Swing approach was designed as an emulation layer, if you like. This means they can provide each platform the same set of rich widgets, and they can potentially program them to look and act native. An advantage (to some perhaps) is that Swing provides a consistant look across all platforms - something the native toolkits can't achieve. The advantage for me as a developer is that I can deploy only one version of my app for all platforms, whereas those using native widgets have to release separate ones for each of the target platforms.

Arrrg...Java is NOT slow!
by deepspace on Fri 20th May 2005 10:12 UTC

Well, I think most of what should be said about widgets, was already said. But there is one thing that keeps anoing me: people keep craping about java beeing slow. Well people, java is not slow. True, the GUI can often be slow(ish). Who cares if you can push buttons faster than you can think? But java itself is not at all slow. Sure, you need some more memory to get the most out of it, but who cares, it's cheap as hell! In a lot of core OO tasks, java is even faster that C++!

In the end, it's not about subjective speed, but about efficiency.

Consistency across platforms
by Anonymous on Fri 20th May 2005 10:51 UTC

It would be much more simple for the Java developers to adopt Windows as the default platform for the look and feel of the widgets.

Under Windows, SWING should use the native ones, and under Linux/Mac/ect, it would try to emulate them.

There's no reason to not do it that way. The Windows native widgets look and feel is perfect. Just use it as a basis. And after all, most people are still using Windows. And uh, there's no reason to take something else as a basis... GTK? QT? All these 3rd party toolkits tried to ripoff Windows look and feel at some point but they almost always failed. Just adopt the original.

Oh I forgot Mac users...well they arent so many ;)

Re: Arrrg... Java is NOT slow!
by Archangel on Fri 20th May 2005 11:08 UTC

Well people, java is not slow.
Yes... it is!
Before you can run a Java app, you have to fire up the virtual machine. Then it's got to compile the thing as it goes. That means Java is, and will remain, slower than properly compiled languages.
And it's further crippled by it's constant bounds checking etc - which can be a lifesaver sometimes, true, but often is painful. Read John Carmack's comments on programming Java if you don't believe me.

In a lot of core OO tasks, java is even faster that C++!
Care to name any of these mysterious core tasks, or provide links?

In the end, it's not about subjective speed, but about efficiency.
Um yes? One thing Java is not is efficient.
C is efficient. You have to worry about array bounds and pointers and that sort of thing, but it is efficient because it doesn't do things it doesn't have to.
Whereas Java tries to do things for you, so it'll check if you're out of bounds of an array even if you know damn well you're never going to be.
And then there's the VM thing - Java is compiling as it goes, which imposes more overhead than if it's all done ahead of time.
So no, it is NOT efficient.

C is beyond Dead...
by BlueStreak on Fri 20th May 2005 11:14 UTC

C is efficient, only because you don't:
- memory leaks
- no unicode, you're still using ASCII
- no bounds checking
- no string library, char[] still used by many programmers.

C is faster, only because it doesn't do ANYTHING a modern language should be doing.

Learn D.

MS-Windows and its LAF
by Tim on Fri 20th May 2005 11:21 UTC

The LAF under WinXP:

WinXP-programs have the WinXP theme (Calc, Notepad, ...)
The Command Shell have its own frame-look.
.net-programs have a Win2k LAF.
Win3.1 programs looks also different.

WinXP is itself inconsistent. So there is no need, to be GUI-compatible with it.
And on the Linux/Unix side, there existing no "Standard-LAF". There existing Qt, GTk+, Motif, Athene, FLTK, ...

GTK look and feel compared to SWT
by chemicalscum on Fri 20th May 2005 11:41 UTC

I would just like too aggree with all the posters that have said the Java "GTK" LAF stinks. The fonts are disgusting the widgets all look wrong and work wrong. Just fire up Eclipse or RSSOwl on a Linux desktop they appear and act really natively and the fonts are RIGHT and look great, you can see how much better SWT is.

I prefer any day a Java app that just gives you a metal LAF with no choice like Jchempaint or Jmol to an app that gives you the "GTK" LAF without any choice like Freemind excellent app though it may be.

RE: Archangel
by deepspace on Fri 20th May 2005 12:16 UTC

Yes... it is!
Before you can run a Java app, you have to fire up the virtual machine.


Who cares about startup? If I run a programme all day long, I can wait that extra second.

Then it's got to compile the thing as it goes. That means Java is, and will remain, slower than properly compiled languages.

True, but ones it is compiled, it will run at full speed.

And it's further crippled by it's constant bounds checking etc - which can be a lifesaver sometimes, true, but often is painful. Read John Carmack's comments on programming Java if you don't believe me.

If you want very fast buffers, use java.nio.* stuff. You'll always find something to wine about. Make it look like a bad thing... That's easy: Grabage collector, balbalbalbal..

Care to name any of these mysterious core tasks, or provide links?

Sure, this one for instance: http://www.kano.net/javabench/data . There are more of those out there. Also ones that say the opposite. Java is especially fast at handling object, and does the trick better dan C++ in most cases. Of course there are othere fronts, where java is simply not as fast, but java is gaining on all fronts with every new release.

Um yes? One thing Java is not is efficient.
C is efficient. You have to worry about array bounds and pointers and that sort of thing, but it is efficient because it doesn't do things it doesn't have to. Whereas Java tries to do things for you, so it'll check if you're out of bounds of an array even if you know damn well you're never going to be.


That's true. C doesn't do anything... What's efficient about that?

And then there's the VM thing - Java is compiling as it goes, which imposes more overhead than if it's all done ahead of time.

True, but that actually makes it more efficient. I know, it's confusing, but "efficency" is not all about speed:

- Java software runs on multiple platform without having to recompile or port one single line of code.
- There is lot's of stuff a programmer doesn't have to worry about. Call me laisy, but you can consentrate on the important stuff now.
- There are coultless free, very well documented api's available for all kinds of fun stuff. So often no need to so something youself. Sure there are also lots of C and C++ api's out there. But good documentation is often missing.
- (I find that) programming in java is much easyer, faster, and pleasent that in for instance C++ or C. Of course, you are free to disagree.

So no, it is NOT efficient.

So, it all depends on what you call efficient...

So, no java is not slow at all. Also, it might not be the fasted language ( I never said that), but it was neaver meant to be.

RE: Performance
by deepspace on Fri 20th May 2005 12:19 UTC

Now it's time to show a link that describes this secret way to program acceptable Swing apps. You may want to email James Gosling too.

Ever tried Jedit: www.jedit.org ...

Too Windows centric...
by Victor on Fri 20th May 2005 12:41 UTC

Swing may look ugly when compared with native widgets, but it manages to mantain a consistent look through every platform that Java supports. That's it's main advantage, portability.

If you don't like it, use SWT.

Also, I may point out that Swing is not slow... The problem is that's very easy to shoot yourself in the foot with Swing, but can happen with any toolkit, even those using native code. Well written Swing code can be as fast as a native application, if not faster.

Re: Swing is not slow ...
by Darius on Fri 20th May 2005 13:02 UTC

Also, I may point out that Swing is not slow... The problem is that's very easy to shoot yourself in the foot with Swing, but can happen with any toolkit, even those using native code. Well written Swing code can be as fast as a native application, if not faster.

Maybe you're right, but when you have 999 out of 1,000 developers shooting themselves in the foot, something is definitey wrong. The fastest swing app I've ever seen is Jedit, and even its speed is on the slow side compared with other alternatives that run natively.

@archangel
by mattb on Fri 20th May 2005 13:08 UTC

>Well people, java is not slow.
Yes... it is!
Before you can run a Java app, you have to fire up the virtual machine. Then it's got to compile the thing as it goes. That means Java is, and will remain, slower than properly compiled languages.
And it's further crippled by it's constant bounds checking etc - which can be a lifesaver sometimes, true, but often is painful. Read John Carmack's comments on programming Java if you don't believe me.


wow. first of all, it will only "compile as it goes" the first time. secondly, the virtual machine adds a second or so to the boot time, which while it is something, isnt much. java isnt the greatest platform for game development, the john carmack article your referring to was about five pages of the obvious. there are a few disadvantages to the way java does things, but the advantages VASTLY outweigh the disadvantages for the majority of application types (games not being one of them)

In a lot of core OO tasks, java is even faster that C++!
Care to name any of these mysterious core tasks, or provide links?


dude, its not too hard to find definitive proof that anything is faster then anything else. most language benchmarks do nothing but proove the efficiency of data structure x in language n. but the VM languages have surpassed compiled languages in terms of speed at this point. wont be the case for long, the next generation of compilers will pull native code ahead again. that doesnt change the fact that for the vast majority of applications, VM languages are so close to native its not worth mentioning.


In the end, it's not about subjective speed, but about efficiency.
Um yes? One thing Java is not is efficient.
C is efficient. You have to worry about array bounds and pointers and that sort of thing, but it is efficient because it doesn't do things it doesn't have to.
Whereas Java tries to do things for you, so it'll check if you're out of bounds of an array even if you know damn well you're never going to be.
And then there's the VM thing - Java is compiling as it goes, which imposes more overhead than if it's all done ahead of time.
So no, it is NOT efficient.


the only possible way you could say C is more efficient is if you manage to find someone that writes perfect C code. but since we arnt taking development times into account, you could say that C is a bloated piece of crap, and ASM is way more efficient.

java doesnt compile as it goes, that is what the java compiler is for (javac). if you want to, you can even compile to native code with gcj (redhat does this with the java bits of oo.o). stuff like bounds checking or garbage collection is definately overhead, but it also makes developing remarkably painless (when compared to C). you can get a hell of alot more done, in exponentially less time, with fewer bugs in java.

Java GUI Problems
by Bryan Feeney on Fri 20th May 2005 13:34 UTC

The problem with the Java GUI falls into two areas

1) The Metal look and feel has never looked good, not even when it was first released. It's always made a bad impression. With its dark tones, poorly rendered non-standard fonts and unattractive widget sets, it makes an instant bad impression. Ocean has fixed the colour issue, but none of the others.

2) A lot of Swing developers go so far with the MVC paradigm, but fail to make the final jump: that is, to run the business logic in a separate thread, so the GUI can remain responsive. The reason for this is bad documentation from Sun. The Swing developers created the "SwingWorker" class many years ago, but it's never been included in Swing, nor has it been mentioned in official Sun documentation, which for its part does not highlight the need for multi-threaded GUIs enough.

Consequently, a lot of Swing apps freeze at every button press for no good reason.


There are two easy fixes to this
1) Use the system's default look and feel by default. All applications have minor differences (especially on Windows), so users won't mind the minor differences introduced by Java, but the vast majority of users do not like Metal.

2) With the default look and feels, use the standard system fonts.

3) Enable, as a priority, anti-aliased fonts; however allow this behaviour to be customised (e.g. to exclude the 9-13pt range)

4) Add to the official Swing classes a helper class to officially encourage developers to multi-thread their GUIs. A really good starting point is the FoxTrot API: http://foxtrot.sourceforge.net/


What's really a crying shame is that none of this is particularly hard, Sun has simple been (characteristically) shooting itself in the foot. LAFs like Alloy and applications like DBVisualizer (http://www.dbvis.com) show that it's possible to create powerful, responsive desktop applications with Java. It's just a matter of focus and education.

You know
by Anonymous on Fri 20th May 2005 14:26 UTC

Every day I see people comment on how much faster the Java programs they use are, how much better they look, and how when given the choice they'd choose a program written in Java to one that wasn't. The sheer obviousness of Java's superiority as a development platform for desktop applications cannot be denied. Not only that, but programs written in Java are even faster that statically-compiled software written in other languages, and who cares about heap usage when RAM is free? Who cares about startup time, when everyone knows that if you just leave all of your programs running all of the time that you can eliminate the latency entirely (and after all, RAM is free so why would you want to close all of those programs anyway?). Who needs sub-pixel anti-aliased fonts anyway? I mean who spends all of their time in front of a computer looking at text anyway?

@Java GUI Problems
by Andy Roberts on Fri 20th May 2005 14:32 UTC

Bryan, you have good points, although I'd like to address them too:

1) The Metal look and feel has never looked good, not even when it was first released. It's always made a bad impression. With its dark tones, poorly rendered non-standard fonts and unattractive widget sets, it makes an instant bad impression. Ocean has fixed the colour issue, but none of the others.

The non-standard fonts were obviously bundled to give the option of a standard multi-platform set, so that you can guarantee that interfaces will have the consistant looks and layout across platforms. Different fonts may alter layout. You can't rely on certain fonts existing on all platforms (this is why web sites often suffer with layout issues). The other reason is because those fonts are pretty rich in lots of languages other than English. Because Java relies on Unicode, it had to make sure that its fonts could render the characters. Admittedly, the bundled fonts don't have all the glyphs, but they're better than many. This may or may not be important for your app.

I'm confident that the looks will continue to improve in house. Of course the Swing team has a lot of other areas to work on and limited resources. Fortunately, there are a few decent 3rd party LAFS that'll tidy up your interface nicely ;)

2) A lot of Swing developers go so far with the MVC paradigm, but fail to make the final jump: that is, to run the business logic in a separate thread, so the GUI can remain responsive. The reason for this is bad documentation from Sun. The Swing developers created the "SwingWorker" class many years ago, but it's never been included in Swing, nor has it been mentioned in official Sun documentation, which for its part does not highlight the need for multi-threaded GUIs enough.

Consequently, a lot of Swing apps freeze at every button press for no good reason.


You're right. SwingWorker appeared in 1998 IIRC. It's being included in the next version of Java (1.6).

plaf is useful
by Herbert Meyer on Fri 20th May 2005 14:32 UTC

Aside from the opinions that Metal or other L&F are ugly, the pluggable L&F allowed me to subclass swing components to do useful things - like a tabbed page with a different icon for a "selected" page, without disabling the other pages. So I am in favor of it. However, the Sun code is rather murky, and it took a couple of weeks of hacking.

Re: RE: It's not really the ugliness ...
by David on Fri 20th May 2005 14:36 UTC

The fact is developing a Swing application does not give you good performances for free. You have to know how Swing works.

That's not the programmer's problem. They can get better peformance from other tookits for free without any extended effort. Swing is slow before you even start.

Myrd: Blaming Java application for not looking perfectly native on MacOS X is not relevant I think. First, remember that Java needs to cope with multiple platforms and it cannot, at least easily, offer a perfect look and feel on each of them and still bring you the portability you would expect.

Qt has managed it. It's never going to be perfectly native, but it's good enough in terms of integration and as long as it looks good it's fine. SWT and Eclipse don't look exact, but they look good enough and integrate enough in terms of colour.

Java applications do not run slowly, they APPEAR to run slowly when they have a GUI, because of some misunderstanding of the Swing API (which, I reckon, is sometimes hard to use). Seriously this is due to how the toolkit is used.

Again, not a programmer's issue. This doesn't happen with other toolkits.

My 20 millibucks...
by Francois Stiglitz on Fri 20th May 2005 14:48 UTC

For comments about performance, I feel that's a canard. Swing (and Java in general) might require a different way of thinking about the implementation, but making a responsive GUI is really trivial if you care to. That many developers don't bother is really their own concern.

Second, the fact that you have a PLF means that you're abandoning the idea of a consistent L&F. Without PLF, all Java apps would have the same L&F, but now the L&F is variable, so it's not even consistent on the same platform.

At my job, we don't fiddle with the L&F and always use the default. That way the L&F is consistent -- all in-house apps L&F feel the same on the same platform.

As far as aesthetics, my impression is that poor layout and the non-aliasing and use of non-native fonts are the principle culprits. Otherwise, the actual presentation of widgets and their interaction is really a matter of personal opinion and not my concern (unless I give everyone a facility to tune not only the L, but also the F, I don't see how I can satisfy everyone; Microsoft's products a good example of popular but ugly and inconsistent UI presentations, yet they are still usable).

What kills a UI more that anything is not consistency, people are wonderfully perceptive and adaptable things, but rather awkwardness and non-obviousness of the functionality. Everyone knows how a scrollbar works and if the arrows adjacent, at the termini, or both, folks will not have an issue. If, sunddenly, you had to grab the corner and turn the scrollbar 90-degrees to activate scrolling along the perpindicular axis -- that's not intuitive.

Personally, most of my apps use the KDE Plastik look and feel, which is simply uncluttered, and I typically favor Qt apps because they are typically better laid-out and don't waste space with huge icons everywhere (unless you explicitly set that as a preference). The reasons are not based on consistency of the L&F, but rather a consistency in the logic of the layouts used and a general attention towards functionality rather than veneer.

@anonymous
by mattb on Fri 20th May 2005 16:49 UTC

Every day I see people comment on how much faster the Java programs they use are, how much better they look, and how when given the choice they'd choose a program written in Java to one that wasn't. The sheer obviousness of Java's superiority as a development platform for desktop applications cannot be denied. Not only that, but programs written in Java are even faster that statically-compiled software written in other languages, and who cares about heap usage when RAM is free? Who cares about startup time, when everyone knows that if you just leave all of your programs running all of the time that you can eliminate the latency entirely (and after all, RAM is free so why would you want to close all of those programs anyway?). Who needs sub-pixel anti-aliased fonts anyway? I mean who spends all of their time in front of a computer looking at text anyway?


cute.

the difference between cpp and java performance wise are minimal at best. do you dispute that? an overhead of 10 megs isnt that much nowadays for a non-trivial app. do you disagree with that?

the problems come from someone who used the ms jvm to run an applet and found it slow, and thereby judged the platform as crap. or someone who used an app by someone who didnt take the time to learn swing properly (insanely common). or from the people who mindlessly believe everything microsoft tells them. java is considered a crappy platform by the general public for desktop apps, yet .net isnt, even though .net has a fraction of the api that java has, and is roughly in the same place performance wise.

its like saying windows sucks because you tried millenium awhile back, and then getting uppity when people point out that xp solves the vast majority of problems.

...
by helf on Fri 20th May 2005 22:53 UTC

java apps are fast for me on a 366 p2. takes longer for them to load than native apps but once they load they run well enough.

@deepspace
by Archangel on Fri 20th May 2005 23:11 UTC

Who cares about startup? If I run a programme all day long, I can wait that extra second.
Yeah that's fine, but you were talking about Java not being slow. I am pointing out that it in fact is slower than many other languages, notably C/C++.
Maybe you don't care about it being slower, but that doesn't mean it's not.

That's true. C doesn't do anything... What's efficient about that?
If you'd read what I posted, I explained why.
If you try to access element i of an array, Java will check if that's okay or if it's out of bounds, even if you know it's not. That is inefficient, and is slower than a language that doesn't check it.

Anyway, it seems you're now trying to change your argument to being something about development times, which fully isn't what you said in your original post. I won't argue that Java's going to be developed faster, but that is NOT what you said - you were talking about application speeds.

Looks like mattb's jumped in with some similar stuff. Best note that in fact Java DOES compile as it goes; I know what javac is and what it does, ie it only does half the job. The bytecode still has to be turned into commands that can be executed.

Usability first
by Iain on Fri 20th May 2005 23:25 UTC

I think the biggest problem here is that the author is rationalising why Java doesn't really look that bad. But it is the users who count first in these things, and they do complain that it looks ugly. Also, users need a clear, easy way to change the default Java look across platforms and install new LAFs; maybe this is a feature which already exists.

@Archangel
by Mike Reid on Fri 20th May 2005 23:50 UTC

Kia Ora bro!
This is gonna be a little off topic but since you are talking about Java's speed I thought I might add my 20 millibucks (nice phrase Francois). One of my current contracts is to write a medical application which does image processing. I'm using the Java Media Framework (which is a shame it appears to have been abandoned, but works well enough for the moment) and Java2D for display. The display was horrid until I took a tip from David M Geary's "Graphic Java: Volume II Swing" which said how to use the SwingUtilities class with other threads to stop repainting from blocking the event thread. Fixed it a treat and it runs superbly in Java 1.5. To all the people who think Swing is slow I suggest purchasing this book (just like one of Charles Petzold's book help so much with Win32). Then you will see that it is not the spoon that bends but yourself.

Anyway, part of the application needs to do convolution - which is a very expensive operation over an entire image so it is exceedingly important to get right. I hand unrolled the loops and timed it in Java. I then did the same thing with C (which is usually faster than C++) and the Java was consistently 1% faster. Now while this isn't enough to crow about it proved to me that in real-world applications Java can be both computationally fast and have a smooth GUI (even when displaying video). Note that Java is smart enough to remove bounds checking of arrays when it knows that the limits are valid (something added to Java a long time ago, I'm surprised you didn't know this already).

For comparison, I recently did some work with WinForms.NET and found it quite nice but far less powerful than Swing (ever tried to left-align column header text in a DataGrid while right aligning the column contents - well the Microsoft docs said it can't be done using what Winforms gives you). While Swing doeesn't feel quite as responsive a as native app (but still usable) neither does WinForms (and worse, WinForms has even more bugs than Swing).

Cheers,
Dr Mike

Re: Usability first
by Anonymous on Fri 20th May 2005 23:52 UTC

Don't you see? Because various Microsoft programs are completely inconsistent and have poor interfaces, that means that no one cares that Java programs are inconsistent. No one complains about it at all, except incredibly-knowledgeable technical people. And UNIX people are completely used to not knowing whether their mouse wheel will scroll a view or select its contents, so clearly there's no problem there, either. I've never seen a single person complain about the integration and interoperability of applications on either platform. Oh, and Java is suitably consistent with OS X.

Desktop users are clamoring for desktop Java!

@Andy Roberts
by Bryan Feeney on Sat 21st May 2005 00:10 UTC

I suspected internationalisation was the basis behind the custom fonts. The font availability item was one I hadn't thought of, though (and I've done a fair bit of web-design work). However it would be nice if the "system" look and feel used the system's default font.

While this may change the size of font-based widgets, surely layout managers should deal with that. After all, if the Java font-set was picked to support internationalisation, then the font-based widget widths are going to change anyway.

I'd actually be disappointed if SwingWorker was all that appeared in Java 1.6. If you look at FoxTrot, you'll see it supports a synchronous call-back model, which is far easier for the average developer to work with. There's a bit explaining how it works in this presentation: http://www.javalobby.org/eps/galbraith-swing-2

Improving the performance of Swing
by Mike Reid on Sat 21st May 2005 00:17 UTC

Dear All,
Here are a bunch of links which deal with improving the performance of Swing applications using multithreading (they will take a total of 20 minutes to read)

http://www.swingwiki.org/other:swing_threading
http://www.swingwiki.org/best:use_swingutilities
http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html

See also the Foxtrox toolkit
http://foxtrot.sourceforge.net/docs/freeze.php

Finally, David M. Geary's book "Graphic Java 2, Volume 2: Swing - 3rd Edition" (ISBN: 0130796670)
http://www.amazon.com/exec/obidos/tg/detail/-/0130796670/103-407217...

And to get a look-and-feel other people will love
http://www.jgoodies.com/

Hope this helps,
Mike

C Array Bounds Checking...
by GeWizz on Sat 21st May 2005 02:04 UTC

Sure, C array handling is faster if you don't code bounds checking.
And that's fine for a little speed benchmark you might code to compare it to Java. However, You should be Strongly Discouraged from putting that into a PRODUCTION system. You should keep in mind that your opening yourself up to Buffer Overruns.

Just one more reason C isn't popular in Business Software.

In java we can be sure our java programmers aren't forgetting array bounds checking because they Don't have to code it and they Can't turn it off.

If you like C, great, but if you won't learn Java you'd better take a look at D.

Pluggable look and feel is EVIL crap
by Angry Java Guy on Sat 21st May 2005 07:21 UTC

The Swing team came up with plaf because they couldn't put together a decent look and feel themselves. So they pushed the responsiblity to third parites. "If you don't like the metal look, you can develope your own." Yeah right. And it's not like they made it easy either.

Image, if the default Java GUI looked as good as Mac OS X. Would anyone complain because it's not native on Windows? It would be a selling point, not something to desperately hide behide a native laf. And there won't be this perpetual problem of trying to mimic the native look and feels but never quite get it.

All they get out of plaf is this hopeless mess that's the Java GUI, not to mention the bugs and performance hit that come with it.

Bounds checking
by Andy Roberts on Sat 21st May 2005 08:55 UTC

Slightly off-topic here. I had a friend who subclassed the C++ vector class to add bounds checking (because he uses them like arrays rather than using iterators). Fearing a loss in performance, he benchmarked with various tests the standard vector with his extended one. And the bounds-checking one performed quicker!

Now, he wasn't expecting that at all, and can't really believe it, but the compiler is doing something that optimises this class better.

Moral of the story here is that sometimes, something that you think of as hindering performance may not in the end ;)

Java 6
by someone on Sat 21st May 2005 15:07 UTC

Personally, I think Sun could use a better GUI team and come up with a new cross-platform LAF that actually looks good. The reason why Java 5's Ocean is not that much of an improvement from Metal is because it's basically an alternative color scheme for Metal (main for compatibility reasons). I think Sun should definitely provide an alternative crossplatform LAF and deprecate the ugly Metal/Ocean.

A lot of the swing performance problems has to do with Sun's bad decision on not including SwingWorker. Even though SwingWorker I is not the most opimal solution, at least it makes multithreading less painful to create. In my opinion, Foxtrot is the easiest API to use at the moment, but we will what they've done with SwingWorker III, which will be included in Java 6.

Java 6 will also include other performance fixes, such as instant splash screen (before the VM loads completely!), DX acceleration pipeline rewrite, grey rect fix etc. The java team is also considering the possibility of native code caching, which means you won't have to recompile the same code the next time you start up the applciation.

The GTK and Windows LAF will also be fixed up (including spacing and alignment bugs). In the mean time, you have WinLAF and Quaqua to patch up the Win and Aqua LAFs respectively.

Re: Bounds checking
by Anonymous on Sat 21st May 2005 16:31 UTC

You don't need to add bounds checking to std::vector, because it already supports bounds checking.
Secondly, when subclassing STL classes you should probably be aware of them enough to know std::vector supports bounds-checking, since for an arbitrary reason I'm going to posit that someone that doesn't know this/can't find it out might not fully appreciate the absence of late-binding and virtual destructors.

Re: Java 6
by Anonymous on Sat 21st May 2005 16:34 UTC

Instant splash screen! Woo!

RE:Java Look-and-Feel
by Uno Engborg on Sat 21st May 2005 18:03 UTC


For me, the ease of development, functionality and cross-platform support are far more important.


I agree! The problem is that java isn't really cross platform for GUI apps. It doesn't work on Linux, and probably not on FreeBSD where the java support in general is even weaker. The only platform where java is cross platform is windows.

For more info see show stopper bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4799499

This bug makes it impossible to input certain characters on non US keyboards. What characters vary from locale to locale.

Re:RE:Java Look-and-Feel @Uno Engborg
by chemicalscum on Sat 21st May 2005 20:32 UTC

"The problem is that java isn't really cross platform for GUI apps. It doesn't work on Linux"

Garbage ! I am not a Java developer but I use the same set of Java desktop applications on Linux at home and Windows at work and the performance on similar machines is almost identical. Indeed running a dual boot machine at home I was able to try the same code on identical hardware and there was no noticeable difference in performance.

A nice trick I would do with swing metal apps at work where I had a Linux vnc server was to serve an 800x600 KDE window to a Win machine set at 1024x768 resolution then display the same Java app running in the KDE window also running on the Win machine and demonstrate pixel for pixel identity visible in overlaping windows - cool!

Re:RE:Java Look-and-Feel @Uno Engborg
by chemicalscum on Sat 21st May 2005 21:03 UTC

Sorry I hadn't read your link. I have the average anglo-saxon blind spot to other languages' character sets.

@Uno Engborg
by jm on Sun 22nd May 2005 07:05 UTC

doesn't work on linux? I do scientific swing applications, and we test software on windows, solaris and linux (red hat). I compile code from my xp laptop and just ssh the jars to the different machines. And all three OS executes the code perfectly without the need to recompile for that specific platform, although we only use english keyboards. But this is a good example of write once run anywhere.

Re: jm
by Anonymous on Sun 22nd May 2005 08:05 UTC

Wow, you're the second person to both acknowledge that he's correct and claim that he's incorrect. I'm really quite impressed. Shall we go for three? Anyone else have the burning need for Java to be the greatest invention in the history of mankind?

@jm
by Uno Engborg on Sun 22nd May 2005 08:21 UTC


doesn't work on linux? I do scientific swing applications, and we test software on windows, solaris and linux (red hat). I compile code from my xp laptop and just ssh the jars to the different machines. And all three OS executes the code perfectly without the need to recompile for that specific platform, although we only use english keyboards. But this is a good example of write once run anywhere.


You have an example of cross platform application, not a good example. If it had been a good example, you would have been able to have full use of your keyboard anywhare you in the world. Read the link in my previous post.

Of course if your program have no keyboard input you would be in the clear.

It seams to be that english speaking people feels that this is a minor problem as their keyboard probably works, but it is a problem to them too. It means that they don't really know what market their program will have. E.g. having a Swedish keyboard I would never buy a java application where I would risk entering URLs as some of them are untypable.

This is an incredibly stupid bug not to fix. Many people in Europe feel that not being able to use their language is a peronal insult. In France even translated Fortran into French.

Until this and other similar internationalization bugs (there are a lot of them) gets fixed I would consider java a serverside only language.


Miscellany comments
by Slobodan Celenkovic on Sun 22nd May 2005 08:35 UTC

RE: C/C++ vs Java

Yes, Java platform performs more work than C/C++, so it does in fact involve more overhead. For instance, array index checking is strictly enforced. This has been a rich surce of bugs and security problems for C/C++ applications forcing programmers to add bunch of checks. Therefore, the discussion is pointless as index checking has to be done, by VM or specific programmed instructions. Java apps may have few extra checks that may not be absolutely required, but in the end it makes a little difference.

Certainly Java platform performs much more work to initialize than a C/C++ app. Java apps almost always need more time to start. Yes, it is a problem and is being addressed by Sun.

In short, Java has added a number of features to improve security, reduce bugs and help programmers while sacrificing (wasting) a certain amount of resources (memory, CPU). This is simply evolution of programming languages, from assemblers, to C/C++ and now to Java/C#
The current computers are certainly powerful enough to handle Java/C# overhead.

RE: Swing app design

The fact that most Swing apps don't handle thread selection properly is certainly an issue that affects everyone, not just programmers. The poor impression left on users has tainted Java desktop apps for years, making it more difficult for new Java apps.
The key to solving this problem is a combination of <a href="http://www.jroller.com/page/slobodan/20050513#swing_scalability">... and addition of helper classes (SwingWorker) into Java as well as frameworks (FoxTrot, Spin). It will take time, but eventually Swing programmers will get it right.

RE: L&F

As mentioned before, there is a lot of overreaction about L&F, fonts, etc. Most users don't really mind the present L&F. In fact, what is more important is usability, things that may have nothing to do with the appearance of fonts. For instance, the initial location of File Open dialogs is often wrong, in some irrelevant directory forcing users to click many times to get back to the proper directory. And many other little annoyancies cause far more frustration than missing/extra pixels in Windows L&F.

Of course, some improvements are needed and should happen. Still we must consider what the aactual end users want/need and not what we think is important.

The important thing is that we have the choice. Java platform is based on the platform hiding principle, hence the single common L&F. There are many benefits from this choice. If you must use the native L&F there are APIs to detect platform type and there are native L&Fs to use. It really is not much effort/code! Clearly, Sun cannot satisfy everyone all the time.


Swing / Flash
by Patrick Schriner on Sun 22nd May 2005 11:02 UTC

I dislike most Swing UIs for the same reason I dislike Flash as Content / Navigation on the web. Quite a lot of programmers think they know best about UI design and quite frankly, the result is horrid.

Flash has got the same issues on the internet - Search engines donīt like it, scrolling by mouse wheel is a thing, etc.

I think itīs totally fair to say SWT primary focus is Windows. They are targetting VS, and that runs on Windows only. They did indeed take a lower common denominator approach, but a different one from AWT: They emulate widgets they need but their platform doesnīt provide. Thatīs of course quite a maintainance nightmare, and thatīs the reason some things are not fixed / changed in SWT (as the Windows widgets (primary platform) canīt behave in another way), but it is quite a pragmatic step.

Netbeans 4.1 is quite fast using a SWING UI (as is IDEA), but I still hate a file opener dialog that is clipped at the bottom (in the same line: I dislike any deviations from platform UI that are not of high value (e.g. different file dialog in MS Office)).

SWING is a really nice API that makes MVC - based applications easy to do. On the other hand I think it makes UI customization far too easy. Why invite every developer to have a different tree, different icon bar etc??

@Anonymous
by jm on Sun 22nd May 2005 14:54 UTC

well he is correct on the non-us keyboard issue, its a well known bug and hopefully will be fixed in 1.6, disagreeing with him on that part is stupid.

But to some extent java can compile code that can be executed in different platforms without the need to recompile.