commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Maplesden (JIRA)" <>
Subject [jira] [Commented] (JEXL-146) Performance problem in Interpreter.unknownVariable mechanism
Date Wed, 01 Oct 2014 10:56:33 GMT


David Maplesden commented on JEXL-146:

Hi Henri,

Thanks for your quick response.

I haven't done a line by line check but it certainly looks like it has addressed my main concern,
delaying the construction of the exceptions until the point where they are actually thrown.
 Looks good.  Some of the other changes I don't completely understand but I trust you do!

One thing I did notice, the way you now temporarily change the `strictEngine` member variable
means the class is no longer thread-safe.  I'm not 100% sure that it was thread-safe before,
but it seems possible that it was intended to be given that most of the member variables are
final or volatile.  You may need to double-check that usage.  Although looking closer it looks
like `functors` was already not used in a thread-safe manner... so maybe the class is not
intended to be thread-safe.

Anyway, thank you for the change, it does look like it will address my problem.

> Performance problem in Interpreter.unknownVariable mechanism
> ------------------------------------------------------------
>                 Key: JEXL-146
>                 URL:
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 2.1.1, 3.0
>            Reporter: David Maplesden
> When JEXL is used in non-strict mode it silently ignores unknown variables.  However
it still constructs a {{JexlException.Variable}} exception, even though it doesn't throw it.
> Constructing exceptions in Java is expensive.  If you happen to have a situation where
unknown variables are common then this becomes a performance problem.  It is showing up as
an issue in our application.
> Inspecting the source of {{Interpreter}} it looks like a similar issue could also occur
with a number of the other exceptions.  They are always created, even if they are not going
to be thrown.

This message was sent by Atlassian JIRA

View raw message