thanks for your thoughts - and I agree with them, mostly. However, I don’t see a better way to write cross-platform software than using Java.

But let me provide our own story — the (desktop) geometry software Cinderella (http://cinderella.de) we are writing (in Java) has had a predecessor, written in Objective-C on NextStep. We made the move from Objective-C to Java (back in 1996), because NextStep was just dead. There was no way to even compile the code on another platform, let alone run it.

Well, we could have waited another 5 years to resurrect the application on Mac OS X… no, not really. So with Java we do support Windows, we support Mac OS X, even Solaris or Linux, and we can do our development on the Mac.

Of course, it would be much easier if we were coding in Cocoa, but only for the Mac, and we just cannot ignore the people on the other side. That might change in another 5 years, but we don’t know yet. Java is now working for more than 10 years for us.

Tell Steve to port Cocoa to Windows, and I’d switch rather sooner than later.

Instead, the UI should be described with data, like an Interface Builder “.nib” file.

This gives me pause to think of Ajax frameworks like GWT or Wicket, where you basically code all the UI in Java. Are we bound to always repeat the same mistakes?

Web apps, not rich clients, but with Ajax the difference is smaller day after day.

Echoing what’s been said before:

* Ours is a niche product, licensed by 200 or so companies, and competition in minimal. So, we can “get away” with minor differences in our Java interface vs. native interface (mostly subtle nuances).

* We’ve layered our own web server/desktop synchronization code for the Java UI, so it has distinct deployment advantages (central, single-point maintenance) over typical native apps without resorting to things like Citrix. Had to do this because:

* Java’s perceived downfall was not so much due to interface issues, mostly due to; Sun’s ignorance of the importance of painless, seamless JVM/app install & update, Preponderance of “Java Developers” that hadn’t proper background to cope w/the sophisticated Swing UI, Sun’s propensity to break seemingly minor things in the API from release to release (e.g. from 1.2 -> 1.3 (?) JInternalFrames visibility default changed to not visible, several focus & modality issues that come & go, etc.). Essentially, it was & is not possible to expect any sophisticated Java UI that touches most JDK APIs to work properly from one JVM release to the next (without tweaking or even re-writing some behaviors, often subtle but critical).

* It was to our advantage to deliver a sophisticated interface to both Windows & Mac OS X platforms and as a small ISV this would *never* happen if it weren’t for JVM 1.2 & above (Swing, etc.). We would have been forced to forgo the OS X environment if we could not develop the Java interface the way we did (same, exact code/JARs for all platforms - very little platform-conditional code).

Bottom-line is that everything has advantages & disadvantages and nothing comes for free. You assess your requirements in the light of what is available.

I found Jens Alfke’s Java remarks insulting.

I used NeXTstep when it first came out and went to two NeXT conventions. Yah - I really loved the development environment. A few years ago I did some cocoa development and I still liked the overall development environment - and if all you ever have to do is write cocoa applications I think you are very fortunate indeed. I can write essays on the myriad things NeXT did right.

As soon as Java was available for download from Sun I was right on it. Sure I had no IDE but I found the language to be much better than Objective-C (and I think C++ is obscene) particularly in the area of memory management and threading. What particularly hooked me was the concept of write-once run-anywhere.

Now I work on a GUI application which works for both our Macintosh and Windows customers. Sure it doesn’t “look and feel” 100% like a Cocoa application, but most of our users cannot really tell the difference, even though it does take more effort to make our application look native on a Macintosh than on Windows. The point is I cannot think of any more effective ways to deploy the same GUI application on Macintosh, Windows, Solaris, and Linux and really open up your market opportunities for your product.

Most of the problems we have had on the Macintosh have been because Apple’s port of Java has been of a lower quality than Sun’s port of Java to Windows.

Finally, I find the combination of Java, Eclipse, Netbeans and other development tools to be an overall improvement over XCode. And who the hell cares about EMACS when you have Eclipse?

People seem to write (or use) one crappy AWT app and write off Java’s GUI capabilities. Luckily we don’t see one crappy Win or Mac app and write off the OS. Meanwhile Swing has been invented for years and is now fairly mature (read: OpenGL optimized) in Java 6…

I grant you OSX GUI programming finally (after these many years) provided something as decently organized as Java’s GUI API’s. There’s nothing comparable in the Windows or Unix world to Java, API-wise even today.

And Applets are still dead, of course. No hope for a 10 MB plugin. Sun never got that part, that’s for sure. But there’s a surprising number of Java Web Start apps running around.

For instance on the Mac there is only small demand (few users), and a small supply of developers, so many applications cost (or cost more than applications for the same purpose on other systems), but Mac users value their convenience over a little money.

Most Windows apps are written in some native toolkit (MFC?), because the market is big, and even an inconvenient language (for the developer) may be worth the higher development cost, if the end result is better.

Similarly, platforms like Mozilla, SWT, and Java focused on Windows as the major platform and look and run well on that system, because while a cross-platform app is supposed to reach all markets (not just one), it should of course run really well on the dominant OS.

And if a cross-platform toolkit runs well on Windows, why not use the cross-platform one? Especially for niche applications that don’t have large numbers of users it might be an advantage to use such a technology. You get another market for free (or little investment), and the technology might make development cheaper and the app more stable (Java vs C++). And cheaper development is good for the user as well, don’t you think?

Oh, and by the way, I know way more languages than just C and Java. It’s just that I consider Java by far the maturest and most well supported one (tools, libraries) right now. (languages like SML, Ruby or Lisp might be better for some domains or applications, but overall they don’t cut it for me.)