|
My Java version is the 1.5.0_14 and the value -3126998878902358585L comes from a solution that I read in a forum. The class that I'm trying to use is:
import java.util.Date; public class DateExtendido extends Date { static final long serialVersionUID = -3126998878902358585L; public Date date=null; |
|
|
Hi, I was having this error.
Take a look at the hex representation of both serial uids: 7523895402267505689: 0x686A3F014B597400 7523967970034938905: 0x686A81014B597400 The 0x3F was changed by a 0x81. In my case this behaviour was caused (only in MS Windows) by a string proccessing of the serialized object stream before unmarshall the object. A proccessing like that: byte[] processedSerializedObjectByteArray = serializedObjectByteArray.toString().replace( ..., ... ).getBytes(); I fixed the problem with binary replace instead of using the String API, wich causes the replacement of 0x3F characters into 0x81 (only in MS Windows). Are you doing a similar string proccessing? |
|
|
Also @OP I can't see what value the DateExtendido class is adding ...
|
|
|
Hi,
I'm tried another way. Cos the java.util.Date don't works anyway, I'm save it as a String using DateFormat. The String type don't need the serialVersionUID. |
|
|
See reply #16. The 0x81 is the only byte with the high bit set and it is the only byte which is being corrupted. This clearly indicates that you are corrupting the stream somewhere, possibly by using a Reader or Writer, or converting it to and from a String. If you don't fix that problem it will come back and bite you somewhere else.
|
java.io.InvalidClassException: local class incompatible: stream classdes
最新推荐文章于 2022-10-22 22:52:54 发布