从语言升级为平台：JAVA老矣，尚能饭否？{转载}
JDK6到JDK7竟然有四年多的跨度，而且新加入的特性，也并不是那么激动人心(相对于社区的期望和动态语言的快速发展)，闭包(Closure)本来是一个万众期待的特性，在经过激烈的争论之后还是被放弃了。
越来越多的人开始担忧JAVA的前途，我觉得，以目前的情况来看，JAVA在JVM上失去Number One的地位是迟早的事情，但我们不要忘了，这个有些老态龙钟的JAVA曾经的辉煌，以及它所背负的兼容性包袱。
java的每一次版本递进，都要考虑对以前版本的语言兼容性、平台兼容性和移植兼容性。
语言兼容性(language compability)，要保证已有的词法、语法在新版本上含义不变;平台兼容性(platform compability)，要保证新版本提供的API(比如java.util/java.io)与已有版本保持一致，原有程序不做改动，可以在新平台上运行，且行为一致;移植兼容性(migration compability)，就是要求原有的程序可以逐步迁移到新的平台，而不是要改相关模块都必须改。以泛型为例，如果有两个不支持泛型的模块，用collection进数据交互，当其中一个模块升级到支持泛型后，是不会对另外一个模块产生影响的。
其实不仅仅是java，任何一个软件系统，随着塞入的功能越来越多，都会逐渐变得臃肿不堪，因为没有哪个架构师有长线预测未来的能力。C的经典，是因为其语言特性的简单和时间稳定性，如果要把泛型、闭包、垃圾回收都加入到C，那么C就不再是C，而是C#。
不过，对于开发人员来讲，我觉得没有必要悲观，也没有必要怀疑java的未来，或者准确的说，不要怀疑JVM的未来，java正在从一种语言(language)，变成一个平台(platform)。Java7的虚拟机对多种动态程序语言增加了支持，也充分说明了sun(或者说oracle)的意图：java不是唯一，java和其它jvm兼容的语言也不是对立的，平台掌握在我手里，那么当然是语言越多越好。
但开发人员也应该做出适当的调整，那就是应该分出一部分精力关注一下JVM的规范和其它语言的特性，既然有更多选择，那么也应该充分发挥各种语言的强项，拿合适的技术做合适的事情。
也许再过若干年，我们会更关注JVM的版本而不是java的版本，java语言，也许就会变成一个参考实现(reference implementation)，就像glassfish之于J2EE;或者，我们可以将java/groovy/scala各种语言真正无缝集成在一个源文件中(就像jsp和html一样)也为未可知。
未来总是美�
相关文档：
tomcat启动web服务的时候总是会有8小时的时差,
琢磨了好久,最简单的办法就是
找到文件夹jdk1.6.0_07\jre\lib\zi\Etc
这里边都是一些时区文件GTM+1,GTM+2,GTM+3....
备份一份Etc
拷贝N份GTM+8文件(中国的时区是GTM+8)
把GMT+8文件名改成GTM+1,GTM+2,GTM+3....
覆盖掉原来的Etc里边的文件
重启tomcat问题解决 ......
import java.awt.*;
import javax.swing.*;
import java.util.Date;
import java.awt.*;
class Time extends JFrame implements Runnable{//实现接口
Thread clockThread;
JLabel jLabel=new JLabel();
public Time()
{
Container con=this.getContentPane() ......
前一阵在公司里使用 jconsle 时一切正常，然而在家中的机器上却出现了标题所示的问题：
jconsole 和 jps 无法显示本地 Java 进程列表。
当时直接利用 -Dcom.sun.management.jmxremote.port=port 启动目标 java 进程，并在 jconsole 中通过 localhost:port 方式成功连接上目标 java 进程。有了这个 work around 之后，对� ......
一、运行class文件
执行带main方法的class文件，命令行为：
java <CLASS文件名>
注意：CLASS文件名不要带文件后缀.class
例如：
java Test
如果执行的class文件是带包的，即在类文件中使用了：
package <包名>
那应该在包的基路径下执行，命令行为：
java <包名>.CLASS文件 ......
