编程语言就像星星一样，没有一种语言可以永远星光闪耀，Java也不例外。虽然Java语言如此，但Java 平台却另当别论。今天即使Java语言出现下降的趋势，Java平台也仍比任何时候都增长得快。
一次我在与DZone其他技术人员讨论技术问题的时候，我无意间表达了Java正处在下滑趋势的说法。这是有许多前车之鉴的，强大的C在被C++和后来的 Java挤下神坛之前也不过持续红火了20年多的时间。Java刚进入第二个十年，我们却已经看到了岁月沧桑和用户不满的痕迹。
那么Java会灭亡吗（Will Java Die？）
就在这时，Rick Ross告诉我“Java并不仅是语言，是平台。”他说的很正确，Java远不单是语法定义的语言。我们已经看到很多语言扩展或者专门运行在JVM上。 JRuby和Scala 的成就已表明即使没有Java语法甚至没有Java库，平台仍可继续生存。
在我看来Java今天达到的高度前所未有，然而我们看到Java平台的流行更在语言之上。所以Java的情形并不同于我们看到的其他语言的下场。那么是否Java自身会衰落却依然在平台中对其他语言扮演支持角色呢？
这个问题我只能说我也不知道。反正我会支持Java，即使地球上只有三个人用它，我也是这三个人中的一个。在我看来，Java避免迷失在时间长河中的唯一方法就是，置于运行在JVM上的一种语言或多种语言中，而且能够与Java的库互操作。
这里一篇关于语言流行度无偏见评测的文章，本文是对客观实际评测的显示：
Java是最流行的语言，受欢迎度为20.8％；
占据第二位的是去年涨幅比Java少3.6％的C语言，现占13.9％；
Java的绝对人气比去年上升1.7％；
Ruby的受欢迎度是2.3％，排名11；
Python是去年增幅最大的，增长2.0％，居第六位；
Python今年第一次超过了排在前面很长时间的对手Perl；
Visual Basic（现在是第三代）在增幅上排第二位，Java排第三位；
Ruby的人气和去年相比下降了0.17％；
Perl，现排第七位，受欢迎度仍然是Ruby的一倍多；
C语言以1.89％跌落谷底；
C＋＋以1.7％的幅度在下降幅度中排第二位；
C＋＋下滑至第五位，因为它以前排在Visual Basic和PHP之前；
PHP比去年增长了1.25％；
Java比VB和C＃结合的AKA.NET更受欢迎，尽管AKA.NET占15.7％；
Delphi以3.3％的迅猛增长超过Javascript和Ruby；
Lua从先前46名升至第十六位；
Groovy排名31；
如果这些数字让你感到吃惊，或许你在阅读Blogs时会持更多的怀疑态度。
还有的人提出了Java语言的10大问题！！
1、缺少闭包（closure）：我想这个不需要解释了。函数式编程已经存在几十年了，但最近几年，它们获得了越来越多的关注，最主要的原因，是它可以自然地编写并行程序。我部分的同意Joshua Bloch强调在Java中引入闭包的问题需要再想一想（BGGA提议的方式真的很糟），至少闭包的缺失，使得在Java中做任何真正的函数式编程都是不可能的。
2、缺少一等函数：这个问题与前一个有些关联，但我认为它更糟糕。在Java里，要达到类似效果的唯一方式，是使用著名的、丑陋悲惨的单方法匿名内部类，但这看上去的确是一个拙劣的方法。甚至在C#中，也通过代理机制，提供了一个更好的实现。
3、原生类型（Primitive types）：如果在Java中一切皆对象，那是多么完美啊，但他们偏偏不这样设计。因而，这一点导致了一些问题，比如，不能把一个int放到集合（Collection）里，这个在Java5中 通过自动装箱特性得到了解决（下面会提到）。它也造成了传值与传引用上的困扰，原生类型数据是通过值传给方法的（复制一份拷贝，然后传给函数），而真正的 对象是通过传递（译注：其实是复制对象地址再传递，因此应该也是传值方式，只是由于函数内部可通过这个对象地址访问对象，因此效果上类似传引用）。
4、自动装箱（Autoboxing）和自动拆箱（autounboxing）：这个特性是为了解决因原生类型的存在所导致的问题，在Java5引入的。它允许静默地转换原生类型到相应的对象，但这常常导致其它的问题。比如Integer可以为null，但int不能，因此这时JVM只能抛出一个难以调试的空指针异常（NullPointerException）。此外，它还可能导致其它奇怪的行为，就像下面的例子，我们就很难理解，变量test为什么是false：
Integer a = new Integer(1024);
Integer b = new Integer(1024);
boolean test = a < b || a == b || a > b;
5、缺少范型具类化：范型是Java5引入的一个很酷的特征，但是为了保持与旧版本Java的兼容性，导致缺失某些重要的特性，尤其是不能在运行时反省范型的类型。例如，你有一个方法，接受List参数，如果传进来一个List
List
6、不可避免的范型警告：你有发现过自己陷入不可能去掉的关于范型的警告么？如果你像我一样大量使用范型，我打赌你碰到过。事实上，是这个问题的规模化症状，让他们认为需要引入一个特定的注解 (@SuppressWarnings("unchecked")) 来处理这种情况，我觉得，范型应该可以被设计的更好。
7、不能传void给方法调用：我得承认，这种给方法传递void的需求，乍一看有些怪异。我喜欢DSL，当我实现自己的DSL库（lambdaj）的一个特定特性时，我不得不需要一个方法声明成这样的签名：void doSomething(Object parameter)，这里为这个方法传进来的参数parameter，是另一个方法调用的结果，它唯一的目的，是注册调用（的对象）自身，以可以在以后执行它。让我吃惊的是，即使println方法返回void，看上去也并没有一个好理由，不允许我把代码写成这样：
doSomething(System.out.println("test"));
8、没有原生的代理机制：代理是一种非常有效和应用广泛的模式，但Java提供的代理机制，只针对接口，而不是具体类。这是为什么象cblib这样提供这种机制的库，被如此多的主流框架，如Spring和Hibernate，采用的原因。此外，由于cglib通过运行时创建被代理类的子类来实现的，因此这些种方式有一个众所周知的限制——不能代理final类，比如String。
9、差劲的switch...case语句：Java规定，switch...case只能选择int和enum（Java5开始）。这一点如果跟更现代的语言如Scala相比，看起来简直太弱了。
10、受检查异常（checked exception）：类似原生类型，受检查异常也已经成为Java的一个罪孽之源。它迫使程序员必须做下面两件极其糟糕讨厌的事情中的一个：让你的代码里充斥大量的、糟糕难读的、容易出错的try...catch语句，而这样做的最大意义，只是将捕获的异常，包装成运行时异常，然后再重新抛出；或者是让大量的抛出声明子句污染你的API，让接口缺少灵活性和可扩展性。
真正的问题是，这里我提到的这几大主要问题，唯一的解决办法，是要做一个痛苦的决择，定义一套新的语言规范，放下当前版本的向后兼容性。我猜他们永远也不会这么做，虽然我相信，如果编写一个能够自动转换旧Java源码的程序，让它们与假设的新版本兼容，并不是很困难。最后，这就是我决定开始寻找一个更好的JVM兼容语言的原因。