Java桌面应用程序

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体积挺大

(反驳:其实JRE不需要单独安装,直接打包就行.)
(反驳:JRE并不大)

缺点二:
JVM一般启动时规定内存占用等参数，因此对系统资源浪费较大，

(反驳: 至于说规定内存参数,也不是啥问题.毕竟客户端所需要的资源比较小.)

对于单CPU（尽管目前一般都是双核甚至4核）以及3G内存的32位个人电脑来说，
仍然效率不如基于操作系统API的本地应用

(反驳: 至于说效率,JAVA在JIT编译之后未必比C++/C慢多少.
而且在client模式下运行的JIT临界值很小,解释执行很快会变成本地代码.)

运行速度慢，初次启动时间慢

缺点三:
和大多数现代语言相比，Java语言语法仍然比较繁琐，开发成本比较高
除传统桌面应用外，目前RIA桌面应用也比较流行，
但无论是
Java还是JavaFX的竞争力仍然不及
Adobe系的Flash/Flex/AIR等，
恐怕未来还要被HTML5/CSS3/Javascript进一步压制。

(同意:
至于说ADOBE AIR,跟JAVA也是一样的模式.
只是JAVA SWING想写出很好的程序
需要对设计模式和SWING常用的设计手法了解很多
但是似乎AIR简化很多.
而且就IDE来说,似乎AIR比SWING也强很多.
至于说HTML5之流,小应用可以吧,大应用不看好
)

缺点四:
swing本身非常优雅，但是缺乏可靠又强大的可视化设计工具，界面设计基本上得靠编码完成，开发效率上不去。
默认风格不够漂亮，要做漂亮，需要下大功夫。
与操作系统交互不够方便 。

(反驳:各种IDE都有swing的可视化插件,开发效率要比C++快太多太多。比如:windowbuilder)

---

描述现状

单纯的J2SE确实很难开发桌面应用。
必须对它进行改造，
于是有了SWT,JFace等框架
（完全颠覆了它原有的AWT、SWING图形库），
于是有了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时代，心里特别添堵。

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

---

发展历史 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这方面的生态较为薄弱。

---

发展历史 JavaFX2.0

我觉得现在如果是写新的Java桌面，
JavaFX2.0应该是基于Java的最好选择了.
基于Java的RCP( Rich Client or Rich Ajax Applications (RCP+RAP))
主要有Eclipse Netbeans平台，他们分别依赖于SWT Swing，
关于Swing，Java的方向已明确说了，不会再发展Swing，将有JavaFX慢慢取代之，
而JavaFX的发展，是否在iPad 智能手机上下功夫，暂且未定。
但至少是作为Java 桌面的主力了

Java在桌面应用程序方面表现得比较好的框架还得说RCP，
Rich Client Platform，富客户端平台，
RCP提供了丰富的界面控件，
这使得基于Java开发桌面应用也变得容易了很多，
偶去年本科的毕业设计就是用RCP开发了个桌面软件-数字证书管理工具，
有兴趣的可以到csdn下来看看
http://download.csdn.net/detail/dongshilongdsl/3301297

---

发展历史

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做桌面开发更多的是面向功能开发，
在用户交互方面确实是它的短板。

钟声 的答案比较全面了。不过从 @陈昊 的并非回答的回答说开：
很多学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 这位贱人是什么仁什么智啊。

我想Adobe的客户端程序应该主要是用C++写的，那么Adobe的服务器端程序呢，会使用Java吗？
一路失败然后变成世界第一的语言……
失败是商业失败。一路赔钱还投巨资改进白送，社区成功也不奇怪。
ams就是java的，以前叫fms

桌面程序不是现在软件的主流。
你可以观察一下，java流行之后，
如果需要使用桌面程序，基本上还是会考虑java的。
至于java的性能问题。
我觉得这个问题在现在的计算机上，不是很大的问题。
java写桌面程序的优势是它的多线程支持，不足是缺乏足够可用的控件，很多东西需要自己写。
swing的继承体系挺复杂的，理解起来需要一定的时间。
JavaFX能够好一点但是也有控件不够丰富的问题。

环境~·环境啦~~~
java原生的运行环境应是JRE，
虽然说可以转成exe，
但是中间还是多了许多其他不必要的环节
（因为，java主旨跨平台，既然功能多了代价也的高了。。 这和是时间常理 ，大家都懂。。。）， C/C++直接就是和操作系统一直的开发语言，速度和适应性肯定比JAVA要好。。。。。。。。。。。

卡
丑
需要JRE

我用
java+swt+excelsior
写了几个java的桌面应用程序,
感觉挺好的啊,
除了界面不能搞的特别好看
(其实用上swt-extension,eclipse.ui.forms,nfa等包做出来的界面还是过得去的),
至于为什么不用RCP,
是RCP的插件体系是给工具软件准备的,
一般用途的Windows平台下的软件不需要这个特性,
所以摒弃RCP,
直接swt+jface;
楼主少说了一个方面,就是安全方面,
因为如果需要商业化这个java桌面应用的话,
是需要一个编译打包方案的,
这个我推荐excelsior,
用了这个之后不需要jre了!
目前最成熟的方案.当然编译出来的native exe可以再加上一个安全特性,
比如虚拟机加密之类的;
再者,对于界面,虽然我没有仔细研究过,
但是相信java和c++做富客户应用比如游戏,差距不是语言本身,而是库

1 Java必须有虚拟机支持。这点很多用户都讨厌，因此开发商也就会权衡。
2 Java的程序运行不是原生程序快。这点很多用户都讨厌，因此开发商也就会权衡。
3 Swing的设计器IDE远不如微软阵营的设计器IDE生产力高。这点很多程序员都会权衡。
4 AWT设计得太失败。
5 想要做跨平台的应用程序现在看来无异于天方夜谭。这就是为什么现在重组件流派的SWT大行其道的一个原因。Java GUI阵营本身也是分裂的。
6 早期C/C++项目太多了。

你找两个Java程序看看效果嘛。
特别注意字体渲染效果，那是相当差啊。
注意别在 Windows XP 下面。
因为 Windows XP 的字体渲染效果也很差，一坨坨的点阵字体，比较不出来。

因为更加适合写服务端

在NetBeans Platform平台上看到很多成功的案例。。。。
我看到Platform Showcase 这里面列表的时候惊吓了，
其实NetBeans Platform很强大，很多国外软件都在用。
而且用得很好。
从以前做系统集成的角度来看，只是国内的Windows平台占有率太高，
于是随便做个是软件，都要嵌入Word，嵌入Office，要用OLE，要用ActiveX。
还要print打印机支持，还要加密狗之类的支持, 还要嵌入浏览器之类的。
再一点，还需要很多windows系统的底层api调用，
弄个什么客户端软件，都要防着会不会被360滥杀， 随便写个客户端，
也要写注册表，改注册表什么东西之类。
这些都不是java擅长的地方。
所以，哎，没办法。

java桌面在理工科各行业软件里面占有很大比例

Desktop Java不能广泛流行的最主要原因是，跨平台的GUI方案已经有Web了。
假如没有Web，大多数Enterprise Application会采用Desktop Java开发的

有了HTML5 NODEJS 跨平台神马的都不再是问题了

就像你不会用.net去开发安卓，虽然可以这样干

这个标题有些歧义可能是导致争执的一个原因。
在我看来Java真的不擅长写GUI应用。
对于GUI开发我之前只在21世纪初使用过VisualBasic。
2015年底由于有个想法想要用Java开发所以开始使用Java以及Swing，
到现在对于Java很满意但对于Swing很吐槽。

（首先说明，我认为Java除了“简单的”跨平台，
另一个很大好处是其实它是一个平台，
上面有很多组件和工具。
这些组件和工具由于其跨平台特性多年来不断积累已经使Java远远超出了传统的“开发语言”的范畴；
所以用C++和Java进行比较本身就有些问题。
C++ 是程序语言一级的东西，
而Java是开发平台一级的东西；
而这也是我在离开大学15年后重新开始学习写程序选择Java平台的一个主要原因：
Java平台完整实现了WebSocket）
第一次NetBeans里面Swing Designer傻眼了。
里面的东西非常强的面向代码，
需要了解MVC模型，
非线程安全每次都要使用invokeLater/invokeAndWait来插入，
Worker等等这些都罢了，
毕竟边用边学也就知道了。
但是这个GUI Designer真的不得不吐槽。
一拖放就不知道是什么结果了；
无法使用箭头移动空间布局；
修改一个控件的名字导航栏里的控件树就会折叠，
图形界面也退回到JFrame主界面；
害你不得不重复的展开树。
更可笑的，无法手工该代码，
所以想改个名什么的无法点击”refactor”，
只有不断的点击鼠标;…就这种水平能进行精确空间控制才来鬼了。
今天下午试用了一把FX，
第一个需要吐槽的就是官方主页上找不到scene builder，只好谷了一个。
一上来在拖出一个tab放在tab pane里直接挂掉；
真是郁闷呀。拉里埃里森(Larry Ellison)本里本就没什么技术情结，
Sun的那些开源项目统统砍掉，
James Gosling辞职 ,
FX在Oracle时代停滞不前，总之是吧Sun的那些东西拆的七零八落了。

可以编写的
而且可以做的比qt还漂亮
而且做复杂的Java GUI开发
也不需要使用到复杂的类库
有一本书 ,
里面有很多技巧关于如何实现漂亮而且实用的gui效果
这本书大概07年就出来了
作者很厉害
就是 chet haase 和romain guy
他们这这本书时还是Swing工作组
后来是Android的核心ui框架的开发者
每年的google io 大会都有他们发言
这本书里面提到的很多概念都很厉害
技巧也很多
尤其是关于动画的实现技巧
特别好 Java可以实现很好的ui效果
Eclipse intellijidea都是基于Java实现的高级产品
关键还有Android 也是用Java实现的 不也是很好吗

java的优势在于处理网络问题，
但是也提供swing以及awt组件库，
所以使用java来开发桌面应用是可行的，
但是为什么没有大规模的应用，
确实因为效率低，
在这方面我最有感触，
因为我用java写过简单的桌面应用，
下面是实现的效果：
给我的感觉，
java写出的代码好丑，
主要是Eclipse IDE用户体验真心很差，打开超慢无比。
所以综合以上观点，还是学前端才是王道

项目完成后，C#程序员开开心心地发布了，享受着程序流通的喜悦
而Java程序员在干什么呢?
他在网络上搜索:
1.如何把JAR打包成EXE
2.如何说服玩家/用户安装JRE
3.如何把JRE精简后打包入住
4.如何让杀毒软件不要误报我的JAVA程序
5.如何教用户设置本地的JRE路径
6.不兼容最新版本JRE怎么办

我觉得语言没有可比性，
可比的只是现有的条件 。
我是做java开发的，在pc界面开发方面，.net有很大的优势，
但在做业务处理时，java有很多开源的东西可以用。
所以两都有擅长。
如果有现成的.net人员，那.net开发最容易，哪怕是业务量再大也是可以处理的。
如果有现成的java人员，想把界面做成什么样都可以，
请看weblaf与javafx两个UI框架。
如果有html人员，
想把界面怎么搞就怎么搞，
但请不要给他太复杂的业务。

minecraft,
spiral knightsm
$还掏了一大笔钱去买minecraft
还有前面无数小白说的跨平台问题
这个native compiling不就可以了嘛，
早就解决了还搜，搜什么哟，
自己无知就当别人都傻
现在也早不是什么微软占主导的时候了国外这些年macosx那叫一个风起云涌，
君不见硅谷一搞seminar，清一色macbook pro嘛？
你不会以为上面跑的都是盗版的windows吧？
只有国内姑娘才这么干说这些没有用，你觉得可以就动手去做，
你不动手做，给自己找无数的理由这个不适合，那个不合适，再好工具都是扯

确实不适合，但不是不能。
最根本的原因在于同样的收获，
选择Java会付出更高的成本。
而且，
很多UI效果Java根本没有任何现成的解决方案！
所以，除非有某些特殊情况（譬如有一大帮子Java工程师且对UI没有任何要求），
一般人不会选择Java做桌面应用。