TOTO.net

KEYWORDS: Java VM, Performance, Static compiler, Dynamic compiler, HotSpot, JIT, Sun Microsystem, BEA

Today, I have found some meterial about the core Java technology. most of them are discussing on the performance about Java VM, some top technologies are discussed like HotSpot, JIT etc.

Maybe the following links are valuable for understanding these key topics.

1. A glance of JVM history (Written by Jim Huang). In this article, you will be able to find out�the footprints of�JVM, how the JVM is developed in the past 6 or 7 years.�A lot of links are mentioned in this article, and I believe most of them are valuable for us.

2. About JRockit which wins the JDJ reader's choice award for "the best JVM of Year 2003" (Written by Joakim Dahlstedt, CTO of Java Runtime Products Group at BEA). This article aims to let us consider the system-level performance, and Joakim Dahlstedt believed that, Java VM will perform a better benchmark than C on a large scale system, because Intel IA-64 model CPU used a new algorithm instead of Out-of-Order, and the CPU will evaluate the work flow of a piece of spot. And I was persuaded…

3. Java HotSpot�means performance (Said by Sun Microsystem). Here the engineers of Sun Microsystem discussed the architecture and the basic concept of HotSopt in their WhitePaper.

Here is a START, I will not stop!

看了一下MSDN上关于C#2.0中的泛型的介绍.发现确实.NET与Java都实现了基于虚拟机的程序语言中的泛型.但是.NET的支持更加好,.NET是从CLR上直接支持了泛型,也就是说微软直接在bytecode上做文章,使得虚拟机本身就支持了泛型,这样带来的一个好处是能更加广泛的支持泛型,由此可以断定,未来支持.NET平台上的语言都会支持泛型,这样可以扩大.NET的影响力,拉拢更多的用其他语言基于.NET的开发人员.从实现的泛型功能上也比Java更多.

Java的泛型原来只是对编译器的修改,最终的结果是从编译器的层次上实现了泛型,并且可以让使用泛型的程序编译过后支持1.5版本以前的JDK.这样做似乎是与C#的泛型有了本质的区别,因为不能从虚拟机的层次上支持泛型,那么就不能利用虚拟机对内存,metadata上的支持.于是很多的开发人员开始批评Java的泛型.对于Java的泛型还需要更多的研究.

JDK1.5.0 已经更名为JDK5.0 由此可以揣测,这次更名是为了压过C#2.0的风头,微软从2001年开始正式推出.NET以后,短短的3年时间,不仅版本直追Java,而且功能上丝毫不逊于Java,这已经让Sun头疼不已.但是从另外一个角度看,Sun和微软已经达成协议,这中间关于Java和.NET平台上的技术交流是否存在就不得而知了.

在Borland,Janeva项目已经快要成型,JBuilder XI正在推Beta版本,由此可以预见,Java和.NET这两个同素异型体会有同化或者消失的一天.但是只要还有一天尚未同化,那么同时掌握这两个都是基于虚拟机的东西也不会是一件困难的事情,也会成为一件必须的事情.这对开发人员来说似乎是一种折磨,一种锻炼,一窍通则百通~

惊天大新闻：

http://java.sun.com/j2se/1.5.0/

居然是J2SE 5.0 !!!!

haha,当然是一个Joke啦。

前不久刚看了Java的COO和 President介绍的Looking －Glass项目。想不到这么快，这个项目就是Sun贡献给开源社区的礼物。

�http://javadesktop.org/articles/LookingGlass/index.html

http://wwws.sun.com/software/looking_glass/

难得Sun这么大方，而且将这么一个前卫的项目贡献出来，佩服。不过自问水平不够，对3D了解无多。参与不了了。。

Jonathan Schwartz 还是很帅的，看来，基于虚拟机上的桌面系统已经成为未来的一个方向。而且大有潜力可以挖掘，因为现在的CPU速度已经跟的上渲染的要求了。而且Java 和本地硬件的交互已经能做的很好了。

而且刚刚看到Sun已经发布了Java 3D的 API

https://java3d.dev.java.net/

还是很不错的。不过从Looking－Glass上来看是很不错的。

但是看上面的图片好像不行。比不上directX,DirectX 马上出10了。Sign。。。

Java将在多任务上得到改进――J2SE1.6呼之欲出

虚拟机技术将得以适用于应用程序共享

Sun公司正在致力于改进Java语言，使得能在一个虚拟机内实现多任务，在4月6日举行的ClusterWorld Conference & Expo会议上，一位Sun的官员如是说。

J2SE 1.6，正准备在今年秋季发布一个beta的测试版，并且计划在2005年能推出面向广大开发者。根据Sun高级Java架构师，Murali Kaundinya所说，这个版本的J2SE将加入Java开发者期待已久的?隔离(isolates)?功能来提升应用程序在同一个JVM中的共享能力。隔离机制将允许被隔离的各个实体能独立的完成各自的计算而不需要第二个JVM，也就是传统上说的多任务(Multitask)机制。

J2SE 1.6另外的一个重大特性将是支持Sockets Direct Protocol。Kaundinya 说：?这将为你提供Java程序之间的高速通信能力。?，并且在J2SE中做出的这些改进也将会在不久以后出现在J2EE中。

J2SE1.5已经在今年的一月份发布了Beta测试版，并且将预计在今年六月的JavaOne大会上发布正式版，Kaundinya说，J2SE1.5是专注于让Java编程变得更容易。

hehe,今天算是对Java的发展有了一个新的认识了，通过阅读JavaLobby（www.javalobby.com）上的一些文章，了解了最近的一些Java发展动态，例如Rich Green，以前Sun的一个VP在Sun和MS联盟的时候离开了工作了13年的Sun，Sign～。

还有一个非常好的主意将出现在NetBeans 4.0上，就是基于Apache Ant的项目管理，这样就使得一个Project可以不用过分的依赖IDE，而是可以建立起一条IDE和其他的开发编译工具之间的桥梁，这个特性太好了，不知道，JBuilder 11是否会支持这个特性。

另外一个震惊的消息就是，Sun将在今年年底左右推出J2SE 1.6的测试版本，我的老天，J2SE 1.5还没有上线，Sun这个家伙就要推J2SE1.6了，有完没有完啊。而且说2005年将是J2SE1.6的年份。可是Sun是说18个月也就是一年半推一个J2SE的版本的啊。

唉。么的救了，就这么把我折腾死吧。

参考link：http://www.infoworld.com/article/04/04/06/HNjava16_1.html

刚刚看到Sun推出了一个新的项目叫做Looking－Glass，这是Sun秘密准备着的下一代桌面系统。

大家可以通过下面的地址来看Jonathen给我们做的一个演示：

宽带高质量演示：（Real格式）

http://webcast-east.sun.com/ramgen/archives/GSN-1312/GSN-1312_01_450.rm

窄带演示：（Real格式）

http://webcast-east.sun.com/ramgen/archives/GSN-1312/GSN-1312_01_050.rm

如果我没有记错的话，早在2年前，Microsoft就已经推出了类似的3D桌面系统，当时在MSDN上还有一段这个3D桌面的演示呢，让我找找吧，如果能找到，那就贴上来。

刚刚看到消息，前几个月闹的非常厉害的要求Sun把Java贡献给开源社区的事情终于有了一个着落：

Sun的CEO Mc Nealy说，我们永远不会把我们的Java语言作为开源项目，并且针对IBM发给Sun的要求开源的信揶揄了一句?等你把你的DB2开源了再来告诉我应该怎么处理我的宝贝?。"Go open source with DB2 and then you can tell me what to do with my assets".

呵呵，Sun的宝贝还是捂的很紧的。

Bruce Eckel在前不久写了一片批判Java的泛型的文章，结合他在OO上浸淫多年的功力，一眼就看出了Java的泛型和其他例如C++，Python，Ruby等等这些语言的泛型的差别。

不过平心而论，Bruce Eckel的批评是比较中肯的，因为他也看到了Java和其他这些面向对象的语言之间的差别，他也可以理解Java实现出了这样的泛型。

另外，如果大家不知道Ruby是什么，可以参考下面的网站：http://www.ruby-lang.org/en/

详细内容如下：

昨晚，我作为嘉宾被Silicon Valley的模式组邀请去参加他们的一个研讨会，并且让我来决定讨论的主题，为了更好的了解JDK1.5，我选择了Java的Generics（泛型），最后讨论的结果是我们大家都有点震惊。我们讨论的主要素材是最新的Sun推出的Java 泛型手册。
我对?参数化类型?的经验来自于C++，而C++的泛型又是基于ADA的Generics，事实上，Lisp语言是第一个实现了泛型的语言，有人说Simula语言也很早就有泛型了。在这些语言中，当你使用参数化的类型的时候，这个参数是作为一种隐式类型（latent type）的：一种被实现出了如何使用，但是却没有显式的声明的类型。也就是说，隐式类型是一种通过你调用方法来实现的。例如，你的模板方法是某个类型中的f()和g()，那么接下来你实现了一个类型包含了f()和g()这两个方法，而事实上这个类型可能从来被定义过。
举个例子，在Python中，你可以这样做：

def speak(anything):
    anything.talk()

注意到，这里对anything没有任何的类型限制，只是一个标识而已，假设这个类型能做一个叫做speak()的操作，就象实现了一个Interface一样，但是事实上你根本不需要去真的实现这样一个Interface，所以叫做隐式。现在我可以实现这样一个?狗狗和机器人?的例子：

class Dog:
    def talk(self):  print "Arf!"
    def reproduce(self): pass

class Robot:
    def talk(self): print "Click!"
    def oilChange(self): pass

a = Dog()
b = Robot()
speak(a)
speak(b)

Speak()方法不关心是否有参数传入，所以我可以传给它任何的东西，就象我传入的对象中支持的talk()方法一样。我相信在Ruby语言中的实现是和Python一致的。
在C++中你可以做相同的事情：

class Dog {
public:
  void talk() { }
  void reproduce() { }
};

class Robot {
public:
  void talk() { }
  void oilChange() { }
};

template void speak(T speaker) {
  speaker.talk();
}

int main() {
  Dog d;
  Robot r;
  speak(d);
  speak(r);
}

再次声明，speak()方法不关心他的参数类型，但是在编译的时候，他仍然能保证他能传出那些信息。
但是在Java（同样在C＃）语言中，你却不能这样做，下面这样的做法，在JDK1.5中就编译不过去(注意，你必须添加source ? 1.5来使得javac能识别你的泛型代码)

public class Communicate  {
  public  void speak(T speaker) {
    speaker.talk();
  }
}

但是这样却可以：

public class Communicate  {
  public  void speak(T speaker) {
    speaker.toString(); // Object methods work!
  }
}

Java的泛型使用了?消磁?，也就是说如果你打算表示?任何类型?，那么Java会把这个任何类型转化为Object。所以当我说不能象C++/ADA/Python一样真正的代表?任何类型?，他只是代表Object。
看来如果想让Java也能完成类似的工作必须定义一个包含了speak方法的接口（Interface），并且限制只能传入这个接口。所以下面这样的代码能编译：

interface Speaks { void speak(); }

public class Communicate  {
  public  void speak(T speaker) {
    speaker.speak();
  }
}

而这样是说：T必须是一个实现了speak接口的类或者这样的一个子类。所以我的反映就是，如果我不得不声明这样的一个子类，我为什么不直接用继承的机制那？干吗还非要弄的这么费事还糊弄人呢？就象这样：

interface Speaks { void speak(); }

public class CommunicateSimply  {
  public void speak(Speaks speaker) {
    speaker.speak();
  }
}

在这个例子里，泛型没有任何的优势，事实上，如果你真的这样使用，会让人迷糊的，因为你会不停的搔头：为什么这里他需要一个泛型那？有什么优势？回答是：什么都没有。完全没有必要用泛型，泛型完全没有优势。
如果我们要用泛型来实现上面的?狗狗和机器人?的例子，我们被迫要使用接口或者父类，用这样显式的方式来实现一个所谓的?泛型?。

interface Speaks { void talk(); }

class Dog implements Speaks {
  public void talk() { }
  public void reproduce() { }
}

class Robot implements Speaks {
  public void talk() { }
  public void oilChange() { }
}

class Communicate {
  public static  void speak(T speaker) {
    speaker.talk();
  }
}

public class DogsAndRobots {
  public static void main(String[] args) {
    Dog d = new Dog();
    Robot r = new Robot();
    Communicate.speak(d);
    Communicate.speak(r);
  }
}

（注意到在泛型中你用的extends而不是implements，implements是不能使用的，Java是精确的，并且Sun说了必须这样做）
再一次，泛型和简单的接口实现相比没有任何的优势。

interface Speaks { void talk(); }

class Dog implements Speaks {
  public void talk() { }
  public void reproduce() { }
}

class Robot implements Speaks {
  public void talk() { }
  public void oilChange() { }
}

class Communicate {
  public static void speak(Speaks speaker) {
    speaker.talk();
  }
}

public class SimpleDogsAndRobots {
  public static void main(String[] args) {
    Dog d = new Dog();
    Robot r = new Robot();
    Communicate.speak(d);
    Communicate.speak(r);
  }
}

如果我们真的写一段能真正代表?任何类型?的泛型代码的话，那么这段代码所代表的类型只能是Object，所以我们的泛型代码只能说是Object的一个方法而已。所以，事实上，我们只能说Java的泛型只是对Object类型的一个泛化而已。不过免去从Object和其他类型之间不辞辛劳的转型，这就是这个所谓的?泛型?带给我们的好处。看起来似乎只是一个对容器类的新的解决方案而不是其他，不是么？所以这次讨论会得到的一致结论是，这个所谓的泛型只是解决了容器类之间的自动转型罢了。
另外一个争论是，如果让代表的是一种任意类型的话，会引起类型不安全的事件。这显然不对，因为C++能在编译的时候捕捉这样的错误。?啊哈?，他们说，?那是因为我们被迫用另外一种方法来实现Java的泛型?。
所以Java中的泛型是真正的?自动转型?。这是Java世界的方法，我们将失去真正的泛型（也就是隐式类型，事实上，我们可以用反射－reflection来实现这样的功能，我在我的《Thinking in Java》中做过2，3次这样的试验，但是实现起来有点乱，失去了Java的文雅本性）。一开始我对Java的泛型有震惊，但是现在过去了。至少有一点清晰的是，这是不得不这样的。C＃虽然有一个比Java更好的泛型模式（因为他们有点超前，他们修改了底层的IL所致，举个例子说，类和类之中的静态域（static field）是不一样的），但是也不支持隐式类型。所以，如果你想用隐式参数，你不得不使用C++或者Python或者Smalltalk，或者Ruby等等：）。