注定了Java客户端不利于推向市场

　　关于JVM的执行效率

　　Java 推出的前几年，人们有不同的看法，解释字节码肯定比全速运行机器码慢很多，牺牲性能换来跨平台的优势是否值得?

　　然而，JVM 有一个选项，可以将使用最频繁的字节码翻译成机器码并保存，这一过程被称为即时编译。这种方式确实很有效，致使微软的 .NET 平台也使用了虚拟机。

　　现在的及时编译器已经相当出色，甚至成了传统编译器的竞争对手，某些情况下甚至超过了传统编译器，原因是JVM可以监控运行时信息。例如，即时编译器可以监控使用频率高的代码并进行优化，可以消除函数调用(即“内嵌”)。

　　但是，Java 毕竟有一些C/C++没有的额外的开销，关键应用程序速度较慢。比如Java采用了与平台无关的绘图方式，GUI程序(客户端程序)执行要慢;虚拟机启动也需要时间。

　　客户端市场的折戟

　　Java 的GUI库称不上出色，界面不算友好，大部分用户不太习惯;Java 的客户端资源消耗也比较大，大数据量的应用和功能复杂的应用性能堪忧。

　　更加不能接受的是，微软因自身利益和SUN分家后，Windows 便不再预装JVM了，用户安装你的程序之前，必须要安装JVM并正确设置，你可以要求普通用户安装你的软件，但是你能期望他了解JVM的有关知识并正确安装设置吗?

　　虽然你可以将JVM集成在你的程序中，自动安装并设置，不让用户干预，但是你希望附带一个比你的程序还要大好多的JVM吗?一个软件这样做或许可以接受，成千上万个软件都这样做，那用户要安装多少个JVM?磁盘空间要浪费多少?

　　所以，直接投放市场的面向普通用户的客户端程序，用Java开发的很少，大部分Java开发的客户端是给企业内部员工使用，员工领到电脑时，技术部已经给配置好了。如果你希望从事客户端开发，建议学习 C/C++ 和 .NET，它们在Window客户端开发方面有较大的优势。

　　种种原因，注定了Java客户端不利于推向市场，让普通用户接受。不过话又说回来，客户端开发也不是Java的初衷，Java最初是面向嵌入式的，却随着互联网的兴起而快速成长，在Web开发上大显身手。