java开发windows桌面程序(java开发平台)
老铁们，大家好，相信还有很多朋友对于java开发windows桌面程序和java开发平台的相关问题不太懂，没关系，今天就由我来为大家分享分享java开发windows桌面程序以及java开发平台的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！
Java适合开发桌面应用程序吗
对于一门语言来说没有适合不适合的，只有需求和实际相结合的结果。
java不擅长做桌面级应用原因有以下几点：
java swing配置的按钮相对来说不太美观，而且优化，排版设计都没有C#的好，甚至界面设计都要考代码段来写，不够直观，虽然有可拖动构建按钮的界面但是用很不方便。
桌面级的应用中有些直接调用了windows的底层，对于java来说先要通过JVM然后再去windows对于数据量大的，效率要求严格的，多一层可能会对效率造成影响。
这也是最致命的，java运行需要java环境。你可以保证服务器上装好java，但你不能强制要求使用用户去装，当然如果你愿意把原来只有几个MB的程序打包成包含有200多MB J2EE环境的大应用也是可以实现的，但接着就产生了一个问题，如果是一个简单的计算器程序，你是愿意去用一个只有几KB的C#程序，还是用一个200多MB的java程序。
java 可以写桌面程序吗
Java可以写桌面程序。以下是关于Java编写桌面程序的一些关键点：
使用Java Swing：
Java提供了Swing库，这是一个用于创建图形用户界面的强大工具包。通过Swing，开发者可以设计各种桌面应用程序的UI组件，如按钮、文本框、菜单等。开发流程：
使用Java编写桌面程序通常涉及创建主窗口、添加UI组件、设置事件监听器等步骤。Swing库提供了丰富的API，使得开发者可以灵活地定制应用程序的外观和行为。与C#的比较：
虽然Java Swing可以用于创建桌面程序，但与C#的桌面开发相比，Java在某些方面可能显得更为繁琐。这主要是因为C#拥有更紧密地与Windows操作系统集成的优势，以及Visual Studio等IDE提供的强大开发支持。适用场景：
Java桌面程序适用于跨平台需求，因为Java具有“一次编写，到处运行”的特性。然而，在特定于Windows平台的应用场景中，C#可能会提供更直接和高效的开发体验。综上所述，Java确实可以用于编写桌面程序，特别是当需要跨平台兼容性时。然而，开发者在选择技术栈时应考虑具体的应用需求和目标平台。
为什么很多人说 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在一旁已经恭候多时了。
OK，本文到此结束，希望对大家有所帮助。