是否有人真的关心Java桌面应用?

是否有人真的关心 Java 桌面应用 ?
作者 Bruce Eckel

如果我明白有什么是对的，那应该是在 Java One 大会上的主题 Java FX 之年。我惊讶于 Java FX 的敏捷与清晰。但是博客社区似乎对此缺乏热情。

Java UI 的历史中充斥着错误的决定，其中之一就是，以一个在发布前最后一秒才建立好的 AWT( Abstract Windowing Toolkit ) 包作为 Java UI 的开始。因为（别惊讶）语言的设计者并不认为 UI 在 Java 中很重要。据传， AWT 包从设计到完成只用了一个月，这就不奇怪它是如此难以应用了。 AWT 的评价是 — 很多 BUG 且在所有的平台上的表现都相当的普通 — 这就让人对 Java UI 再无信任可言。直到精工细作很多年的 Swing 出炉 , 但也只不过得回一些失去了的魔力。用户们对第一印象有着很长时间的记忆，所以依然认为 Java 的 UI 界面是很蹩脚的，对他们而言，这冒着热气的咖啡杯看起来就像蒸汽。

当时这们语言坚决不支持组件和事件模型， JavaBean 可不是这些组件，而是一种无力的尝试，试图弥补其中的空隙。一个正真的组件与事件模型，绝对不是让程序员或上下环境通过大量的代码来模仿。如果这样也可以解决，我们将不再需要抽象，我们将可以这样说：基本的图灵机将解决所有的问题。

用 Swing 从来就不是简单的事，而是很凌乱与复杂的。当人们尝试让 Java 像 Visual Basic 一样简单的时候，产生了许多的抱怨。曾经 Sun 有一个要把 VB 移植过来的计划，不过后来又放弃了。没有真确的下层体系结构，这事永远也不会发生。你也将在大量乏味的 UI 代码中结束。

基本上， Java 中的 UI 程序员，都会后悔且很难适应，而不是正真的支持它。这样当人们谈到 Java FX 时的观望态度就不值得奇怪了。

有多少广为人知的 Java 桌面应用程序呢？好的， Eclipse 算一个 , 这是一个开发环境 , 用的是自己开发的 UI 包建立的应用程序 , 因为 Java 在当时并没有满足它的需求。 NetBean 算一个 , 这也是一个开发环境 , 展示了 Swing 现在可以很好的完成任务了。 IntelliJ 也算一个，这同样是一个开发环境。但是我不知道有什么常规的 Java 桌面程式，尤其是有人买的。

人们不用 Java 创建桌面应用的原因，实际上是因为那彻底失败的 UI 。

我已学习 Flex on 与 off 有好几年了，我发现它真的是最全面的 UI 解决方案。特别是因为我没有使用单一的语言来做后台逻辑。 Flex 是作为一个用户界面语言来设计的。使用 Flex 来作为多语言程式的 UI 解决方案是很具有扩展性的，因为人们可以创建一个 AMF (ActionScript Message Format ) 来沟通他们最喜爱的语言。

AMF 是理想的方法，因为它是异步的。可以很好的符合 UI 的使用范式。一般来说，你不会知道某个任务会耗时多长，而异步方法会保证你的 UI 总是可以做出快速响应，而不管真正的代码会运行多久。

在这篇文章中我将展示一个 PyAMF 的列子。 PyAMF 的项目很有效率、很容维护，同时提供了一个简单易懂的 Python 桌面应用的 UI 解决方案。

RubyAMF 项目同样很有效率。它可以建立 Ruby on Rails 应用程序的 Flex 用户界面。 ( 未完成 , 后面的意义不大啦 )

 

If I understood it right, this was supposed to be the "year of Java FX" at Java

One. We were going to be stunned by how clever and clear Java FX is. Instead, there seems to be deafening silence in the blogosphere.

The history of Java UI is littered with disastrous decisions, starting with the AWT (Abstract Windowing Toolkit ), which was created at the last second, because (no surprise) the language designers hadn't considered UI as an important paradigm for Java. Rumor has it that AWT was one month from conception to completion, which certainly fits. The results of AWT -- buggy and equally mediocre on all platforms -- destroyed everyone's faith in Java UI, for so long that Swing, which has been baking for years and years, is only just getting back some of the lost mojo. Users, who have a long memory of first impressions, still equate Java with crappy user interfaces, so to them the steaming coffee cup looks like something else that steams.

Then there's the steadfast refusal to support a component and event model in the language. No, Java Beans is not that; it's a weak attempt to fill in the gap. A true component and event model is far different from requiring the programmer or environment to spew out lots of code to emulate it. If that was the solution to everything, we'd never need abstractions; we might as well just say that a basic Turing machine will solve all problems.

And Swing programming has never been easy, but always messy and complicated. There were periodic murmurs of trying to make Java UI programming as easy as Visual Basic; at one point, Sun even had a VB porting project but abandonded it. Without the underlying infrastructure it can't ever happen. You'll always end up with lots of tedious UI code.

Basically, UI programming in Java has always been an afterthought, reluctantly accomodated but never really supported. It's no wonder that people are taking a wait-and-see attitude about Java FX.

How many well-known Java desktop applications are there? Well, there's Eclipse, a development environment, which created its own UI library because Java didn't satisfy the needs at the time. There's NetBeans, a development environment, which shows that Swing is now up to the task. And there's IntelliJ, a development environment. But I don't know of any general desktop apps in Java, especially ones that people pay for.

The reason people don't seem to create consumer and business desktop applications in Java may in fact be the UI debacle.

I've been studying Flex on and off for several years now and I continue to find it to be the best all-around solution for UIs, especially because I'm not trapped using a single language for the back-end logic. Flex was designed from the ground up as a user-interface language. The use of Flex as a UI solution for multiple languages has been expanding because people have been creating AMF (ActionScript Message Format ) bridge s for their favorite languages.

AMF is an ideal approach because it is asynchronous, so it fits well with the UI paradigm. In general, you never know how long something is going to take, and the asynchronous approach guarantees that your UI is always responsive no matter what is going on.

I've shown an example of PyAMF in this article . The PyAMF project appears to be quite active and well-maintained, and provides a straightforward solution for creating UIs for desktop Python applications.

RubyAMF also seems to be a very active project. It creates Flex user interfaces for Ruby on Rails apps, but there was a presentation at the last RailsConf on "Powering AIR Applications with Rails," so it would seem to support the desktop paradigm, as well.

There's also an AMFPHP project for PHP , although this is not a desktop solution.

There is an OpenAMF project for Java-Flash remoting , but it appears to be dead, with the last activity being 1.0 Release Candidate 12 in April 2006. The product doesn't work with more recent versions of Java, and no one appears to be maintaining it. Which is interesting because Java should theoretically be a much larger base and in that vastness there should be a group of people who want this -- I certainly do. Even more so because BlazeDS is open source and contains the core workings of what you need to create Java AMF (BlazeDS itself is only designed for Java web apps).

I don't know this for sure but I think at some point Adobe extended the olive branch to Sun regarding connecting Java and Flex beyond BlazeDS, but as usual, Sun couldn't see beyond their "not invented here" motto and had to create something "better." So now everyone appears to be taking a wait-and-see attitude, wondering whether Java FX is going to be another "greatest thing in the world, just you wait" that never materializes (perhaps Sun, in all of its tussles with Microsoft, has learned far too much about that company's marketing practices).

My first preference would be that Adobe would create and maintain a Java-AMF bridge for desktop applications, but perhaps Adobe considers Java a server-only technology; in any event, desktop Java support doesn't appear to be forthcoming from Adobe (I'd love to be surprised about that one). Perhaps their focus is on competing with Silverlight (I'm definitely waiting-and-seeing on Silverlight. Microsoft always promises big, but what they actually deliver is often very different -- consider Vista ).

So if people are really interested in desktop Java, prove it. Take the work that's already been done in the open-source BlazeDS and create a desktop Java-AMF bridge, so we can easily add AIR user interfaces on top of Java code. That way you can have easy-to-create UIs now, instead of waiting to see whether Java FX pans out.