There are very good reasons why this combination hasn't been particularly popular. C++ with a few libs like MFC or WTL continues to rule on Windows being slowly replaced by .NET stack, Obj-C keeps rocking on OSX and C/C++ with Qt/GTK doing their job on Linux/BSD. Why is that? I suspect because of 3 reasons: very weak JVM penetration on the desktop, JVM is too heavy for most applications and because JDK-based UI feels foreign on every platform.
Developing a desktop application on JDK means that your users will have to deal with 100MB+ downloads followed by quirky installation process that rewards the with less then stellar UI experience at the end, especially the slow startup time.
Startup time is more important than most developers think: majority of desktop apps absolutely need it: imagine 5-second delay every time you wanted to launch Apple's "Quick View" to glance at a file, or imagine 5+ JVM-based apps load&initialize after reboot. Most desktop software I worked on was small-to-medium size and we just couldn't afford to add those 5+ seconds on JVM initialization. JVM I guess will work OK for projects like Ecilpse or a big Office suite or something like Photoshop. Microsoft understands this very well, this is why C#/.NET is so carefully optimized around loading time and comes with precompilation tools that essentially turn your C# code (including .NET itself) into native Win32 modules.
One project I want to do for myself is a usable Del.icio.us client for OSX. I can't see how I can use JVM-based tools for that... I want instant start-up by a hotkey when I need to search for links or add one. Moreover, I want users to be able to download and try it under 20 seconds.
The only JDKUI apps I'v ever used were development tools for Java itself plus numerous crap for the enterprise. And, of course, every once in a while I get "Java. Please wait..." splash screen on a new cellphone, followed by a prompt "Cancel/Go Back" keypress: that pretty much sums up my JVM-based UI experience. Which is sad: Clojure is going to be locked up on the server just like Java has been for years.
Java has always had challenges ont he desktop, but I don't agree with a lot of your assertions.
> ..users will have to deal with 100MB+ downloads
I've never seen a JRE download that big. At most it's around 25Mb, although in practice you can get it a lot smaller than that (sub 10Mb for the minimal install afaik).
> ..One project I want to do for myself is a usable Del.icio.us client for OSX.
Java is already shipped on every copy of OS X - so zero download in that case. The startup time seems just fine. I'm using Apache JMeter right now and the startup time seems about the same as any other app I use.
Veryyy slowly... but I think its the same issue with it.
>100MB+ downloads
When is that ever the case? Certainly not the VM or even a "odd" toolkit like SWT.
>Startup time is more important than most developers think
Agree. Any app its more important them people think.
The bottom line is if you want maximum responsiveness, minimum size, you have to eliminate layers, not add them. And Obj-C + cocoa is a fairly productive environment.
however, it isn't necessarily small or fast to startup - have you downloaded or tried to create a cocoa app lately? 30 + meg is common for the most basic things. And they are anything but instant to start up. Sounds like you want quicksilver like performance - which means pre loading - or just use quicksilver (probably already is a del.icio.us thing in existence).
Well the only ones I know are as a user - adium, various dinky little utils like twitteriffic. Downloads seem to be min 30 meg, and memory usage around twice that, minimum. I just have never experienced cocoa apps to be any common definition of "lightweight". Maybe they are poorly written apps, but they work fine, and I only use the common stuff.
"quicken-like" - well that means nothing unless it replicates the girth of horrible accounting rules that quicken has to adhere to - if its a "quicken like" accounting app, I guess it would not, so I don't think that really is a useful measure.
You're arguing that people should use Qt or GTK on *nix. The article is about using Qt with Clojure. Qt also looks and works well enough on Windows - at least, I never hear any complaints about Opera related to its UI toolkit.
The startup time can be a problem, and Clojure offering only JIT compilation doesn't improve things.
I imagine something akin to Monkeybars could be developed for Clojure whereby developers can exploit the fluidity of the language while getting the benefit of Swing development tools.
They both suck from a users point of view. Who cares what developers think - if you want your users to have the best experience, then as a developer you have to not think of your own convenience.
Which port is better? A Qt/Gtk/Swing port or no port at all?
Every time I use Inkscape on Windows I'm happy about the Gtk toolkit, because there was no chance at all of the software being ported to Win32 otherwise.
Markup only solves the shallow part of the problem anyway. Sure it can help communicate with graphic designers, but it doesn't do everything.
Lots of OSX apps (the ones which most people think of as being friendly, usable and pretty) are done mostly programmatically, even with the interface builder stuff available...
It can be a good thing the way HTML-CSS-Javascript separation can be a good thing. In the case of Clojure, it actually is possible to write the layout code in a declarative style and keep the handlers completely separate, but for most of the popular languages, it's easier to just use Qt Designer, Glade or similar to generate an XML layout and write the handlers in your language of choice. Compared to the old approach of GUI designers generating a pile of C/C++ code, which you then modify, the XML blob is actually much nicer.
Also, most of the XML-presentation libraries offer multiple language bindings, so there's less of a requirement for your language to provide its own GUI toolkit, and it's easier to convert your app from one language to another (e.g. injecting Python into a legacy C app) without losing any of the details from the original interface.
There are very good reasons why this combination hasn't been particularly popular. C++ with a few libs like MFC or WTL continues to rule on Windows being slowly replaced by .NET stack, Obj-C keeps rocking on OSX and C/C++ with Qt/GTK doing their job on Linux/BSD. Why is that? I suspect because of 3 reasons: very weak JVM penetration on the desktop, JVM is too heavy for most applications and because JDK-based UI feels foreign on every platform.
Developing a desktop application on JDK means that your users will have to deal with 100MB+ downloads followed by quirky installation process that rewards the with less then stellar UI experience at the end, especially the slow startup time.
Startup time is more important than most developers think: majority of desktop apps absolutely need it: imagine 5-second delay every time you wanted to launch Apple's "Quick View" to glance at a file, or imagine 5+ JVM-based apps load&initialize after reboot. Most desktop software I worked on was small-to-medium size and we just couldn't afford to add those 5+ seconds on JVM initialization. JVM I guess will work OK for projects like Ecilpse or a big Office suite or something like Photoshop. Microsoft understands this very well, this is why C#/.NET is so carefully optimized around loading time and comes with precompilation tools that essentially turn your C# code (including .NET itself) into native Win32 modules.
One project I want to do for myself is a usable Del.icio.us client for OSX. I can't see how I can use JVM-based tools for that... I want instant start-up by a hotkey when I need to search for links or add one. Moreover, I want users to be able to download and try it under 20 seconds.
The only JDKUI apps I'v ever used were development tools for Java itself plus numerous crap for the enterprise. And, of course, every once in a while I get "Java. Please wait..." splash screen on a new cellphone, followed by a prompt "Cancel/Go Back" keypress: that pretty much sums up my JVM-based UI experience. Which is sad: Clojure is going to be locked up on the server just like Java has been for years.