Serializable 인터페이스

 

객체건 뭐건 결국 바이트의 흐름으로 전송하게 된다. 저장도 그렇고…
다시 읽었을 때 객체의 자료구조를 그대로 보존하지 않으면 객체 지향 프로그래밍은 없다.
자바에선 Serializable 인터페이스만 구현하면 알아서 이를 보장해준다.

일명 Serialzation

단지 implements Serializable 만 추가하면 되기에 이 녀석을 관심을 대상에서 배제된다.
공기가 흔해서 고마움을 모르듯이(?)

느닷없이 경고 문구를 보게되었다.
아마도 JDK 5.0 을 사용해서 나타나는 것이라 추정된다.

내가 만든 InvalidEmployeeNameException 클래스는 Exception을 상속받아서 자연스레 Serializable 인터페이스도 구현하게 된다. 늘 그냥 쓰던 것인데 새삼스레 경고가 뜬다. 에러는 아니지만 찜찜해서 코딩하다 말고 중간중간 이녀석을 해결할 것을 고민하게 된다.

경고는 static final long 타입의 serialVersionUID 상수를 선언하라는 것이다.

API를 뒤척이다 관련된 내용을 찾았다. 지금 읽고 있다.

찾아보니 Serializable 인터페이스 이외의 경우에도 보안 등의 용도로 많이 쓰였다.
일종의 객체에 대한 지문(fingerprint)으로 이해할 수 있을 것 같다.

음… 중요한 내용인데 어설프게 정리했다가 오해의 소지가 날 수 있어서 일단 해석만 해야겠다.

Serializable 인터페이스를 구현한 클래스는 자신의 serialVersionUID를 명시적으로 선언할 수 있는데, 필드의 이름은 “serialVersionUID”이며, static, final 이어야 하며 long타입이다.

예) private(추천) static final long serialVersionUID = 42L;

만일 serialVersionUID를 지정하지 않으면 실행시점에서 serialization을 담당하는 모듈이 디폴트 값을 산정하게 되며, 그 알고리즘은 Java(TM) Object Serialization Specification 정의된 것을 따른다. 그러나 모든 serialization이 필요한 클래스에 명시적으로 serialVersionUID 값을 선언해줄 것을 강력하게 권유한다. 그 이유는 디폴트 serialVersionUID 계산은 클래스의 세부 사항을 매우 민감하게 반영하기 때문에 컴파일러 구현체에 따라서 달라질 수 있어 deserialization(serialization 했던 객체를 복구하는 과정)과정에서 예상하지 못한 InvalidClassExceptions을 유발할 수 있다.
그러므로, 서로 다른 자바 컴파일러 구현체 사이에서도 동일한 serialVersionUID 값을 얻기 위해서는 명시적으로 serialVersionUID 값을 선언해야 한다.가능한 serialVersionUID을 private으로 선언하기를 권장한다. 상속되어 쓰여지는 것은 유용하지 않고, 해당 클래스에서만 쓰일 것이기 때문이다.

참고 : http://blog.naver.com/an5asis/60022869955

 

This entry was posted in Java/JSP and tagged , , . Bookmark the permalink.

댓글 남기기