commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [DISCUSS] New Expressions Sandbox Project...
Date Thu, 10 Apr 2008 11:56:54 GMT
On Wed, Apr 9, 2008 at 11:18 PM, James Carman
<> wrote:
> On Wed, Apr 9, 2008 at 9:47 PM, James Carman <> wrote:
> >  So, does anyone object to me putting this code into the sandbox?

No, I support this and would like to work on it.

> >  I've
> >  got working versions of expressions and builders (with test cases of
> >  course) for:
> >
> >  MVEL
> >  OGNL
> >  BeanUtils
> >  JXPath
> >
> If you're interested, I set it up in my own SVN repository while I was
> working on it:

Thanks a lot, this is great. I was lost reading the emails in this
thread but the code has made things much clearer.

I have some immediate comments:

(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.

(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:

The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):

public interface Context {
  Object get(String name);
  void set(String name, Object value);

public interface Evaluator {
  Object evaluate(String expression, Context context)
         throws EvaluationException;
  Context newContext(Context parent);

Names TBD etc.

SAMPLE USAGE (untested, ofcourse):

  Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example

  Context context = evaluator.newContext(null);

  try {
    /*Some type*/ result = evaluator.evaluate("...", context);
  } catch (EvaluationExpression ee) {
    // ...

We have proven implementations of this in [scxml] land for:
 * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
 * Commons JEXL
 * JavaScript (by way of Rhino)
 * Various (by way of javax.script)
 * Pnuts

Other comments:
 * I've done adapters for two proprietary ELs
 * MVEL would be trivial
 * I'm not familiar with its OGNL APIs, will take a look later

To summarize, generally the above abstraction has worked well.

(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).

(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate "22 / 7".

(5) The [proxy] APIs have bled into your proposal. While thats
completely understandable in a PoC since you have the [proxy] usecase
in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
might need a subinterface or equivalent of the cleaner [expression]
APIs, we'll have to see. If [expression] makes progress, I'd want
[scxml] to depend on it.

I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.


> Enjoy!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message