Version 6

    This page is to add suggestions for things which would change default behaviour or break backwards compatability. The idea is to get a roadmap of possiblities for Drools 6.0


    Modified Activations should not refire

    A rule with the following pattern should not refire for each change in age:

    Person( age > 17)

    i.e. you don't want the rule to fire when the person is 18, 19, 20 etc. This will further help with recursion and most likely the default behaviour people expect.


    We can allow a new keyword to control triggering cycles, such as "every", this might overlap with suggestions for "sequencing", as sequencing has directives to control when a sequence restarts or not.

    every Person( age > 17)


    Will not do this, instead will use "any", or the end keyword that is chosen.


    Type safe Annotations

    currently we allow any annotation to be used in a rule, there is no type safety enforcement. This is becuase these annations also provide meta data information for a rule. With the move to project oriented bundles, having pre-defined set's of annotations to be used for meta data is not too cumberson. So for 6.0 we should make this type safe and request all annotations are pre-declared. Builder configuration can potentialy relax this for backwards compatability.


    agreed, need to make sure we can declare annotations.


    Make boolean CEs ("guards") non-blocking


    Currently we have the CEs "not", "exist" and "eval" which, when false, inhibit further LHS evaluation. By permitting these CEs to create temporary Boolean pseudo-facts (like "accumulate" or "collect") additional expressivity is gained. Continuing the evaluation could be expressed by, e.g.

       $b: not(...)  # never blocks, binds the result of "not" to $b.


    Consider, for instance, a condition for a city's attractiveness: The city must have at least two of of these three: an opera house, a theater, a library.

    rule "attractive city"


        $c: City( name == "Boomtown" )

        $b1: exist Opera( city == $c )

        $b2; exist Theater( city == $c )

        $b3: exist Library( city == $c )

        eval( atLeastTwoTrue( $b1, $b2, $b3 ) )






    leave for now

    Permit named constants in DRL (and their import from a DRL package)


    Using literals such as 42 or "R2-D2" in your code is generally considered bad programming style. While DRL does permit the import of final statics defined in Java, this feature is missing from the DRL language itself.


    Adding the DRL construct

    constant type name = expression

    would remove this restriction.


    Ideally, such constants could be imported from another DRL package. Potential problem: the compilation order isn't arbitrary any more.


    agreed, make sure we can init globals too. Need to think about scoping

    Add CE templates

    When similar arrangements of patterns with similar constraints occur over and over again, almost identical CE snippets have to be repeated. It should be possible to define such snippets once, and instantiate them repeatedlly. This should work as a purely compile-time feature, similar to the C Preprocessor's "define".


    template name ([name,...])




    A (contrived) example:

    template hasMoreThan( count, Entity, prop, owner )
       Number(intValue > count) from accumulate( Entity( prop == owner ), count(1) )

    rule "more than 5 cars"
       Person( $name: name )
       hasMoreThan( 3, Car, owner, $name )

    rule "young mother with more than 2 children"
        $p: Person( age < 21 )
        hasMoreThan( 2, Person, mother, $p.ssn ) # ssn : soc. sec. no.






    Note 1: This is fundamentally different from rule extension!

    Note 2: This might also be used for "named constants" (as in C), but only on a local level.


    Interesting needs more thought. We need to think about macro's and dsl as a whole. It's also related to the idea of "predicates" for pluggable nodes, such as a message node.


    Enable RemoveIdentites by default

    Remove identities is disabled by default at the moment, due to performance. With new ASM JIT this should now be much cheaper, so we should think of enabling this. This ensures that the following rule would only get a single activation per A instance:

    rule when


    Agreed, are look at refraction. Annotation to turn on/off, default to be decided, at rule level.