commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject Re: [DISCUSS] New Expressions Sandbox Project...
Date Thu, 10 Apr 2008 12:21:26 GMT
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <> wrote:
>  No, I support this and would like to work on it.

That's great!  I would love to have some help/input on this.

>  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.

Yes, primarily it deals with object graph navigation, but the
Expression implementations can support more complex scenarios via the
underlying technology.

>  (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);
>  }

I don't know about this API.  The idea behind [expression] is that
it's not necessarily string-based (a lot of the impls are, but the
Javassist one wouldn't be; it'll probably only be available via
builder).  The [expression] project strives to treat the expression as
a first-class object which encapsulates the underlying technology.

>  Names TBD etc.
>  SAMPLE USAGE (untested, ofcourse):
>   Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
>   Context context = evaluator.newContext(null);
>   context.put(...);
>   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.

I didn't consider JavaScript, but that's an interesting idea.
>  (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).

I would have to disagree with this.  The API I'm using makes the code
easier to read, IMHO.  I would want it to use generics.  No, it
doesn't necessarily *guarantee* type safety (as evidenced by the
@SuppressWarnings("unchecked) in the code), but it doesn't hurt by
having it there and makes it easier to use the code in other libraries
(like Wicket; I can imagine a Wicket ExpressionModel<T> which extends

>  (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".

BeanUtils does support "expressions" in that they have their own
expression syntax for referring to bean properties.  That's why I
chose to support it.  The same goes for JXPath.

>  (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.

Well, the builder idea does require proxies to get it to work.  I'm
using the InvocationRecorder support from Proxy to achieve this.  I
could pull that stuff out of proxy and into [expression] if others see
that as necessary.  I think the builder idea is a very nice addition,
though.  It's like being able to create an anonymous inner class in
Java without having to create the class.  It's almost like having a
closure (albeit a limited one)! :)

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

I can put my existing code into the sandbox to bootstrap it.  I have
access to the sandbox.  I just wanted to make sure nobody completely
objected to the idea behind [expression] with respect to the commons
in general.

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

View raw message