MVEL 1.1, expression and property access language, released

Discussions

News: MVEL 1.1, expression and property access language, released

  1. Given the enormous response that MVEL 1.0 received, and directly due to feedback and requests made by many, MVEL 1.1 represents major improvements to the baseline functionality of MVEL, as well as further performance enhancements, most notably the ability to now compile expressions in MVEL. MVEL is a full-featured property access and expression language, including a templating system. It is simple to integrate, and simple to use with a language grammar mirroring that of Java with orthogonal language extensions. It's licensed under the Apache 2.0 license. New features in 1.1 include:
    • Projections support
    • Soundex and String Similarity operators added
    • Pre-compilation of expressions
    • Caching improvements for repetitive statements, including sub-expression compilation and recursive statement compilation support.
    • Type conversion API now open.
    • Support for typeless, inline Map, List and Array creation
    • Improved resolution accuracy for method and constructor information (exact signatures not prioritized over covertable signatures.)
    One of the major benefits of MVEL is that in many cases its interpreted-mode execution is almost-as-fast as compiled execution, allowing for more liberal use of MVEL without extraneous caching of pre-compiled expressions. (Performance figures here) In addition to being an EL, MVEL also comes packaged with a high-performance property accessor API, which can also be used for situations where only property-access is desirable.

    Threaded Messages (15)

  2. Needs some stabilization work[ Go to top ]

    Hi, this looks like an interesting project. I took a little bit of time to integrate this into RIFE templates alongside with support for OGNL, Groovy and Janino. While the API for embedding is adequate, it seems that there are quite some problems with the expression language execution itself. In the two hours that I spent with it, I already stumbled into three important issues that I posted to the MVEL forums: http://www.nabble.com/MVEL-%28MVFLEX-Expression-Language%29-f17143.html It thus seems that MVEL needs quite some real-world testing so that it can stabilize much more. Just thought I'd post my brief experience with it here. Looking forward to newer versions that feel more solid. Best regards, Geert
  3. Agreed[ Go to top ]

    Geert, Thanks for your feedback. I agree that we need more real-world testing. The feedback that you provided was excellent, and the problems (short of the static namespace issues) have all been addressed. The namespace issue is being rolled into the 1.2 beta which will be available for testing within the next few days. It is true that MVEL's usage scope has been limited by it's small user base, and I appreciate all the advanced users coming along and challenging it with complex problems.
  4. Inherited JavaBean properties[ Go to top ]

    Does MVEL supports accessing inherited JavaBean properties? With a simple test case I've found that MVEL can't find inherited JavaBean properties... is this the intended behavior? I've chased the issue to org.mvel.util.PropertyTools where there are some getDeclaredMethods() which apparently need to be changed to getMethods(). So...
  5. Hi, This looks interesting and similar to a sub-project we are working on. I have not done so yet but I'll test the speed of the EL compared with OGNL. I'll have a better look on your up and coming website. I have a couple of questions to ask here on TSS: 1) Is there a formal grammar for MVEL? A JavaCC or ANTLR definition? 2) Is there a way to order the results of restrictions/ collections? Take a look at JOSQL for some ideas... 3) What project(s) is this currently live on? 4) What's next fo MVEL? Thanks, Gary Watson ______________________________________________
  6. Hi,

    This looks interesting and similar to a sub-project we
    are working on. I have not done so yet but I'll test
    the speed of the EL compared with OGNL.

    I'll have a better look on your up and coming website. I
    have a couple of questions to ask here on TSS:

    1) Is there a formal grammar for MVEL? A JavaCC or ANTLR
    definition?
    2) Is there a way to order the results of restrictions/
    collections? Take a look at JOSQL for some
    ideas...
    3) What project(s) is this currently live on?
    4) What's next fo MVEL?

    Thanks,

    Gary Watson
    ______________________________________________
    Answers to your question: 1. MVEL does not currently have a formal grammar definition available. 2. This is an interesting suggestion, and we'll look into it. 3. MVEL just went live with RIFE, it's being planned a pluggable option in Struts 2.0, and I'm aware of it's ue on several private projects (as I have been providing e-mail support to those projects) 4. MVEL is currently moving to Codehaus, and we're joining forces with the JBoss Rules project where we'll be expanding the scope of MVEL.
  7. Christopher (and others), thanks for the information. In order to be extensible, MVEL would need to be generated by one of the parser generators (such as ANTLR or JavaCC) if it isn't already. That would give you and its users the confidence it is based on an unambiguous grammer i.e. LL(1+). Does this mean the expression parser is hand-written? It looks either hand-written or tidied a little. That is the last question, honest... - Gary ____________________________________________________
  8. MVEL replacing JFDI[ Go to top ]

    Does this mean the expression parser is hand-written?
    MVEL uses a hand coded parser which is why it's able to be less than 200kb self contained. We at JBoss Rules along with Bob McWhirter, from codehaus, recently started our own reflection based language, JFDI, for the reasons stated in this blog: http://markproctor.blogspot.com/2006/11/jfdi-new-business-action-scripting.html However at the time we where unaware of MVEL, which we have been evalauating recently; we are now looking to move those JFDI efforts into MVEL as our goal's seem mostly aligned. We are currently working closely with Mike to improve performance. JFDI, for the currently impl feature set, is probably the fastest reflection based system and we are looking to move those design improvements to MVEL - Mike is working on this now - our current use case puts us 60 times faster than MVEL1.1 - but Mike is sure that we can achieve comparable performance with MVEL and his latest improvements put it at only 13 to 14 times slower. Our current torture test/benchmark iterates the following a million times: misc.toList(foo.bar.name, 'hello', 42, ['key1' : 'value1', c : [ foo.bar.age, 'car', 42 ]], [42, [c : 'value1']] )
  9. When it comes to a fast performing expression language where I just want fast access to object properties and ability to call methods, I haven't found anything better than JEXL. The only thing faster than JEXL is Janino, but you can't have dynamic bindings with Janino. MVEL seems it could be a slightly better JEXL if you could match the performance. Thanks, Chad.
  10. I think ognl will be able to beat the stuffing out of jexl(or any other expression library) in a few more days - once the new changes are done.
    When it comes to a fast performing expression language where I just want fast access to object properties and ability to call methods, I haven't found anything better than JEXL. The only thing faster than JEXL is Janino, but you can't have dynamic bindings with Janino. MVEL seems it could be a slightly better JEXL if you could match the performance.

    Thanks,
    Chad.
  11. MVEL is faster than JEXL[ Go to top ]

    In fact, MVEL is faster interpreted than JEXL is compiled. And MVEL 1.2 will be out very shortly with a much more advanced compilation engine.
  12. Not for my use case[ Go to top ]

    JEXL is about 2 times faster than MVEL is compiled for me. I'm using JEXL 1.1 and MVEL 1.1 for Java 1.5. Now keep in mind the only thing I'm testing is just having JEXL and MVEL access a variable from the context and also make a method call. But in my application scenario that is 90% of its use so that's what is important to me. I do like MVEL and would consider using it as default if it could equal JEXL for these use cases. So I'm looking forward to testing you next release. Also, it would be nice to have the XML friendly syntax of JEXL for using as embedded expression language in XML. FYI, I'm evaluating expression languages for use with this AlphaWorks XML technology: http://www.alphaworks.ibm.com/tech/hirixml Thanks, Chad
  13. Re: Not for my use case[ Go to top ]

    There is a known performance problem with method calls in MVEL 1.1, that has already been addressed in the unreleased 1.2 beta. We are currently in the process of moving to Codehaus, and that beta will be available publicly soon. MVEL also has JIT optimization in the works.
  14. Re: Not for my use case[ Go to top ]

    MVEL 1.1.2 has been released, which has HUGE performance improvements. Check it out.
  15. Seems like the code uses a backing WeakHashMap without exclusion. This is not safe: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6425537
  16. I'm aware of the thread safety issue with WeakHashMap, and I am confident that MVEL is not afflicted by this. In fact, MVEL has thread-safe method of caching that can be enabled if it becomes an issue: MVEL.setThreadSafety(true)
    Seems like the code uses a backing WeakHashMap without exclusion. This is not safe:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6425537