This is an example PersistentComponent component with a final field.
import com.simsilica.es.PersistentComponent;
public class PlayerCharacter implements PersistentComponent {
private final boolean leader;
public PlayerCharacter() {
// No-Arg Constructor usde for JME Serialization
this(false);
}
public PlayerCharacter(boolean leader) {
this.leader = leader;
}
public boolean isLeader() {
return leader;
}
}
and I am registering it using a FieldSerializer:
Serializer.registerClass(PlayerCharacter.class, new FieldSerializer());
I add it to the player character (while setting the field to true) when I initialize it for the first time.
GameEntities gameEntities = manager.get(GameEntities.class);
gameEntities.createEntity("Doha", ed.createEntity(),
new SpawnPosition(0, 1, 0),
new PlayerCharacter(true)
);
I can save/load it from SqlEntityData without issue.
The problem is when I look for it from the client-side using an EntitySet the field is “false” (set by no-arg constructor) instead of being “true”.
If I remove the final modifier from the field then it works fine.
Would it be possible to add support for final field serialization in JME’s networking layer?
and i understand there were no Errors, because i think there might be problem for Reflection to set Final field (it require tricks to set it). Maybe JVM do not allow reflection set it even via constructor call, idk.
Or constructor set it, but it cant later change it to “true” due to JVM security reasons.
But anyway its not a problem in this case, since if im not wrong readObject override default serialization. So if Paul skip final fields, it just skip them anyway. (it could be anyway problem for Reflection to read them, even if setAccessible is true)
Now i feel like i should remind myself all reflection-security topic hehe.
Seems like we need wait for @pspeed reply.
But i guess it will be “you cant use final fields, because…”
(or at least use final fields, but not for serialize purpose)
Tho as i remember, default Java Serialization is able to serialize/deserialize final fields.
Actually my point was to see if I can convert my components to Java Record (added in Java 14) because it fits the design better for immutable objects and remove most of the boilerplate codes. (implicitly all fields are final in records and compiler add getters automatically and there is no setter).
May be we need a RecordSerializer for this specific purpose.
Paul did not write the crap that is the JME serializer stuff… only patched it here and there so it was usable.
My one regret when rewriting spider monkey was not rewriting this package. Since according to some it was “working perfectly”, I chose to concentrate on the things that were horribly broken.
Though if I were to rewrite it today, it would be much better than if I rewrote it back then. It is still on my to-do list to make a bit stream based implementation.
By the way, my client and server are inside the same VM (embedded server) do I need to test the case where the client and server are separated or that is not relevant?