4 Replies Latest reply on Jan 18, 2011 7:21 AM by Kris Verlaenen

    why to use drools rules and not Java code?

    Odelya Holiday Novice



      I still do not understand why to use drools rules to write code and not simply java code? Can anyone point out advantages?

        • 1. why to use drools rules and not Java code?
          Mauricio Salatino Master

          Hi there, I'm back.

          Some of the advatanges of using a Rule Engine against plain java code are:

          - Declarative definition of your business rules, that can be expressed using a domain specific language that business analysist can validate and understand. In other words you can define what to do and not how to do it.

          - You keep the business logic decoupled from your application, letting you change it without recompiling your entire application.

          - You need to understand that having rules is not the same of having multiple IF/ELSE statements. The analysis of true statements are not done sequencially, allowing you to analyze multiple conditions much faster.

          - Using rules you don't burry the business logic inside your application code

          Among other advantages

          • 2. why to use drools rules and not Java code?
            Kris Verlaenen Master

            Are you referring to using rules in general (like Mauricio has answered excellently ), or the more specific case of using Java code constraints vs. rule constraints inside your processes?



            • 3. why to use drools rules and not Java code?
              HUI LIU Newbie

              In fact, in the source code of krisv-jbpm, I find the test code about Java constraint and MVEL(rule) constraint in jbpm-flow-build/src/test/java/org/jbpm/integrationtests/processSplitTest.java, in this file, there is no difference between MVEL constraint and java constraint, see

              public void testSplitWithMVELContextConstraint() and

              public void testSplitWithJavaContextConstraint()

              the two kinds of constraints are the same:

              in the first function:

              <constraint toNodeId="6" toType="DROOLS_DEFAULT" priority="1" type="code" dialect="mvel" >return context.getVariable("name") != null &amp;&amp; ((String) context.getVariable("name")).length() > 0;</constraint>

              in the second function:

              <constraint toNodeId="6" toType="DROOLS_DEFAULT" priority="1" type="code" dialect="java" >return context.getVariable("name") != null &amp;&amp; ((String) context.getVariable("name")).length() > 0;</constraint>


              I don't know why?


              By the way, in this test case file, there is also the comparison between context and kcontext, I don't know their difference and in the testcase file, their only difference is their name. Can you explain it?




              • 4. why to use drools rules and not Java code?
                Kris Verlaenen Master

                MVEL is a scripting language, but it is a superset of Java, so any Java expression is also an MVEL expression.  Though you can do more with MVEL, e.g.


                myVariable = myPerson.name

                (which would be equivalent to myVariable = myPerson.getName())


                You can check out the MVEL documentation for all details:



                Regarding context or kcontext, they resolve to the same object, context was the old name we used first, we later switched to kcontext (which is now the preferred) as it is similar to ksession and kbase etc.