Discussions

News: MVEL: Going Public with JBoss' Secret Weapon

  1. MVEL: Going Public with JBoss' Secret Weapon (14 messages)

    MVEL started out as an expression evaluator for the Valhalla project, and while Valhalla itself is dormant, MVEL lives on, like a pearl plucked out of a dying oyster.

    Some have compared it to OGNL, JEXL or JUEL, but that's a mistake. In terms of features, performance, ease of use and integration, MVEL is in a class of its own. MVEL solves problems, namely the problems encompassing the domain of embedded scripting.

    Not convinced? Interested in learning more? Check out the exclusive TSS article written by Mark Proctor, the Drools Project Lead at Red Hat, and Mike Brock, the MVEL and Errai Project Leads at Red Hat.

    Learn more about MVEL and the JDK.

    Threaded Messages (14)

  2. This looks a lot like Python or Ruby both of which can be run with in a Java application  Am I missing something?

    If it is basically a new dynamic language, why should I choose this over more widely used options?

  3. vs. the rest[ Go to top ]

    I can't speak too expertly on the topic, but I think the key comes from the beginning of the article where they talk about not being "Yet another JVM language" and instead focussing on embedded scripting.

    "It does not try to be Yet Another JVM Language, but instead focuses on solving the problems of embedded scripting

    "MVEL is particularly ideal for restrictive environments that can't use bytecode generation due to memory restrictions or sand boxing. Instead of trying to re-invent Java, it instead aims to provide a familiar syntax for Java programmers while also adding syntactic sugar for short and concise expressions."

    It's also interesting what problems they encountered when evaluating other languages. Given, the evaluation likely took place a while ago, but they problems are still valid:

    • Lack of optional type safety
    • Poor integration, normally via a map populated context.
    • Inability to work without bytecode

      • Those with bytecode generation had slow compilation times, plus scalability problems (perm gen)
      • Those without bytecode generation where very slow at runtime execution.
    • Too much memory consumption.
    • Large jar/dependency size

     

  4. vs. the rest[ Go to top ]

    MVEL is a brilliant and well designed expression language (and more).

    It's invaluable (fast and also solid) where you want to run regular Java but want some parts of the program to be configurable (http://javaforu.blogspot.com/search?q=mvel) or flexible.

  5. vs. the rest[ Go to top ]

    MVEL is a brilliant and well designed expression language (and more).

    It's invaluable (fast and also solid) where you want to run regular Java but want some parts of the program to be configurable (http://javaforu.blogspot.com/search?q=mvel) or flexible.

    A little off topic:  I am really tired of people calling programming 'configuration'.  If you are writing expressions that are evaluated at runtime, it's programming regardless of whether it's dynamic or not.

    One might argue that this is just semantics and doesn't matter but that's kind of my point.  Calling 'programming' 'configuration' when it's really programming is a far to common form of BS used to bamboozle the uninformed.  It's unethical and highly irritating to me.

    Note that this really has no bearing on whether MVEL is a good tool or not.  But whenever I see a language that starts off as a 'configuration' tool, it sets off alarm bells in my head.

  6. vs. the rest[ Go to top ]

    I can't speak too expertly on the topic, but I think the key comes from the beginning of the article where they talk about not being "Yet another JVM language" and instead focussing on embedded scripting.

    "It does not try to be Yet Another JVM Language, but instead focuses on solving the problems of embedded scripting

    ...

     

    I believe that even now there is nothing that provides both static compile time safety and also non-bytecode runtimes. Both python and ruby are non type safe languages. There is "duby" the type safe ruby, but that works via bytecode generation.

    Further all those are trying to be new languages. MVEL just tries to be java, with a little added sugar. Mike actually tries to obey the java language spec, such that MVEL is just a superset of java - for statement syntaxes.

  7. MVEL is quite small; ~500k I think.  And fast.  I have used it to replace specialty classes that are called from an XML based action framework.  I now have *1* MVELExpression specialty class, with the mvel expression as the sole input.

    Why not ruby or python?  (Or groovy?)  Their runtimes are bigger, and the code to get them "spun up" quite a bit larger too.  I'm not hurting for space necessarily, and the syntax is so easy that no one's going to be thrown by it (for my small uses) anyway.

    But I'm using it as glue only, not as a full on language.

  8. But I'm using it as glue only, not as a full on language.

    Is it a Turing complete language?

  9. But I'm using it as glue only, not as a full on language.

    Is it a Turing complete language?

    http://mvel.codehaus.org/Language+Guide+for+2.0

  10. I have used MVEL wherever there was the need of path expressions with a lot of satisfaction.

    Now I am on a JSF project with its EL dependency.

    Well, there is no limit to human masochism and stupidity.

  11. MVEL rocks[ Go to top ]

    Super userful and super fast. We use it in Mule configurations and inside the Mule Query Language as an expression evaluator.

  12. From architectural point of view, scripting language _must_ be retrictive enough to prevent actual "coding" in it. It should be the orchestrator, rather than actual implementation. I saw, not once, how introduction of a scripting language turn system into a Godzilla ...

     

    It does not mean that MVEL is a bad/good language, it just yet another one. And honestly I do not see how it is better than many popular ones?! Quite a few can do the same ...

     

    Also I am 100% agree with James Watson comment:

    [quote]

    But whenever I see a language that starts off as a 'configuration' tool, it sets off alarm bells in my head.

    [/quote]

     

  13.  Quite a few can do the same ...

    You clearly did either not read or did not understand the article. I listed the aspects missing in other languages. I do not know ANY language that satisfies those requirements:

    At the time other scripting languages where reviewed, but exhibited the following issues:

    • Lack of optional type safety
    • Poor integration, normally via a map populated context.
    • Inability to work without bytecode

      • Those with bytecode generation had slow compilation times, plus scalability problems (perm gen)
      • Those without bytecode generation where very slow at runtime execution.
    • Too much memory consumption.
    • Large jar/dependency size

     

  14. Custom Property Resolver[ Go to top ]

    Hi Mark,


    Why you did not write simple document to descirbe how the custom property resolver and custom converter can be registered? and how they can delegate the actual work to the one comes with mvel if necessary, which is also very important for an implementation already complex enough?

    Ivan

  15. Custom Property Resolver[ Go to top ]

    Hi Mark,


    Why you did not write simple document to descirbe how the custom property resolver and custom converter can be registered? and how they can delegate the actual work to the one comes with mvel if necessary, which is also very important for an implementation already complex enough?

    Ivan

    No particular reason other than the article already being large enough. I'm sure they would make great topics for a second article, maybe you could volunteer to write it. I'm sure TSS would publish it for you.