Hi Roger,
Thanks for the explanation; I'll adjust the proposed java.io.Serial spec
and serialization-related check accordingly.
Cheers,
-Joe
On 8/10/2018 11:02 AM, Roger Riggs wrote:
Hi Joe,
serialVersionUID is used to confirm the identity of a class so it is
applicable to classes
implementing Externalizable as well as Serializable. (And also
serialization of a class itself).
Thanks, Roger
On 8/10/18 1:39 PM, joe darcy wrote:
Hi Roger,
Returning to this topic, I'll add a clause in the spec for
serialPersistentFields and Externalizable and corresponding code in
the checker. Should there be a similar check for serialVersionUID in
an Externalizable class? It wasn't clear to me from reading the specs
and there are cases in the JDK of classes implementing Externalizable
and having serialVersionUID fields defined.
Thanks,
-Joe
On 5/10/2018 2:26 PM, Roger Riggs wrote:
Hi Joe,
The words are fine.
The field serialPersistentFields is also not used with @Externalizable.
I would guess the lint checker would flag those methods and field
for warnings for Externalizable classes
since they might mislead to think they were used.
Roger
On 5/10/2018 5:03 PM, joe darcy wrote:
PS After additional reading, I propose to add the follow clause to
where using the annotation is not appropriate:
* <li>the {@code writeObject}, {@code readObject}, and {@code
* readObjectNoData} methods in a class that is {@code
* Externalizable}. While the {@code Externalizable} interface extends
* {@code Serializable}, those three methods are not used for
* externalizable classes.
How does that sound?
Thanks,
-Joe
On 5/10/2018 1:22 PM, joe darcy wrote:
Hi Roger,
Right; there are a few other distinguished methods defined for
externalization, but they are defined on the as methods on the
Externalizable interface as far as I can tell. The existence of
externalization is mentioned in the javac lint bug JDK-8202385.
I'll add as sentence indicating that the checks are for
"Serializable but not Externalizable" classes.
Thanks,
-Joe
