以下讨论只针对pc端和移动端。
java最大的优势真的在于跨平台吗？以前是，但现在已经不是了。
有跨平台需求的仅仅是客户端应用，而不是服务端。例如桌面应用，你的客户可能是windows用户，也可能是linux用户，这时候如果不想多投入成本对各个平台进行适配，那么java所谓的”write once, run everywhere”就显得异常光彩。然而今天，整个软件世界都在向b/s应用倾倒(嵌入式除外)，即使要做客户端跨平台，qt等第三方框架远远比swing更强大，java在桌面应用领域基本被淘汰已经是不争的事实了，而当初java引以为豪的applet也早已销声匿迹。如果说客户端java还有一点优秀的话，那只有android了。android最初确实靠jvm屏蔽了不同硬件设备之间的区别并取得了巨大的成功，但在今天，android l中art模式的出现也即将颠覆这一情况，况且google还可能会想用自家的go语言取代java成为android平台的第一语言。所以在客户端，java几乎完败。
服务端应用不需要跨平台。做一个web服务器，我想没有哪家公司今天用linux，下个月就换windows吧？如果仅仅是更换linux发行版，如从debian到fedora，本质上讲其linux内核是不变的，因此像c++这样纯编译类型的语言已经没什么问题。如果做游戏服务器，我想几乎都会选择linux而不是win平台。java的跨平台优势的实用性其实已经被大大弱化了，可以说在实际应用中并不明显，在一般情况下几乎感知不出java还能跨平台这个特性。作为三大商用jvm之一的jrockets是只有编译器的jvm，即应用启动时会将字节码全部编译为本地机器码，这其实就很大程度上摒弃了跨平台，而追求性能。
今天，java最大的优势在于其庞大而完善的生态系统。 一门编程语言是否能流行，主要是由其生态系统决定的。java生态系统的完善性主要体现在以下几个方面：
java拥有世界上数量最多的程序员。你说他们是农民也好，但数量放在那里，最明显的效果就是公司招人的时候会比较容易地招到java程序员。试想如果你想要做一套软件，你有一个很棒的技术方案需要用c++，scala或ruby等语言实现，但招不到足够的人手，那么计划多半泡汤。这时候你的应用java也能做到，并且很轻松就能招到足够的人，那么你选择java的可能性就要大一些。
java拥有大量的第三方类库。假如你想解析html，用c/c++这类语言恐怕多半只能自己编写解析算法库了，而如果是java，你可以非常轻松地在github上找到jsoup，使用maven导入依赖后分分钟就搞定html。为此还有一句讽刺java的话是：“我们不生产代码，我们只是github的搬运工。”这句话从字面上看是很有道理的，但却忽略了对软件生产效率的提升所带来的巨大价值。对于软件的开发，公司的唯一成本其实就是“人头费”，每减少一个月开发时间，就能帮助公司节省几十万几千万的研发成本。
java拥有功能强大的ide。 eclipse，通过插件几乎可以满足你开发的任何需求。它虽然有些慢，但你可以通过jvm调优来提高程序的流畅度，千万不要使用默认的jvm参数。不过，intellij idea已经完全超越eclipse了，idea的智能程度几乎可以媲美win平台下的vs。我是那类离了vim就活不下去的人，在这两款ide中都有vim插件从而让我愉快地存活下去。
java拥有很多杀手级应用。 不必多说，spring, struts, hibernate, hadoop, tomcat, jboss等等。
java的语法特性很少。对，这也是一项优点。c++相比c添加了大量特性，学起来费事不说，用起来还会降低代码可读性，其实是费了工夫不讨好。当今世界对编程语言的要求是语法简单，代码可读，对性能已经是退而求其次了，因此才诞生了python, ruby这样的编程语言。有很多人批评java语法写起来很臃肿，我承认这一点，但事实是，编程语言从来都不是因为语法臃肿而被淘汰的，决定其生死的是生态系统。对于批评者，引用知乎的一句话：”动态类型一时爽，代码重构火葬场”
java的性能已经足够高了。 sun/oracle的hotspot jvm内置的jit编译器在运行时对字节码已经做出了非常大的优化努力，服务端应用启动后对jvm进行足够的”预热”，并给出合理的启动参数即可。如果不是对性能十分敏感的系统类应用，java已经足够快了。有一种简单可行的方法可以形象地看出这点，在jvm启动参数中添加+xx:printcompilation可以看到jit编译器的忙碌。当今世界对软件的需求量越来越大，在性能可接受的情况下，开发效率才是第一位的，这也是python这类动态脚本语言流行的主要原因