The current Faker.with(Context) is broken if used by multiple threads. The mFaker needs to be declared as volatile, or someone may get an partially initialized instance of it. Also if anyone accesses the static fields like Lorem, they may get incomplete instances if they do not synchronize of Faker.class first.
https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java
As a whole nothing seems to be trying to be thread safe in this library other than Faker.with(), which does so incorrectly. Probably need to look into each class and see if they can be made thread safe. The methods that act on Views don't need to be, but the generic data generation methods should be thread safe.
An example. LoremComponent, would be thread safe if loremWords was declared final, since the final will make sure anyone that gets an instance of it will see the list fully constructed. And if FakerCoreComponent had the context declared as final.
The current Faker.with(Context) is broken if used by multiple threads. The mFaker needs to be declared as volatile, or someone may get an partially initialized instance of it. Also if anyone accesses the static fields like Lorem, they may get incomplete instances if they do not synchronize of Faker.class first.
https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java
As a whole nothing seems to be trying to be thread safe in this library other than Faker.with(), which does so incorrectly. Probably need to look into each class and see if they can be made thread safe. The methods that act on Views don't need to be, but the generic data generation methods should be thread safe.
An example. LoremComponent, would be thread safe if loremWords was declared final, since the final will make sure anyone that gets an instance of it will see the list fully constructed. And if FakerCoreComponent had the context declared as final.