Java用于开发桌面应用的优劣分析

我承认即使在JavaFX出现之前Java已经在桌面领域做出了一些重大的提升 比如Swing中的提升 我们现在也有了很棒的OpenGL DirectX也有了很大的提升 启动时间也显著提升了 没错 Java在去年做了很多显著而有效的工作

然而不得不说的是 除此之外其他的仍是一塌糊涂 比如Java sound实际上并不好用 被遗弃的Java D又如何呢？最近甚至JOGL也被Sun遗弃 包括很久之前的SwingLab JAI（用作图片处理）多年未真正升级过 看起来也没有在什么地方得到利用 它迫切需要性能上的巨大提升以适应来临的多核GPU时代所有这些应用于桌面领域的Java产品不是被遗弃就是成为鸡肋

而且很关键一点是 尽管我们可以用Java创建出桌面应用 但只要我们想开发真正的富桌面应用我们就无法真正使用Java而使用JNI C/C++和平台依赖的libraries等

使用Java构建桌面应用更多的是困难和麻烦 比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事 而且没有用Java编写的图片处理应用 没有一个纯粹的Java web浏览器 没有数字音频应用 没有 D建模器 没有矢量图形编辑器 没有先进的光栅编辑器 Java今日在桌面端所到达的高度只能满足那些服务器开发者 因为他们只需要在远程服务时使用电脑桌面上的简单界面

过去我们一直说这是因为Java太慢 无法在一个慢的平台上开发出如此复杂的应用 但我们这样说是错的 原因有两点 一 Java从来就没有慢过 即便有些部分曾经慢过 但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升 比如JITs GCs等 这一点也正是Java语言卓越的地方 二 由于Java平台的天然特性 Java应用总是第一个利用市场上新硬件和新 *** 作系统的应用 一旦JVM被配置到了一个新系统中 几乎不需要任何编辑和调试 Java应用就可以在上面全速运行 比如你在 位的 *** 作系统上开发了一个应用 它就可以全速运行在Windows 或者Solaris的 位JVM上 所以所谓的Java太慢根本不能成为Java在桌面端碌碌无为的借口

而且 如果你是一个终端用户 你甚至不需要从网站上重新下载应用 这意味着不仅终端用户和开发者得到了速度提升 甚至应用的执行性能的前边也得到了速度提升 今天 JIT在runtime为本地 *** 作优化代码已经做得很棒了 这意味着你可以挖掘出你运行的硬件的全部的能力 这是一个静态编译语言永远也无法竞争过的性能 只是这个性能如果可以运用到桌面端和游戏领域就好了

我们总是说 由于Sun总是一个服务器端公司的原因 Java在桌面端一直没有真正的机会 而Oracle的收购让这种境况看起来不会有什么改变 希望这不要轮昌察再继续下去 为了Sun Oracle和Java自身的利益 Oracle内部的知名人士应该提醒公司来让他们知道 如果缺乏了在桌面端的能力和效率 必将影响Java的普及率甚至它在服务器端的占有率

我们一直以来习惯着Sun主要提供服务器端服务 因而想象著未来更腊茄多的处理能力还是出现在服务器端 而客户端不过是连接服务器的简单服务 这种情况已被证明是绝对错误的 因为未来的桌面应用将服务 应用与硬件所有的运算能力相结合 大量的数据和解码 声音 图像 视频被开发者处理 而且用并行编程的方式来实现 既保证了丰富的性能又保证了速度 对开发者来说 未来的服务既需要他们在客户端处理也需要在服务器端处理 执行复杂的搜索 图像 视频以及虚拟 D环境需要服务器端的技术 而远程服务如医学分析 远程教育和远程会议等则需要客户端能力

只是令我们感到失望的是历史又一次地重复了 因为至今Java中还没有什么大的动作

armin Ehrenreich 在回复中说道 说的好 我完全认同

确实迫切需要跨平台的桌面应用技术 而且我不认为C++结合Qt是个好的选择 你说阐述的问题之所以没有引起很多的共鸣 我想是文化上的问题 许多Java社区的人们包括Sun内部的负责人无法理解你所说的 所以我断言Oracle也不会对Java做出什么大迅敏的改变

客户端现在基本上被微软和Apple包揽 到Cocoa论坛中会发现他们谈论的是GUI的可用性 响应性 终端户如何处理桌面应用等而我们的论坛呢 大部分人认为应用的未来在服务器端 这就是文化上的差异

但是桌面技术需要做很多工作 Swing很慢很慢地进化 连同Netbeans平台 Java D JOGL等应用勉强成为了桌面端的一个选择 但Sun置此境遇于不顾 只是模仿Flash发布了一款新的脚本语言 但是那些API只有使用JavaFX才可用

Jeff Martin回复道 正确的观点 但我有一点不同 Sun真正的问题是他应该吃自己的饭 用自己的力量来用Java写一些实在的桌面应用 这可以证明他们关于Java在桌面端的承诺 证明他们可以写出应用 提升框架和工具 我不认为另一个框架会帮助Java

James Sugrue回复道 我同意作者观点 我也很支持桌面端开发 看看现在处于开发中的Eclipse e 中的一些项目 它们为桌面和浏览器提供了一个解决方案 所以我想还是有一些希望的 但我认为我们不需要过分聚焦于桌面端 JavaFX是正确方向上的一个迈进 只是无法在Swing和Java D/JOGL中看到应用提升

Osvaldo Doederlein回复道 我认为JOGL的支持没有那么糟糕 毕竟它是JavaFX Desktop Runtime的一个依赖 实际上 我们可以写一个非JavaFX的小程序 而且不需要请求本地代码的许可性就可以配置

lishixinzhi/Article/program/Java/hx/201311/25625

什么是 JavaFX ？

JavaFX 包含了一些列图形和媒体包，允许程序员设计、创建、测试、调试、和部署富客户端应用并且保持跨平台的 *** 作一致性。

JavaFX 应用程序

JavaFX 应用程序由 Java API 编写，可以调用任何 Java API 包。例如，可以调用 Java API 访问本地 *** 作系统，并且与服务器进行连接。

JavaFX 的外观可以自定义。层叠样式表（CSS）将应用的外观与功能分离，让程序员可以更专注于编码。美工可以简单地通过 CSS 来自定义应用程序的外观。

如果你有 Web 设计的背景，或者你想将 UI 和后台逻辑分离，那么你还可以将 UI 放入到 FXML 标记语言中，用 Java

编写业务逻辑。如果你只想编码，那么可以将编写 UI 的工作交给 JavaFX Scene Builder。在支持 JavaFX

的集成开发环境（IDE）中，可以使用 JavaFX Scene Builder 来编写 FXML 标记语言。

可用性

从 JavaFX 2.2 以后，JavaFX 已经集成在 JRE 7 和 JDK 7 以及以后的 Java 版本中了。因为 JDK

可以很好地运行在主流桌面系统上（Windows, Mac OS X, and Linux），因此 JavaFX

也可以运行在这些主流的桌面系统上。跨平台兼容性，可以让 JavaFX 的开发者和用户得到一致的体验。

在 JDK 的下载页锋吵面，可以获取 JavaFX 例子的 Zip 包。这些例子应用程序提供了很多代码来演示如何使用 JavaFX。

主要特性

JavaFX 2.2 和之后的版本都包含以下主要特性：

Java API

JavaFX 是一个 Java 包，由 Java 类和 Java 接口等原始的 Java 代码编写而成。这些 API 在设计上可以很友好的替代为 Java VM 语言，例如 JRuby 或 Scala。

FXML and Scene Builder

FXML 是基于 XML 的标记语言，用来创建 JavaFX UI。设计者可以直接编写 FXML 或者使用 IDE 的 Scence Builder 来编写 FXML。

WebView

Web 组件可以使用 WebKitHTML 技术将 Web 页面嵌入到 JavaFX 应用程序中。在 WebView 中运行的

JavaScript 可以调用 Java API，并且 Java API 也可以调用 WebView 中运行的 JavaScript。

Swing 集成

旧有的 Swing 应用程序可以更行 JavaFX 的新特性，比如丰富的图形媒体播放功能和嵌入 Web 页面的功能。

丰富的自有控件和CSS

JavaFX 提供了桌面应用程序需要用到的主要控件。并且控件的外观可以使用标准的 Web CSS 来进行控制。

画布（Canvas）API

Canvas API 允许在可以包含一个作图元素的 JavaFX scene 直接绘制图形。

支持多点触控

基于平台的底层能力，JavaFX 支持多点触控功能。

硬件加速的图形通道

JavaFX 图形渲染基于 Prism。如果使用了支持 Prism 的显卡或 GPU，JavaFX 可以很快的进行平滑渲染。如果系统不支持 Prism，那么默认值将会变为 Java 2D。

高性能的媒体引擎

媒体通道蔽磨支持 Web 多媒体内容的播放，基于 GStreamer 媒体框架，提供了稳定的、低延迟的媒体播银并侍放框架。

自包含的应用程序部署模式

自包含的应用程序，可以包含所有的应用程序资源、Java 运行时以及 JavaFX 运行时。应用程序发布后，可以在 *** 作系统本地安装，获得 *** 作系统一致的安装和加载体验。

---