On Fri, 20 Oct 2023 at 19:09, Henri Biestro <hen...@apache.org> wrote: > > > JexlPermissions concrete classes are but since this is an interface, anyone > could create a non-thread safe instance and use it. The same way a > JexlFeatures could be corrupted by being constructed with a non-thread safe > namespace predicate (making side-effects etc). > And for JexlFeatures, using a concurrent set for reserved names (although a > strange idea) could be a valid usage (counting the number of times a var name > is declared for instance). > > Back to your question, both of them are *expected* to be thread-safe if you > want to use the same JexlEngine and JexlScript across threads. There is no > way to ensure this and I suppose altering documentation would not ease your > worry.
JexlFeatures is not thread-safe, but AFAICT JexlEngine does not need JexlFeatures to be thread-safe, because it takes its own copy which is stored in a final field as part of construction. That should ensure the mutable fields are published safely. Of course if changes are made subsequently to the copy, that would change matters. If JexlFeatures were immutable there would be a lot less to be concerned about. Sebb > > On 2023/10/20 16:26:30 sebb wrote: > > Are instances of the classes JexlFeatures and JexlPermissions intended > > to be thread-safe? > > > > I have seen mention that they can be shared between threads. > > > > However JexlFeatures is does not appear to be thread-safe (has mutable > > fields which are not safely published). Not looked at JexlPermissions > > in detail. > > > > Sebb > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
