关于两个不同公司开发的两个系统分别只支持MS JVM与Sun JVM的问题分析与解决方法的讨论背景说明：
================================================================================
某软件开发公司B ==>>代替真正公司的名字
某某客户 ==>> 代替真正的客户公司名字
两公司分别开发系统A与系统B，某软件开发公司A开发系统A，某软件开发公司B开发系统B
系统A实施与应用时间比系统B早一年多，但只支持IE默认的MS JVM
系统B只支持Sun JVM
================================================================================================================================================================
以下是某软件开发公司B对某软件开发公司A开发的系统A的升级建议
================================================================================
关于某某客户系统A升级的建议
自2005年1月系统B在某某客户分公司试运行以来，发现某某客户分公司的系统A与系统B二者不兼容。具体表现为：某某客户分公司的系统A的某些功能只能在Microsoft JVM下运行，而该JVM只支持1.1版本的JDK；系统B要求的JDK版本为1.3或1.4。就此问题，某软件开发公司B组织人员专门对JDK各版本兼容性进行深入研究，发现二者不兼容的原因如下。
1. JDK各版本类的组织发生了改变，导致系统B客户端程序运行在只支持低版本JDK的JVM下时（譬如说Microsoft JVM），该JVM会找不到相应的类。例如：系统B客户端程序用到PrintJob类，该类在JDK1.1版本中是位于java.awt包下，而在JDK1.2版本以后新增了一个java.awt.print包，并将该类放在此包下面。这样就导致即使以Microsoft JVM类的加载格式重新编译系统B，在运行过程中也会报错：找不到PrintJob类。
2. 高版本的JDK对低版本的某些类不但在功能进行了相应的增强，而且其运行机理也与低版本有较大不同。比如说系统B大量使用了Thread类， 1.1版本的JDK对该类的设计在安全性上存在严重问题，1.2及其以上版本的JDK对此进行了全面的改进。这样就导致1.1版本的JDK编译器编译出来的客户端程序不能运行在1.2或更高版本的JVM之下，1.2版本的JDK编译器编译出来的客户端程序即使能运行在1.1版本的JVM之下，也可能会抛出异常（比如说找不到该方法等等异常）。
通过对JDK各版本兼容性的研究以及对系统B功能实现的综合考虑，开发人员发现系统B向下兼容（即通过修改WEB系统源代码，使得客户端程序可以在Microsoft JVM下运行）实现起来需要修改大量程序代码，工作量很大，并且系统安全性、可靠性都会出现问题（这是由JDK1.1本身缺陷造成的）。相比较而言，升级系统A，使其可以运行在较高版本的JVM之下就容易很多，也更合理，原因如下。
1. 高版本的JDK开发、编译出来的客户端程序往往更加稳定、更强壮，解决问题的手段也较为丰富。升级之后的系统A扩展功能将会变得相对容易。
2. Microsoft已经宣布到2007年底推出的Internet Explorer将不再包含Microsoft JVM，即以后的IE都必须由用户自己安装相应的JAVA运行环境，也就是说日后系统A的升级的可能性非常大。
3. 升级系统A相对简单，只要将相应的源程序用高版本的JDK重新编译，编译过程中编译器可能会提示：找不到某些包，这样只需修改相应的import路径即可。工作量较小。
基于以上考虑，希望某某客户分公司采纳此意见，升级系统A，解决二者不兼容的问题。在此过程中，某软件开发公司B进行相应的配合。 某软件开发公司B
2005-02-05
================================================================================
某软件开发公司B ==>>代替真正公司的名字
某某客户 ==>> 代替真正的客户公司名字
两公司分别开发系统A与系统B，某软件开发公司A开发系统A，某软件开发公司B开发系统B
系统A实施与应用时间比系统B早一年多，但只支持IE默认的MS JVM
系统B只支持Sun JVM
================================================================================================================================================================
以下是某软件开发公司B对某软件开发公司A开发的系统A的升级建议
================================================================================
关于某某客户系统A升级的建议
自2005年1月系统B在某某客户分公司试运行以来，发现某某客户分公司的系统A与系统B二者不兼容。具体表现为：某某客户分公司的系统A的某些功能只能在Microsoft JVM下运行，而该JVM只支持1.1版本的JDK；系统B要求的JDK版本为1.3或1.4。就此问题，某软件开发公司B组织人员专门对JDK各版本兼容性进行深入研究，发现二者不兼容的原因如下。
1. JDK各版本类的组织发生了改变，导致系统B客户端程序运行在只支持低版本JDK的JVM下时（譬如说Microsoft JVM），该JVM会找不到相应的类。例如：系统B客户端程序用到PrintJob类，该类在JDK1.1版本中是位于java.awt包下，而在JDK1.2版本以后新增了一个java.awt.print包，并将该类放在此包下面。这样就导致即使以Microsoft JVM类的加载格式重新编译系统B，在运行过程中也会报错：找不到PrintJob类。
2. 高版本的JDK对低版本的某些类不但在功能进行了相应的增强，而且其运行机理也与低版本有较大不同。比如说系统B大量使用了Thread类， 1.1版本的JDK对该类的设计在安全性上存在严重问题，1.2及其以上版本的JDK对此进行了全面的改进。这样就导致1.1版本的JDK编译器编译出来的客户端程序不能运行在1.2或更高版本的JVM之下，1.2版本的JDK编译器编译出来的客户端程序即使能运行在1.1版本的JVM之下，也可能会抛出异常（比如说找不到该方法等等异常）。
通过对JDK各版本兼容性的研究以及对系统B功能实现的综合考虑，开发人员发现系统B向下兼容（即通过修改WEB系统源代码，使得客户端程序可以在Microsoft JVM下运行）实现起来需要修改大量程序代码，工作量很大，并且系统安全性、可靠性都会出现问题（这是由JDK1.1本身缺陷造成的）。相比较而言，升级系统A，使其可以运行在较高版本的JVM之下就容易很多，也更合理，原因如下。
1. 高版本的JDK开发、编译出来的客户端程序往往更加稳定、更强壮，解决问题的手段也较为丰富。升级之后的系统A扩展功能将会变得相对容易。
2. Microsoft已经宣布到2007年底推出的Internet Explorer将不再包含Microsoft JVM，即以后的IE都必须由用户自己安装相应的JAVA运行环境，也就是说日后系统A的升级的可能性非常大。
3. 升级系统A相对简单，只要将相应的源程序用高版本的JDK重新编译，编译过程中编译器可能会提示：找不到某些包，这样只需修改相应的import路径即可。工作量较小。
基于以上考虑，希望某某客户分公司采纳此意见，升级系统A，解决二者不兼容的问题。在此过程中，某软件开发公司B进行相应的配合。 某软件开发公司B
2005-02-05
由于我们A公司对产品源代码有全部所有权，所以不打算给公司B看。
所谓的升级系统A只是B公司单方面的片面之词，根据我们A公司的评估，发现升级非常麻烦，经初步估计，大概需要$1,000,000的费用。
由于B公司擅自更改客户计算机上的JVM，导致A公司的程序不能运行，对A公司造成恶劣的影响，因此A公司强烈要求B公司停止这种破坏行为，并赔偿人民币若干云云。
<param name="cabbase" value="Applet.cab">
<param name="archive" value="Applet.jar">
<param name="Name" value="value">
</applet>
不过象这样的情况，各打五十大板肯定解决不了问题，必须有一方做出改动，这可以说不是技术上的问题，要看两家公司怎么去协调处理了。
MS已经从SUN挖走多少天才了！
为了什么？？
就是想将来MS一统天下！
1. jdk1.1和后续版本不兼容. 因为jdk 1.1 实在太不成熟. 且ms的jdk也确实扰乱了市场.2. 一些awt io处理方面不兼容.写gui时比较麻烦. swing会比较好。其他大部分api都是可以继续用的.只是在后续版本中被标记为deprecated. 知道不兼容情况, 也很容易把握该怎么写能够继续用的程序了吧.
* @deprecated As of JDK version 1.1,当然加上
* @deprecated As of JDK version 1.1, replaced by <code>NewClass.newMethod(String s)</code>.
给人家提示一下更好了比如：你的DepartedClass里有个方法departedMethod是即将被抛弃的，那么在另一个新类里引用这个被抛弃方法时，在编译时就人报信息的：）完整的程序附后。
* <p>Title: DepartedClass</p>
*
* <p>Description: DepartedClass</p>
*
* <p>Copyright: Copyright (c) 2004</p>
*
* <p>Company: Beyond DayBreak Office</p>
*
* @author YuLimin
* @version 1.0
*/
public class DepartedClass
{
/**
* 即将被抛弃的方法
*
* @param s a string.
* @see NewClass
* @see NewClass#newMethod(java.lang.String)
* @deprecated As of JDK version 1.1, replaced by <code>NewClass.newMethod(String s)</code>.
*/
public void departedMethod(String s)
{
System.out.println(s + ":Departed Method!");
} /**
* 测试即被抛弃的类、方法，这里编译是不会报departed信息的，只有在另一个类引用此类时，在编译新类的时候才会提示departed信息的。
*
* @param args String[]
*/
public static void main(String[] args)
{
DepartedClass departedclass = new DepartedClass();
departedclass.departedMethod("Hello");
}
}
* <p>Title: DepartedTest</p>
*
* <p>Description: DepartedTest</p>
*
* <p>Copyright: Copyright (c) 2004</p>
*
* <p>Company: Beyond DayBreak Office</p>
*
* @author YuLimin
* @version 1.0
*/
public class DepartedTest
{
/**
* 引用即被抛弃的类、方法，这里编译的时候就会提示departed信息的。
*
* @param args String[]
*/
public static void main(String[] args)
{
DepartedClass dc = new DepartedClass();
dc.departedMethod("test");
}
}
不能改到1.5，因为我还没用过呵呵呵
而且1.5与1.2，1.3，1.4差别很大
做Applet应用时是要考虑不同的JVM的问题，做多了就知道：）
没做过,也知道啊
比如263.net上的 那个棋牌室 就他 妈的要ms 的,晕,超级烂,还不能升级!辛好,还没有看到必须要IBM的
用浏览器运行applet时，总提示：
java(TM)plug-in致命错误：
无法从<\bin\hotspot\jvm.dll>载入java runtime environment
是不是因为系统里装过不同版本的JVM呢？卸载时没有卸载干净?
呵呵，借地方一用