Trackback: http://www.artima.com/weblogs/viewpost.jsp?thread=234900
Does Anyone Really Care About Desktop Java?
by Bruce Eckel
Summary
If so, this is a call to action.
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) bridges 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.
要是我没记错的话，在JavaOne大会上今年被定为“JavaFX年”。我们本该会叹服JavaFX的智能和简练性。然而在Blog圈子里却显得震耳欲聋的安静（意为不同意或缺乏热诚 –译者注）。
Java UI的历史无不充斥着极其糟糕的决定。首先是AWT（Abstract Windowing Toolkit），由于语言设计者们并没有计划将UI（用户界面）作为Java一个重要组件考虑进去（不必惊讶），它是在最后一秒钟才诞生的。据说AWT从产生概念到完成只用了一个月时间。而AWT的结果—Bug成堆且在所有平台表现平平—重创了所有人在Java UI上的信心。后来的Swing，历经年复一年的考验，也只是挽回了一些丢掉的颜面。而怀有这样长久的第一印象，用户们当然仍将Java和劣质的用户界面画上等号。因此对他们来说，热气腾腾的咖啡杯里似乎有别的什么东西在冒着热气。
之后，Java又坚决拒不支持组件和事件模型。Java Beans也不例外，它的出现只是为了弥补这个缺陷而作的一次尝试。真正的组件和事件模型可不是需要程序员或环境实现大量代码来效仿它的。如果它能解决所有问题，我们就不必需要抽象（abstractions）概念了，更可以说一个基本的图灵机就能解决所有问题。
Swing程序设计不但不简单，还很凌乱、复杂。虽然时不时会出现让Java UI编程变得和Visual Basic一样简单的声音，在这一点上Sun甚至也提出了VB引入计划，但最后都搁浅了。没有底层基础架构的支持这些都不可能实现。最终你还是会产生大量UI代码的。
Java的UI编程基本上都是“马后炮”，不情愿地接受却又从未真正支持过。因此如今人们对Java FX所持有的观望态度也就不足为怪了。
著名的Java桌面程序有哪些呢？恩，Eclipse，一个开发环境，由于那时Java还不能满足用户需要，它就成为了创建自己的UI库的工具。NetBeans，另一个开发环境，使得Swing如今依赖于任务了。还有Intelli J，也是一个开发环境。可是我还不知道有哪个通用桌面程序是Java写的，即使是付费的也没有。
人们不用Java来创建个人或商用桌面程序的原因也许就是它在UI上的失败。
我已经断断续续学了几年Flex，仍认为它是UI的最佳解决方案，特别是在后台逻辑上未局限于使用一种语言的时候。Flex是完全作为一种用户界面语言而设计，并且在作为多种语言的UI解决方案上将继续大有作为，因为人们一直在为他们钟爱的语言建立AMF（ActionScript消息格式）桥。
AMF由于其异步性而成为一种理想格式，和UI样式表也有良好的兼容性。总之你不会看到执行需要多长时间，异步方法可以保证你的UI在任何情况下总是处于响应状态。
我在这篇文章里给出了PyAMF的一个例子。PyAMF项目总是看起来十分活跃且势头良好，还为Python桌面程序提供了一个创建UI的简单方法。
RubyAMF 也是一个很活跃的项目。它为Ruby on Rails程序提供了Flex用户界面。但在最近的RailsConf大会上出现了有关“Rails下的AIR程序”的报告。因此看来它还将支持桌面程序。
还有一个基于PHP的AMFPHP项目，尽管并不是桌面解决方案。
Java-Flash remoting的OpenAMF项目 也似乎中止了。它最近的一次1.0版本发布还是在06年4月份。它的产品并没有使用更近一点的Java版本，更不用说维护了。有意思的是理论上讲Java应该有更广泛的基础且有一群人在支持它。而且由于开源的BlazeDS包含了创建JavaAMF的核心代码（BlazeDS本身只是为Java的web程序服务的）也更凸现了这一点。
虽然不很确信，但我想从某种角度上说在基于BlazeDS连接Java和Flex上Adobe向Sun伸出了橄榄枝。可通常Sun会本着“非此处发明(not invented here)” 的态度(即不愿意用外人发明的东西–译者注)将其拒绝并创建“更好”的东西出来。所以现在看大家都在观望着，想看看JavaFX到底是否会成为“期待中的又一个世界上最好的语言”（或许在和微软的无数次较量中Sun已经学会了太多的营销方面实践技巧了）。
我所希望看到的是Adobe能够为桌面应用程序创建并维护一个Java-AMF桥。但也许Adobe认为Java只是一个服务器上的工具，无论什么时候Java支持的桌面应用似乎永远不会出现（我对此十分惊讶）。他们所重视的是与Silverlight的竞争（我对Silverlight也确实持观望态度。微软做出的允诺不少，实际做到的却常常大相径庭—看看Vista吧）。
所以如果人们真的对桌面Java感兴趣，马上尝试一下吧。找出开源BlazeDS上实现过的代码，创建一个桌面Java-AMF桥，这样我们就可以在Java代码开头轻松地加入AIR用户接口。通过此方法现在就能很容易地创建UI而不必等待JavaFX成功与否了。
by Bruce Eckel
Summary
If so, this is a call to action.
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) bridges 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.
要是我没记错的话，在JavaOne大会上今年被定为“JavaFX年”。我们本该会叹服JavaFX的智能和简练性。然而在Blog圈子里却显得震耳欲聋的安静（意为不同意或缺乏热诚 –译者注）。
Java UI的历史无不充斥着极其糟糕的决定。首先是AWT（Abstract Windowing Toolkit），由于语言设计者们并没有计划将UI（用户界面）作为Java一个重要组件考虑进去（不必惊讶），它是在最后一秒钟才诞生的。据说AWT从产生概念到完成只用了一个月时间。而AWT的结果—Bug成堆且在所有平台表现平平—重创了所有人在Java UI上的信心。后来的Swing，历经年复一年的考验，也只是挽回了一些丢掉的颜面。而怀有这样长久的第一印象，用户们当然仍将Java和劣质的用户界面画上等号。因此对他们来说，热气腾腾的咖啡杯里似乎有别的什么东西在冒着热气。
之后，Java又坚决拒不支持组件和事件模型。Java Beans也不例外，它的出现只是为了弥补这个缺陷而作的一次尝试。真正的组件和事件模型可不是需要程序员或环境实现大量代码来效仿它的。如果它能解决所有问题，我们就不必需要抽象（abstractions）概念了，更可以说一个基本的图灵机就能解决所有问题。
Swing程序设计不但不简单，还很凌乱、复杂。虽然时不时会出现让Java UI编程变得和Visual Basic一样简单的声音，在这一点上Sun甚至也提出了VB引入计划，但最后都搁浅了。没有底层基础架构的支持这些都不可能实现。最终你还是会产生大量UI代码的。
Java的UI编程基本上都是“马后炮”，不情愿地接受却又从未真正支持过。因此如今人们对Java FX所持有的观望态度也就不足为怪了。
著名的Java桌面程序有哪些呢？恩，Eclipse，一个开发环境，由于那时Java还不能满足用户需要，它就成为了创建自己的UI库的工具。NetBeans，另一个开发环境，使得Swing如今依赖于任务了。还有Intelli J，也是一个开发环境。可是我还不知道有哪个通用桌面程序是Java写的，即使是付费的也没有。
人们不用Java来创建个人或商用桌面程序的原因也许就是它在UI上的失败。
我已经断断续续学了几年Flex，仍认为它是UI的最佳解决方案，特别是在后台逻辑上未局限于使用一种语言的时候。Flex是完全作为一种用户界面语言而设计，并且在作为多种语言的UI解决方案上将继续大有作为，因为人们一直在为他们钟爱的语言建立AMF（ActionScript消息格式）桥。
AMF由于其异步性而成为一种理想格式，和UI样式表也有良好的兼容性。总之你不会看到执行需要多长时间，异步方法可以保证你的UI在任何情况下总是处于响应状态。
我在这篇文章里给出了PyAMF的一个例子。PyAMF项目总是看起来十分活跃且势头良好，还为Python桌面程序提供了一个创建UI的简单方法。
RubyAMF 也是一个很活跃的项目。它为Ruby on Rails程序提供了Flex用户界面。但在最近的RailsConf大会上出现了有关“Rails下的AIR程序”的报告。因此看来它还将支持桌面程序。
还有一个基于PHP的AMFPHP项目，尽管并不是桌面解决方案。
Java-Flash remoting的OpenAMF项目 也似乎中止了。它最近的一次1.0版本发布还是在06年4月份。它的产品并没有使用更近一点的Java版本，更不用说维护了。有意思的是理论上讲Java应该有更广泛的基础且有一群人在支持它。而且由于开源的BlazeDS包含了创建JavaAMF的核心代码（BlazeDS本身只是为Java的web程序服务的）也更凸现了这一点。
虽然不很确信，但我想从某种角度上说在基于BlazeDS连接Java和Flex上Adobe向Sun伸出了橄榄枝。可通常Sun会本着“非此处发明(not invented here)” 的态度(即不愿意用外人发明的东西–译者注)将其拒绝并创建“更好”的东西出来。所以现在看大家都在观望着，想看看JavaFX到底是否会成为“期待中的又一个世界上最好的语言”（或许在和微软的无数次较量中Sun已经学会了太多的营销方面实践技巧了）。
我所希望看到的是Adobe能够为桌面应用程序创建并维护一个Java-AMF桥。但也许Adobe认为Java只是一个服务器上的工具，无论什么时候Java支持的桌面应用似乎永远不会出现（我对此十分惊讶）。他们所重视的是与Silverlight的竞争（我对Silverlight也确实持观望态度。微软做出的允诺不少，实际做到的却常常大相径庭—看看Vista吧）。
所以如果人们真的对桌面Java感兴趣，马上尝试一下吧。找出开源BlazeDS上实现过的代码，创建一个桌面Java-AMF桥，这样我们就可以在Java代码开头轻松地加入AIR用户接口。通过此方法现在就能很容易地创建UI而不必等待JavaFX成功与否了。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/782823/viewspace-432945/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/782823/viewspace-432945/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
