Artur,
I think that running serialver on Sun's classes and hardcoding their uid
in classpath's or kaffe's classes is perfectly fine.
We've already done it for a lot of classes anyway.
I remember that Tim said at some point that using reverse-engineered
information is legally okay if there's no other way to achieve
interoperability. This was in the context of header files, I think.
Btw, it's the same with the values of "public final" constants in
many of Sun's interfaces. Those aren't published either and have to
be reverse-engineering by writing programs and running them against
Sun's JDK)
- Godmar
>
> For now java.util.ArrayList (and I suppose a lot of other classes) is
> not compatible with one serialized from JDK because of different
> serialVersionUID. ArrayList do not seem to have published it's ID, so it
> is probably computed in normal way from name/fields.
>
> Could we legally check serialver for JDK class library and include their
> IDs in classpath classes ? Also, are there any other reasons to not do
> it ?
>
> I know that it is stupid for sun to not publish ids, but this kills
> serialization - classpath, kaffe and sun JDK has different ids from each
> other. Of course I can workaround it in my installation, by replacing
> certain kaffe classes with sun's ones, but it is not a long term
> solution.
>
> Sorry for crossposting, but it affects both projects (kaffe and
> classpath). If you want to discuss only one of them, please delete
> second destination from To: list.
>
> Artur
>
