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