为什么很多人说 Java 不适合编写桌面应用？
请大家解释一下，谢谢。
按票数排序
Java的桌面程序并不少，其中最为知名的莫过于Eclipse。在Linux和Mac下，Java程序的比例远高于Windows下。不过，“Java不适合写桌面应用”的说法有一定道理，论调的主要背景是供Windows下使用的企业桌面应用的开发。由于一些历史和定位的原因，对于这种GUI程序的需求，Java的优势不明显，劣势比较明显。这事还得从Java的传统，“跨平台一致性”说起。在写后台逻辑的时候，跨平台是好东西。很多公司都是在Windows下开发，在Linux下部署，方便。但涉及到GUI的时候，跨平台就成了个“看上去很美”的东西。理论上，我写个窗口，在Windows和Mac下都一样能用，那是多么美好的事啊。但实际上，每个平台提供的GUI控件多多少少有点差别，一坚持跨平台，麻烦就来了，该支持多少控件，怎么支持呢。一开始，Java的思路是：那简单啊，有原生控件干嘛不用，至于不跨平台的，就不支持呗，又坚持了原则，又回避了问题。这一代的gui库，awt，就此诞生。因为Java一开始是一根筋想推广Applet的，只是“顺便”也支持本地应用，设计成这样不能说不合适，毕竟，HTML也是同样的思路，只支持几种最基本的控件。但对于想开发复杂点界面的人来说，就有麻烦了。想来个目录树吧，对不起，不支持；想来个进度条吧，对不起，不支持。旁边放着Delphi和VB这么方便的东西，哥干吗受这气啊。这样一来，Java自己也觉得说不过去了。但又要跨平台，又要提供丰富的控件支持，那就只有另起炉灶，开始用第二种思路：自己动手、丰衣足食，自己重写一套GUI控件，代替操作系统的原生控件。这一代的gui库，叫做swing。这也是一个想“彻底”解决问题的思路，但是要付出代价。代价之一就是效率。我们可以参考一下另一个相同思路的产品——flash。为了实现矢量动画，在flash的那个小框里，图是一帧一帧地算出来的。接下来的事情我们都知道了：复杂的flash动画极耗cpu；iPhone说，您太耗电了，俺就不支持了；Adobe说，那好吧，那俺也不费心折腾移动版flash了。自己画出来的控件毕竟不能跟原生控件比效率，尤其是在早期Java优化还不够完善的时候。而且，自力更生的目的只是为了平台兼容，不是为了更好的效果，这事儿其实怎么想怎么亏。代价之二就是效果。自己画的控件毕竟只是模拟，还是会有细节差别。比如著名的毛玻璃效果，这不是简单套样式就能套出来的。而且，各个平台控件的风格本来就不一样，虽然swing提供了几种外观，但大部分程序出于偷懒或是跨平台一致考虑，还是使用默认外观。默认外观跟平台不一致倒也不是问题，主要是别比平台效果土。我用着win7，一个程序非让我感觉回到xp时代，心里特别添堵。就这样，一帮人商量着，又琢磨出个新思路：做适配。平台有这个控件，就直接用，保证效率；没有，再造轮子，保证可用。就这样，swt问世。eclipse的gui就是基于此。swt是赞，不过这属于改良，两个根本问题仍在：1. 跟操作系统api打交道不是Java的长项，效率仍然不能与c++等相提并论。2. 到底要不要跨平台。如果要跨平台，swt接浏览器控件、接ActiveX控件的功能就成了形同虚设；而要是不想跨平台，又何必使用Java呢，.Net在一旁已经恭候多时了。（补充：原生控件在各平台下还是会有些差异，感谢@冯东指点）@冯东：另一方面，即使每个平台都支持的 control 也多多少少有些差异。比如同样是文本框，Windows 和 Mac (Cocoa) 对待 non-English 输入法选词的语义就不同。再比如对 focus-lost 的处理二者也不同。所以 SWT 其实目前很难做到 Swing 那样的跨平台。跨平台么，终究还是只能做到最大公约数，比如 x86 支持 4 级，Unix 只用两级。可那是大家都同意不用的。在 UI 级别可没有人能同意不用操作系统的某个功能。 除了技术本身，还有一个产业的问题，围绕着GUI控件也存在一个生态环境，没有丰富的领域、行业控件的支持，技术本身的战斗力也会大打折扣。而Java这方面的生态较为薄弱。 综上，如果一个GUI程序使用Java，通常都是有这些特征：确实是想跨平台对界面并没有太多效果的要求，界面效率也不是瓶颈相比于其他GUI工具，开发人员对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，其入侵性给用户带来不便* JVM一般启动时规定内存占用等参数，因此对系统资源浪费较大，对于单CPU（尽管目前一般都是双核甚至4核）以及3G内存的32位个人电脑来说，仍然效率不如基于操作系统API的本地应用* 和大多数现代语言相比，Java语言语法仍然比较繁琐，开发成本比较高除传统桌面应用外，目前RIA桌面应用也比较流行，但无论是Java还是JavaFX的竞争力仍然不及Adobe系的Flash/Flex/AIR等，恐怕未来还要被HTML5/CSS3/Javascript进一步压制。综上，这些原因导致Java并非开发桌面应用的首选解决方案，纯属个人见解……
@钟声 的答案比较全面了。不过从 @陈昊 的并非回答的回答说开：很多学JAVA的人一开始学都听过这句。。于是SE就只被人当作基础过渡算了。。结果JAVA程序员很大部分都聚拢在EE 关注了 希望得到更多更全面的答案那么，很多人一开始听过这句是谁说的？为什么 SE 过渡之后的终极是 EE？答案是：说这话的人正是 Sun。Java 本来是作为 Web 上的 rich-client 设计的，Applet 在浏览器上失败之后，搞基于 ActiveX 的 Applet plug-in，再失败之后搞 Web Start，再失败之后，Sun 祭出 EE，宣称 GUI 它不玩了，宣称 Java 是最好的 server-side 语言。有人说这是个「见仁见智」的问题。问题就是 Sun 这位贱人是什么仁什么智啊。
Desktop Java不能广泛流行的最主要原因是，跨平台的GUI方案已经有Web了。假如没有Web，大多数Enterprise Application会采用Desktop Java开发的
尽管我们可以用Java创建出桌面应用，但只要我们想开发真正的富桌面应用我们就无法真正使用Java而使用JNI、C/C++和平台依赖的libraries等。使用Java构建桌面应用更多的是困难和麻烦，比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事。而且没有用Java编写的图片处理应用，没有一个纯粹的Java web浏览器，没有数字音频应用，没有3D建模器，没有矢量图形编辑器，没有先进的光栅编辑器Java今日在桌面端所到达的高度只能满足那些服务器开发者，因为他们只需要在远程服务时使用电脑桌面上的简单界面。过去我们一直说这是因为Java太慢，无法在一个慢的平台上开发出如此复杂的应用。但我们这样说是错的。原因有两点：一，Java从来就没有慢过，即便有些部分曾经慢过，但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升，比如JITs，GCs等。这一点也正是Java语言卓越的地方。二，由于Java平台的天然特性，Java应用总是第一个利用市场上新硬件和新操作系统的应用。一旦JVM被配置到了一个新系统中，几乎不需要任何编辑和调试，Java应用就可以在上面全速运行。比如你在32位的操作系统上开发了一个应用，它就可以全速运行在Windows 7 或者Solaris的64位JVM上。所以所谓的Java太慢根本不能成为Java在桌面端碌碌无为的借口。而且，如果你是一个终端用户，你甚至不需要从网站上重新下载应用，这意味着不仅终端用户和开发者得到了速度提升，甚至应用的执行性能的前边也得到了速度提升。今天，JIT在runtime为本地操作优化代码已经做得很棒了，这意味着你可以挖掘出你运行的硬件的全部的能力，这是一个静态编译语言永远也无法竞争过的性能，只是这个性能如果可以运用到桌面端和游戏领域就好了我们总是说：由于Sun总是一个服务器端公司的原因，Java在桌面端一直没有真正的机会。而Oracle的收购让这种境况看起来不会有什么改变。希望这不要再继续下去，为了Sun、Oracle和Java自身的利益，Oracle内部的知名人士应该提醒公司来让他们知道：如果缺乏了在桌面端的能力和效率，必将影响Java的普及率甚至它在服务器端的占有率。我们一直以来习惯着Sun主要提供服务器端服务，因而想象着未来更多的处理能力还是出现在服务器端，而客户端不过是连接服务器的简单服务。这种情况已被证明是绝对错误的。因为未来的桌面应用将服务、应用与硬件所有的运算能力相结合，大量的数据和解码、声音、图像、视频被开发者处理，而且用并行编程的方式来实现，既保证了丰富的性能又保证了速度。对开发者来说，未来的服务既需要他们在客户端处理也需要在服务器端处理：执行复杂的搜索、图像、视频以及虚拟3D环境需要服务器端的技术，而远程服务如医学分析、远程教育和远程会议等则需要客户端能力。只是令我们感到失望的是历史又一次地重复了，因为至今Java中还没有什么大的动作。Armin Ehrenreich 在回复中说道：说的好，我完全认同。确实迫切需要跨平台的桌面应用技术，而且我不认为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中看到应用提升。Osvaldo Doederlein回复道：我认为JOGL的支持没有那么糟糕，毕竟它是JavaFX Desktop Runtime的一个依赖。实际上，我们可以写一个非JavaFX的小程序，而且不需要请求本地代码的许可性就可以配置。
太慢了！！！！！！！！除了专业用户可以忍受速度慢点，普通用户根本不关心你用什么开发，更不关心你的开发效率，他只会比较你的软件和其他软件哪个快，哪个好用。您比较过WinZip和Java版的zip吗？喜欢用哪个？肯定是快的WinZip。不能以开发人员的个人喜好选择语言，要根据用户和市场决定。
1.java程序不能直接运行，机器上需要安装jre，而jre体积挺大2.swing本身非常优雅，但是缺乏可靠又强大的可视化设计工具，界面设计基本上得靠编码完成，开发效率上不去。3.默认风格不够漂亮，要做漂亮，需要下大功夫。4.与操作系统交互不够方便 。5.运行速度不够快（这应该问题不大）。我就想到这么几个原因
卡丑需要JRE
你找两个Java程序看看效果嘛。特别注意字体渲染效果，那是相当差啊。注意别在 Windows XP 下面。因为 Windows XP 的字体渲染效果也很差，一坨坨的点阵字体，比较不出来。
Java的GUI一开始定位就不是消费者市场， Java Applet的产生是因为当时Web还没有出现一种能够展现丰富动画效果的技术。Flash的后来居上更是加速了Java Applet技术在Web中的消亡。而AWT只是为了支持Java Applet技术存在的。后来Java技术更是被SUN定位在企业开发领域，桌面领域也变得比较小众和专业化。再后来，Swing库更是一个被叫做Amy的女人弄得一团糟....Swing/AWT说实话是比较烂的，要不然IBM不会自己开发一个SWT库替代。有兴趣可以看看这篇博客，
1 Java必须有虚拟机支持。这点很多用户都讨厌，因此开发商也就会权衡。2 Java的程序运行不是原生程序快。这点很多用户都讨厌，因此开发商也就会权衡。3 Swing的设计器IDE远不如微软阵营的设计器IDE生产力高。这点很多程序员都会权衡。4 AWT设计得太失败。5 想要做跨平台的应用程序现在看来无异于天方夜谭。这就是为什么现在重组件流派的SWT大行其道的一个原因。Java GUI阵营本身也是分裂的。6 早期C/C++项目太多了。
因为太丑。参见
写了个小工具，在OSX下复制粘贴的快捷键还是ctrl+c/v，顿时就不想爱了。。
单纯的J2SE确实很难开发桌面应用。
必须对他进行改造，于是有了SWT,JFace等框架（完全颠覆了它原有的AWT、SWING图形库），于是有了Eclipse这样的工具。
要不J2SE开发的应用都有很强的专业性，针对计算机专业的软件，因为计算机专业用户电脑多数安装有JVM。比如ETL工具Kettle，Java代码分析工具Findbugs
我觉得现在如果是写新的Java桌面，JavaFX2.0应该是基于Java的最好选择了.基于Java的RCP 主要有Eclipse Netbeans平台，他们分别依赖于SWT Swing，关于Swing，Java的方向已明确说了，不会再发展Swing，将有JavaFX慢慢取代之，而JavaFX的发展，是否在iPad 智能手机上下功夫，暂且未定。但至少是作为Java 桌面的主力了
我用java+swt+excelsior写了几个java的桌面应用程序,感觉挺好的啊,除了界面不能搞的特别好看(其实用上swt-extension,eclipse.ui.forms,nfa等包做出来的界面还是过得去的), 至于为什么不用RCP,是RCP的插件体系是给工具软件准备的,一般用途的Windows平台下的软件不需要这个特性,所以摒弃RCP,直接swt+ 楼主少说了一个方面,就是安全方面,因为如果需要商业化这个java桌面应用的话,是需要一个编译打包方案的,这个我推荐excelsior,用了这个之后不需要jre了! 目前最成熟的方案.当然编译出来的native exe可以再加上一个安全特性,比如虚拟机加密之类的; 再者,对于界面,虽然我没有仔细研究过,但是相信java和c++做富客户应用比如游戏,差距不是语言本身,而是库
因为桌面程序运行在宿主机器上，所以比如你运行java桌面程序，必然要安装java虚拟机，也就是相当于在操作系统上再加一层抽象，这与直接调用api的桌面程序效率相比，或多或少低一点。因为java主要用于因特网编程和移动开发，如jsp，而这些代码是运行在服务器端的，客户端（浏览器）只需要接收html代码即可，不需要安装java虚拟机，又因为java的跨平台性，语言又比较简单，还有就是背后有orecal这样的大公司支撑，其出身简直就是高富帅，堪称贵族语言。所以java的用武之地太多了，而桌面应用方面，由于微软的垄断，所以java显得有点不太出众，又加之在其他方面做的太好，把人的注意力都吸引了，所以造成了人们感觉java不适合的假象，其实如果你执意要用java开发桌面应用的，我感觉完全没有问题。
有了HTML5 NODEJS 跨平台神马的都不再是问题了
很多学JAVA的人一开始学都听过这句。。于是SE就只被人当作基础过渡算了。。结果JAVA程序员很大部分都聚拢在EE 关注了 希望得到更多更全面的答案
mac上有不少软件是java写的.其他平台上也有.比如ecilpse,netbeans,jedit,永中office,VP UML,jude.用JAVA写的桌面软件也蛮多的.java程序在Eclipse中运行没有问题，打包成.jar文件之后运行后路径出现异常不知道怎么回事？请各位大侠指教
[问题点数：40分，结帖人wudangsanxia]
java程序在Eclipse中运行没有问题，打包成.jar文件之后运行后路径出现异常不知道怎么回事？请各位大侠指教
[问题点数：40分，结帖人wudangsanxia]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
相关帖子推荐：
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。