1.我们老祖宗说过，合久必分，分久必合。软件工程本身是希望从工程学的角度来控制工程的进度，混杂各种技术不是什么好现象，C++恐怕种类也不少，目前还有谁只写ansi C++的？看到漫天飞的makefile，各个版本的lib，不知名的头文件()，遍地的define。。。，恐怕晕的不止我一个，多有耐心的人都要消耗时间来协调各个部分的程序(呜呜，我是低手，别臭我)，写了许久，还是某个平台的(确实有人可以写出移植方便的程序，但我辈低手尚我此种眼界和经验)。提到IA32真考倒了，java和jvm最好还是分开讲，信任一群公司的联盟可以提供更好的jvm，好象不只是我这么想。当然，java很多东西做不了，可以尝试通过JNI、CORBA、Socket等技术来调用万能的C++啊。十八班武器，那个没有自己长短处？不过现在做底层应用的，还是以C为主。不信，看看那些做通讯，电子的，哪个是在用C，而且将来也不一定会转到C++。
2.java是什么？这个问题问的好，三年前，两年前，一年前，半年前，大家的理解都不同，本人第一次对这个问题有感觉有触发是在回答一份ibm调查问卷的时候。
java.sun.com/products下面那些东西，有谁看完了？我是看了几个，但起码知道跑java的设备目前已经存在了，虽然是手持设备或通讯类产品，而且不是只能跑java，但起码那也叫硬件。将硬件跟软件支持分开，这才是适应不断升级硬件、软件的最优结合方式，拘泥于技术的细节，忽略方向，这样子很被动的。
3.被他的例子击中要害。没话讲，一是不熟悉，二是我也基本同意他的看法，除了3.1.3，小小细节就不必拖出来讲了。
4.
4.1是个老话题了。的确，java效率通常要低于c++，但是它是挂在jvm上运行的，比通常的C++运行多了个壳，而且用循环来比较的话，恐怕这种举例更不公平，显然C++对于y = x * z优化跟java的处理有不同。如果一味强调编译器优化的某项特性，那java这边也可以做优化啊。运行态编译就那么不可行？别忘了，服务器上的程序没有哪个是运行一次就被重新执行的，而执行过一次，运行态编译就会体现它的优点，一个C++程序运行一次3秒，一个java程序运行一次6秒，这就说java慢？好，那么那个c++程序运行10000次就是30000秒，那个java还是这么简单乘法吗？请考虑统计数据采样的重要性。统计本身就是们学问，加减乘除都要有凭据的。对于两者效率差多少，个人意见：在不同的应用场合下来测试，这样可能客观点。
4.2预编译java谁说没有？SQLJ白出来那么久了。运算符重载在java就有一个"+"，如果C++中有反射的话，相信灵活性会有更大程度的提高。模板类都是C++的精华，我也非常喜欢，那是C++中的奇迹，ATL和STL活在一群热爱C++的程序员里面，但是其它语言又有谁支持了？类型约束，呵呵，如果程序员连类型都写错，那么在C++不需要改吗？多继承是个老话题，不过从com/dcom、corba这些技术，恐怕接口比多继承更受欢迎吧。毕竟超过二层的多继承在C++应用实例也不常见，主要原因是没必要，而且程序难调。AWT的确不是很受欢迎，4年前，人们都以为AWT就是java全部，结果多少人放弃java，但现在情况就完全不同了。java可以将程序压缩放在jar文件中，以减少文件尺寸和方便管理，不过pe的也有压缩加壳技术，但是终究不是系统级支持。
