WhyMVEL

Version 2
    • reflection/bytecode modes - for huge systems we need to be able to avoid bytecode integration

    • fast reflection mode. We originally started with our own language JFDI, which was designed to be a simple and fast reflection based language, the idea is all work is done at compile time so runtime is just a series of reflection invokers. This design has been carried through to MVEL, so that it has good reflection performance. Where as other languages have to drop reflection mode and use bytecode to get any reasonable level of performance.

    • pluggeable resolvers, dictionary population is too slow, MVEL can resolve its variable direct from the provided resolvers, which we make array based for performance.

    • small, MVEL is currently < 500kb including the inlining of ASM.

    • custom language extensions. MVEL is extending the language to support rule friendly constructs, in particular block setters. So I can do "modify (person) { age += 1, location = "london" }" with the ability to treat that as a transaction block so I can run before and after interceptors on the entire block.

    • optional typed or dynamic mode. In typed mode full type inference is done, with support for upcasting, so that we can check correct api usage at compile time, provide code completion and refactoring. Dynamic code is no so good for rules, type enforcement through type inference is much better.

    • ability to turn language features off. We don't want imperative flow structures in the "then" part, no 'if' 'switch' etc. Rules should be declarative, "when this do that" not "when this maybe do that"