import java.applet.Applet;
import java.awt.*;public class Example4_d extends Applet
{
Button redbutton;
public void init()
{
redbutton = new Button("我是一个红色的按钮");
redbutton.setBackground(Color.red);
redbutton.setForeground(Color.white);
add(redbutton);
}
}
/*
 * 1)
 * public class Example4_d extends Applet
 * 报如下信息:
 * “serializable 类 Example4_d 未声明类型为 long 的静态终态 serialVersionUID 字段“
 * 2)
 * public void init()
 * 报如下信息:
 * 覆盖 java.applet.Applet.init
 */

解决方案 »

  1.   

    The serializable class Example4_d does not declare a static final serialVersionUID field of type long这属于警告,因为Example4_d类是可序列化的,要求有一个long型serialVersionUID域
    类似于
    private static final long serialVersionUID = -6344212589908974890L;
      

  2.   

    serialVersionUID是为了验证序列化前和反序列化后类版本是否一致
    不声明的话jvm也会自动生成一个默认的,但因为其生成对类细节信息高度敏感和因jvm实现不同而不同,很容易产生InvalidClassExceptions,因此不建议
      

  3.   

    自动生成的serialVersionUID一般情况下也没什么问题的因为多次编译产生的serialVersionUID是不同的
      

  4.   

    什么时候需要更改serialVersionUID,是在对类的结构作了不兼容的改变之后,详见:
    http://java.sun.com/j2se/1.4/pdf/serial-spec.pdf我想应该是这样:对象反序列化时如果类已作不兼容更改,就需要改变该类serialVersionUID
     
      

  5.   

    类结构前后没改变情况下,不同恰恰就是问题(jvm不同实现引起)
      

  6.   

    是同一个jvm吧Client / Server environment- Client is using SUN’s JVM in Windows.
    - Server is using JRockit in Linux.Client sends a serializable class with default generated serialVersionUID (e.g 123L) to server over socket, server may generate a different serialVersionUID (e.g 124L) during deserialization process, and raise an unexpected InvalidClassExceptions.引用自:http://www.mkyong.com/java-best-practices/understand-the-serialversionuid/
      

  7.   

    人为设置时,它变不变是受你控制的,序列化和反序列化时serialVersionUID的值
    你觉得你的类版本没变时,就不要改变serialVersionUID
      

  8.   

    类的结构作了不兼容的改变之后需要改变serialVersionUID,这个我没验证过