[jboss-jira] [JBoss JIRA] (DROOLS-941) On the fly automatic @Modifies configuration for PropertyReactive

[Geoffrey De Smet (JIRA)]

Geoffrey De Smet created DROOLS-941:
---------------------------------------

             Summary: On the fly automatic @Modifies configuration for PropertyReactive
                 Key: DROOLS-941
                 URL: https://issues.jboss.org/browse/DROOLS-941
             Project: Drools
          Issue Type: Feature Request
          Components: core engine
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco


Property reactive can't be enabled by default on all classes because:
A) It's not backward compatible 
B) The annotation @Modifies is a pita because it makes us repeat ourselves. For example

{code}
class Foo
  @Modifies("price")
  int basePrice;
  @Modifies("price")
  int vat;
  Location location;

  public int getPrice() {
    return price + vat;
  }
}
{code}
Now do maintenance on the code above and don't charge VAT if the location == airport. You'll likely forget to add the @Modifies on Location. And nor compilation nor runtime will tell you. This bug might even escapes into production.
=> @Modifies violates DRY.


Solution to both A) and B), which *allows that property reactive with an incredible speed improvement can be enabled by default*:

Use ASM or byteman on this class:
{code}
class Person {
   int a;
   int b;

   int getA() {return a;} // Modified by {a}
   int getB() {return b;} // Modified by {b}
   int getC() { // Modified by {b}
        return b + 5;
   }
   int getD() { // Modified by {*} because we don't know, so modified by {a,b}
        return Util.rabbitHole(this);
   }
   
}
{code}

Through bytecode introspection we figure out the @Modifies, in a way that won't have too little activations (which would be a bug). It still might have a few too many activations (such as d), but it will be far less activations that the current default behavior.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)