Kiss: Mitigate synchronization problems with immutable pojos

[EmmanuelMess]

It seems that many of the pojo classes can be immutable classes, that would help with and reduce possible bugs, such as synchronization problems.

[Neamar]

Not a Java expert, but from what I understand this would mean creating constructors and marking all fields as final, right?

[Neamar]

Pull requests welcome :)

[EmmanuelMess]

You can assing this to me, I'll do it next week though.

[Neamar]

Thanks!

[EmmanuelMess]

I will start ASAP (probably sunday).

PS:
I was ill and working on projects for school for most of this week, so I wasn't able to look at any GitHub notification...and they accumulated quite a bit. I'm able to work now, so I apologize for the lateness.

[Neamar]

(see #1083)

[EmmanuelMess]

Changing the names from "Pojo" to something more descriptive would be in order, what do you say the name could be?

[EmmanuelMess]

(see #1086)

[Neamar]

Closing the issue!

@EmmanuelMess as an active contributor, do you want to join the private contributor chat? If so, send me an email at [email protected] and I'll add you!

[EmmanuelMess]

Closing the issue!

Not yet, some of the Pojos aren't immutable yet.

[Neamar]

@EmmanuelMess do you still plan to work on this at some point?

Otherwise, are you OK to close?

[EmmanuelMess]

@EmmanuelMess do you still plan to work on this at some point?

No plans for now, too little time.

Otherwise, are you OK to close?

Well the issue is still there for some Pojos.

[Neamar]

I've marked most Pojos as final (both class and properties) where it made sense.

I've kept some as mutable classes (thinking about SearchProviders) where it made sense to keep a single property change rather than using the constructor for the whole Pojo.

This shouldn't be a threading issue, as Pojo writes only happen from a single thread (they're only read from the UI thread, never changed).

Thanks for raising the concern and helping with the first batch!