![](https://iknow-base.cdn.bcebos.com/lxb/notice.png)
为什么很多人说 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不适合写桌面应用”的说法有一定道理,论调的主要背景是供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更为熟悉
比如,一些工具的管理界面,很符合
展开全部
没有什么合不合适的,选定那种语言写桌面应用一般都是看OS的,java在跨平台方面其实是有优势的。就是运行是消耗的内存较多。jdk6之后jvm的运行速度还算不错。其实很多工具类别的软件都是用java编写的。Java的桌面程序并不少,其中最为知名的莫过于Eclipse,java游戏中最有名的就是“我的世界”MC了。在Linux和Mac下,Java程序的比例远高于Windows下。只不过在windows环境下java编写的桌面应用一般没有那么多酷炫效果。
“Java不适合写桌面应用”的说法有一定道理,论调的主要背景是供Windows下使用的企业桌面应用的开发。由于一些历史和定位的原因,对于这种GUI程序的需求,Java的优势不明显,劣势比较明显。因为java必须在jvm上运行,而对于一般人来说安装jre也是一个不小的负担,毕竟不容版本的jre混装容易出现问题。
这事还得从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在一旁已经恭候多时了。
以下是知乎原文链接:
http://www.zhihu.com/question/19711713
“Java不适合写桌面应用”的说法有一定道理,论调的主要背景是供Windows下使用的企业桌面应用的开发。由于一些历史和定位的原因,对于这种GUI程序的需求,Java的优势不明显,劣势比较明显。因为java必须在jvm上运行,而对于一般人来说安装jre也是一个不小的负担,毕竟不容版本的jre混装容易出现问题。
这事还得从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在一旁已经恭候多时了。
以下是知乎原文链接:
http://www.zhihu.com/question/19711713
本回答被提问者采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
2018-07-30 · 百度知道合伙人官方认证企业
兄弟连教育成立于2006年,11年来专注IT职业教育,是国内专业的IT技术培训学校。2016年成功挂牌新三板(股票代码:839467)市值过亿。开设专注程序员培训专注php、Java、UI、云计算、Python、HTML5、
向TA提问
关注
![](https://wyw-base.cdn.bcebos.com/pc-content/follow.gif)
展开全部
java本来就不是桌面编程,Java主要针对网页开发的,B/S结构(B:Browser浏览器 S;server服务器)
只是一些人这样认为的,因为Java在服务器端应用的太多,表现也太好,但是Java桌面应用也不少的,只不过主要集中在Linux平台,所以很多人没有注意到而已,比如OWASP ZAP(一个非常优秀的Web漏洞检测工具)、Burpsuite(另一个Web漏洞发掘工具)、...//兄弟 连Java战 狼班
第一,java对于画面展示上是很丑的 第二,java写桌面应用会显得很笨重,先不说java环境,就java运行占用内存你也可想而知~
当初sun好高骛远了,想用awt来一个一次开发,各系统均可用,结果玩崩了,后来的swing基本上是对awt的封装和补充,但仍有缺陷,并且已经错失良机了
因为现在C#或者delphi在编写桌面应用的时候,界面很容易就处理好了。 而java在处理界面方面比C#或者delphi要累很多。 在编译器方面,vs或者delphi对界面方面支持很方便,拖动控件到位置,改下参数就行。但是java在这块就全部需要用代码去处理。
也不是不适合吧,只是有更简单的开发语言, 就没必要去用java写桌面应用了 其实像eclipse idea 这种开发工具也是用java开发的, 大形应用 可以跨平台所以用java语言开发, window macos linux都可以用的
只是一些人这样认为的,因为Java在服务器端应用的太多,表现也太好,但是Java桌面应用也不少的,只不过主要集中在Linux平台,所以很多人没有注意到而已,比如OWASP ZAP(一个非常优秀的Web漏洞检测工具)、Burpsuite(另一个Web漏洞发掘工具)、...//兄弟 连Java战 狼班
第一,java对于画面展示上是很丑的 第二,java写桌面应用会显得很笨重,先不说java环境,就java运行占用内存你也可想而知~
当初sun好高骛远了,想用awt来一个一次开发,各系统均可用,结果玩崩了,后来的swing基本上是对awt的封装和补充,但仍有缺陷,并且已经错失良机了
因为现在C#或者delphi在编写桌面应用的时候,界面很容易就处理好了。 而java在处理界面方面比C#或者delphi要累很多。 在编译器方面,vs或者delphi对界面方面支持很方便,拖动控件到位置,改下参数就行。但是java在这块就全部需要用代码去处理。
也不是不适合吧,只是有更简单的开发语言, 就没必要去用java写桌面应用了 其实像eclipse idea 这种开发工具也是用java开发的, 大形应用 可以跨平台所以用java语言开发, window macos linux都可以用的
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
2018-07-06 · 百度知道合伙人官方认证企业
1【专注:Python+人工智能|Java大数据|HTML5培训】 2【免费提供名师直播课堂、公开课及视频教程】 3【地址:北京市昌平区三旗百汇物美大卖场2层,微信公众号:yuzhitc】
向TA提问
关注
![](https://wyw-base.cdn.bcebos.com/pc-content/follow.gif)
展开全部
如果要编写出特别好的桌面应用,只有C/C++,因为操作系统就是使用C/C++编写的,其他任何语言都不适合编写桌面应用,而具体到java,eclipse就是使用java编写的,效果很差吗?不差,其实eclipse很棒,但是为什么说java不适合编写桌面应用,一个原因自带的库不好,特别是JDK6之前,自带的库特别烂,学习难度和曲线特别高。 一个原因是打包之后应用比用C/C++编写的大很多,至少需要带一个jre。 另外一个原因是java在web端很火,但是在桌面应用却很冷,很难招到合适的人。 但是java绝对不是不适合编写桌面应用,而是要看你编写什么类型的桌面应用,公司的人才储备如何,不过说句实话,能够有这样的人才储备,为什么不用C/C++呢?至少你不用去优化JVM,JVM你优化得再好,能好过直接优化C/C++代码。 所以 Java 不适合编写桌面应用的原因是: 要学习java的桌面应用是有难度和曲线的; 所以导致桌面应用方面的java人才相比web少很多; 所以又导致公司不愿意花差不多跟C/C++一样的成本来投入java的桌面应用开发
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
如果要编写出特别好的桌面应用,只有C/C++,因为操作系统就是使用C/C++编写的,其他任何语言都不适合编写桌面应用,而具体到java,eclipse就是使用java编写的,效果很差吗?不差,其实eclipse很棒,但是为什么说java不适合编写桌面应用,一个原因自带的库不好,特别是JDK6之前,自带的库特别烂,学习难度和曲线特别高。 一个原因是打包之后应用比用C/C++编写的大很多,至少需要带一个jre。 另外一个原因是java在web端很火,但是在桌面应用却很冷,很难招到合适的人。 但是java绝对不是不适合编写桌面应用,而是要看你编写什么类型的桌面应用,公司的人才储备如何,不过说句实话,能够有这样的人才储备,为什么不用C/C++呢?至少你不用去优化JVM,JVM你优化得再好,能好过直接优化C/C++代码。 所以 Java 不适合编写桌面应用的原因是: 要学习java的桌面应用是有难度和曲线的; 所以导致桌面应用方面的java人才相比web少很多; 所以又导致公司不愿意花差不多跟C/C++一样的成本来投入java的桌面应用开发
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询