java 桌面应用印象

因为桌面程序运行在宿主机器上， 所以比如你运行java桌面程序，必然要安装java虚拟机， 也就是相当于在操作系统上再加一层抽象。 这与直接调用api的桌面程序效率相比，或多或少低一点。

因为java主要用于因特网编程和移动开发，如jsp，而这些代码是运行在服务器端的，客户端只需要接收html代码即可，不需要安装java虚拟机，又因为java的跨平台性，语言又比较简单，还有就是背后有 Oracle 这样的大公司支撑，其出身简直就是高富帅，堪称贵族语言。所以java的用武之地太多了，而桌面应用方面，由于 微软 的垄断，所以java显得有点不太出众，又加之在其他方面做的太好，把人的注意力都吸引了，所以造成了人们感觉java不适合的假象，其实如果你执意要用java开发桌面应用的，我感觉完全没有问题。

Java桌面应用软件

mac上有不少软件是java写的. 其他平台上也有. 比如ecilpse,netbeans,jedit,永中office,VP UML,jude. 用JAVA写的桌面软件也蛮多的.vuze就是， 还有charles我常用。 我的看法是基本上对特效和本地外观要求不是那么高的话， java其实也是可以考虑用来做桌面软件的。 swing 的设计极其稳健。

请问怎么看一个软件是用java开发的还是用其他（比如C#或者mfc）开发的？

如果没有 JRE 库就跑不起来的就是JAVA写的（当然有的会自己打包JRE，但这样的体积一定不小）DB2的图形化界面就是用java写的。 不属实啊，Jetbrains的系列IDE全是Java开发的啊，够复杂也够好用了吧。在工业界，Java开发的桌面工具也已经很多了。 面向最终消费者的游戏也有， 最近2年很火的游戏的minecraft就是用java开发的，效果很好。 Java开发桌面程序效率还是很高的，不过如果要开发出和native程序一样的体验，难度就比较高了。

Java桌面软件的特征:

1. 确实是想跨平台对界面并没有太多效果的要求，
2. 界面效率也不是瓶颈相比于其他 GUI 工具，
3. 开发人员对Java更为熟悉比如，
4. 一些工具的管理界面
5. 针对计算机专业的用户的定位

分析Java与桌面应用

不过只做过Java在互联网服务方面的应用，没做过桌面应用， 所以只能说说自己的理解。 如方圆同学所说， 很多跨操作系统工具都是Java编写， 特别是一些Java相关的开发工具，Java的大支持企业 IBM , Oracle / Sun /MySQL 都有众多基于Java编写的工具。除此之外，貌似非常经典的足球经营类游戏Football Manager系列也需要跑在Java虚拟机上， 至少一部分是这样的， 还有PSP的一个模拟器，至于Java适不适合做桌面应用，这其实算是个仁者见仁，智者见智的问题，那么主要从其优缺点来说吧。

使用Java开发桌面应用的优势在于

• 优点一:
• 可以以较小的成本实现图形应用的跨平台
• 众所周知，对于窗口应用，需要很多平台依赖的图形库
• 当然， QT 也是个很好的跨平台图形库解决方案(c++的)。
• 因此对于非商业应用，特别是一些需要支持多平台的工具而言，Java是个很好的选择
• 优点二:
• Java语言非常流行，拥有众多开源中间件，
• 基于其开发自己的应用非常方便尽管如此，
• Java进行桌面开发也有很多缺点：
• 缺点一:
• Java应用必须运行在 JVM 上，因此安装Java应用必须安装JRE，其入侵性给用户带来不便
• java程序不能直接运行，机器上需要安装jre，而jre体积挺大
• 缺点二:
• JVM一般启动时规定内存占用等参数，因此对系统资源浪费较大，
• 对于单CPU以及3G内存的32位个人电脑来说，
• 仍然效率不如基于操作系统API的本地应用
• 运行速度慢，初次启动时间慢
• 缺点三:
• 和大多数现代语言相比，Java语言语法仍然比较繁琐，开发成本比较高
• 除传统桌面应用外，目前RIA桌面应用也比较流行，
• 但无论是
• Java还是 JavaFX 的竞争力仍然不及
• Adobe系的 Flash /Flex/AIR等，
• 恐怕未来还要被HTML5/CSS3/Javascript进一步压制。
• 缺点四:
• swing本身非常优雅，但是缺乏可靠又强大的可视化设计工具，界面设计基本上得靠编码完成，开发效率上不去。
• 默认风格不够漂亮，要做漂亮，需要下大功夫。
• 与操作系统交互不够方便 。

描述现状

单纯的J2SE确实很难开发桌面应用。 必须对它进行改造， 于是有了 SWT ,JFace等框架 。于是有了 Eclipse 这样的工具。 要不J2SE开发的应用都有很强的专业性， 针对计算机专业的软件， 因为计算机专业用户电脑多数安装有JVM。 比如ETL工具Kettle，(注解: Extract-Transform-Load,数据从来源地出发，1.抽取2.转换3.加载 到目的地.数据仓库) ，Java代码分析工具Findbugs。Java的桌面程序并不少， 其中最为知名的莫过于Eclipse。 在Linux和Mac下， java程序的比例远高于Windows下。 不过，“Java不适合写桌面应用”的说法有一定道理。

论调背景

论调的主要背景是供Windows下使用的企业桌面应用的开发。 由于一些历史和定位的原因， 对于这种GUI程序的需求， Java的优势不明显，劣势比较明显。

Java传统

这事还得从Java的传统，“跨平台一致性”说起。

第一： 后台跨平台

在写后台逻辑的时候，跨平台是好东西。

很多公司都是在Windows下开发，在Linux下部署，方便。

第二: 前端GUI跨平台

但涉及到GUI的时候，跨平台就成了个“看上去很美”的东西。

理论上，我写个窗口，在Windows和Mac下都一样能用，那是多么美好的事啊。

但实际上，每个平台提供的GUI控件多多少少有点差别

一坚持跨平台，麻烦就来了，该支持多少控件，怎么支持呢

发展历史 AWT

一开始，Java的思路是：那简单啊， 有原生控件干嘛不用， 至于不跨平台的，就不支持呗， 又坚持了原则(跨平台)，又回避了问题。(平台控件差异)这一代的gui库，awt，就此诞生。因为Java一开始是一根筋想推广Applet的，只是“顺便”也支持本地应用 。设计成这样不能说不合适， 毕竟，HTML也是同样的思路，只支持几种最基本的控件。 但对于想开发复杂点界面的人来说，就有麻烦了。想来个目录树吧，对不起，不支持； 想来个进度条吧，对不起，不支持。 旁边放着Delphi和VB这么方便的东西，干吗受这气啊。

发展历史 swing

这样一来，Java自己也觉得说不过去了。 但又要跨平台，又要提供丰富的控件支持，那就只有另起炉灶， 开始用第二种思路：自己动手、丰衣足食，自己重写一套GUI控件，代替操作系统的原生控件。 这一代的gui库，叫做swing。 这也是一个想“彻底”解决问题的思路，但是要付出代价。代价之一就是效率。 我们可以参考一下另一个相同思路的产品——flash。 为了实现矢量动画，在flash的那个小框里，图是一帧一帧地算出来的。 接下来的事情我们都知道了： 复杂的flash动画极耗cpu； iPhone说，您太耗电了，俺就不支持了； Adobe说，那好吧，那俺也不费心折腾移动版flash了。自己画出来的控件毕竟不能跟原生控件比效率， 尤其是在早期Java优化还不够完善的时候。 而且，自力更生的目的只是为了平台兼容，不是为了更好的效果，这事儿其实怎么想怎么亏。

代价之二就是效果。 自己画的控件毕竟只是模拟，还是会有细节差别。 比如著名的毛玻璃效果，这不是简单套样式就能套出来的。 而且，各个平台控件的风格本来就不一样， 虽然swing提供了几种外观， 但大部分程序出于偷懒或是跨平台一致考虑，还是使用默认外观。 默认外观跟平台不一致倒也不是问题，主要是别比平台效果土。

我用着win7，一个程序非让我感觉回到xp时代，心里特别添堵。

1. java GUI界面的罪过要追溯到SUN开始设计GUI的时候，
2. 他们招了一个强力的女人作为GUI部门的老大，
3. 这个女人一来就推翻了sun原来的awt思路，
4. 带着她以前的团队成员加入，后来就诞生了swing。
5. 这个女人叫Amy Flowler，
6. 她之前在parc-place公司任职，
7. 一贯就是模拟界面的倡导者。

发展历史 swt

就这样，一帮人商量着，又琢磨出个新思路：做适配。 平台有这个控件，就直接用，保证效率； 没有，再造轮子，保证可用。就这样，swt问世。eclipse的gui就是基于此。 swt是赞，不过这属于改良，两个根本问题仍在：

1. 跟操作系统api打交道不是Java的长项，效率仍然不能与c++等相提并论。

2. 到底要不要跨平台。

如果要跨平台，swt接浏览器控件、接ActiveX控件的功能就成了形同虚设；

而要是不想跨平台，又何必使用Java呢，.Net在一旁已经恭候多时了。

1.技术本身，很难做到UI跨平台

另一方面，即使每个平台都支持的 control 也多多少少有些差异。比如同样是文本框，Windows 和 Mac ( Cocoa ) 对待 non-English 输入法选词的语义就不同。再比如对 focus-lost 的处理二者也不同。所以 SWT 其实目前很难做到 Swing 那样的跨平台。 跨平台么，终究还是只能做到最大公约数， 比如 x86 支持 4 级，Unix 只用两级。可那是大家都同意不用的。(硬件上) 在 UI 级别可没有人能同意不用操作系统的某个功能。

2.产业问题

除了技术本身，还有一个产业的问题， 围绕着GUI控件也存在一个生态环境，没有丰富的领域、行业控件的支持， 技术本身的战斗力也会大打折扣。而Java这方面的生态较为薄弱。

发展历史

Java的GUI一开始定位就不是消费者市场， Java Applet的产生是因为当时Web还没有出现一种能够展现丰富动画效果的技术。 Flash的后来居上更是加速了Java Applet技术在Web中的消亡。 而AWT只是为了支持Java Applet技术存在的。 后来Java技术更是被SUN定位在企业开发领域， 桌面领域也变得比较小众和专业化。 再后来，Swing库更是一个被叫做Amy的女人弄得一团糟…. Swing/AWT说实话是比较烂的， 要不然 IBM 不会自己开发一个SWT库替代。

原因分析

尽管我们可以用Java创建出桌面应用， 但只要我们想开发真正的富桌面应用我们就无法真正使用Java ，而使用JNI、C/C++和平台依赖的libraries等。 使用Java构建桌面应用更多的是困难和麻烦， 比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事。 而且没有用Java编写的图片处理应用， 没有一个纯粹的Javaweb浏览器， 没有数字音频应用， 没有3D建模器， 没有矢量图形编辑器， 没有先进的光栅编辑器Java今日在桌面端所到达的高度只能满足那些服务器开发者， 因为他们只需要在远程服务时使用电脑桌面上的简单界面。 过去我们一直说这是因为Java太慢， 无法在一个慢的平台上开发出如此复杂的应用。 但我们这样说是错的。

原因有两点：

一，Java从来就没有慢过，即便有些部分曾经慢过，

但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升，比如JITs，GCs等。

这一点也正是Java语言卓越的地方。

二，由于Java平台的天然特性，

Java应用总是第一个利用市场上新硬件和新操作系统的应用。

一旦JVM被配置到了一个新系统中，

几乎不需要任何编辑和调试，

Java应用就可以在上面全速运行。

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

我们总是说： 由于Sun总是一个服务器端公司的原因，Java在桌面端一直没有真正的机会。 而 Oracle 的收购让这种境况看起来不会有什么改变。 希望这不要再继续下去， 为了Sun、 Oracle 和Java自身的利益， Oracle 内部的知名人士应该提醒公司来让他们知道： 如果缺乏了在桌面端的能力和效率， 必将影响Java的普及率甚至它在服务器端的占有率。我们一直以来习惯着Sun主要提供服务器端服务， 因而想象着未来更多的处理能力还是出现在服务器端， 而客户端不过是连接服务器的简单服务。 这种情况已被证明是绝对错误的。因为未来的桌面应用将服务、应用与硬件所有的运算能力相结合， 大量的数据和解码、声音、图像、视频被开发者处理， 而且用并行编程的方式来实现， 既保证了丰富的性能又保证了速度。

对开发者来说，未来的服务既需要他们在客户端处理也需要在服务器端处理： 执行复杂的搜索、图像、视频以及虚拟3D环境需要服务器端的技术， 而远程服务如医学分析、远程教育和远程会议等则需要客户端能力。只是令我们感到失望的是历史又一次地重复了， 因为至今Java中还没有什么大的动作。

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

客户端现在基本上被 微软 和Apple包揽。 到Cocoa论坛中会发现他们谈论的是GUI的可用性、响应性、终端户如何处理桌面应用等而我们的论坛呢， 大部分人认为应用的未来在服务器端。 这就是文化上的差异。 但是桌面技术需要做很多工作， Swing很慢很慢地进化， 连同Netbeans平台、Java3D,JOGL等应用勉强成为了桌面端的一个选择。但Sun置此境遇于不顾，只是模仿Flash发布了一款新的脚本语言， 但是那些API只有使用JavaFX才可用Jeff

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

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

{Java支持OpenGL(JOGL)是近期在Java OpenGL图形API结合。它是一个包装库,它可以访问OpenGL API,并且它被设计来创建Java编码的2D和3D图形应用程序。}

Osvaldo Doederlein回复道： 我认为JOGL的支持没有那么糟糕， 毕竟它是JavaFX Desktop Runtime的一个依赖。 实际上，我们可以写一个非JavaFX的小程序， 而且不需要请求本地代码的许可性就以配置。据说Java + QT也可行, 只不过没试过, QT是跨平台的, Java也是跨平台的, QT本身的效率自然大于Java, 不知道是否可行 awt,jface. 试试看.不能简单说java不适合做桌面系统， 每一种语言都有它的专长。 java做桌面开发更多的是面向功能开发， 在用户交互方面确实是它的短板。

最后，小编准备了一套2019年的Java学习教程。

领取方式：894180257加群即可。Java程序员交流群。